cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: AW: [C2]: Avalon Component Configuration
Date Tue, 10 Apr 2001 11:27:28 GMT
Quoting Carsten Ziegeler <cziegeler@sundn.de>:

> > Giacomo Pati wrote:
> >
> > Quoting Carsten Ziegeler <cziegeler@sundn.de>:
> > 
> > > Hi,
> > > 
> > > I am trying to add new avalon components to the 
> > > cocoon.xconf (yes, for caching of course....) and am
> > > now a little bit confused about the format.
> > > 
> > > E.g. the parser has the following entries:
> > >   <parser class="org.apache.cocoon.components.parser.JaxpParser"/>
> > > 
> > >  <role name="org.apache.cocoon.components.parser.Parser"
> > >        shorthand="parser"
> > >       
> default-class="org.apache.cocoon.components.parser.JaxpParser"/>
> > > 
> > > Is the first one obsolete? I thought the second declaration adds
> > > a component with the role name "parser".
> > 
> > I'm not sure if the definition of the role is sufficent to define 
> > the component 
> > without the absolute minimum component definition (which in this 
> > case would be 
> > <parser/>). Berin, have you any comments on this handy?

I can now answer this myself. No, it is not sufficent to define a role element 
for a component. There needs to be a component definition.

> > > For the URL Factory I found:
> > >   <url-factory>
> > >     <protocol name="resource"
> > > class="org.apache.cocoon.components.url.ResourceURLFactory"/>
> > >     <protocol name="context" 
> > > class="org.apache.cocoon.components.url.ContextURLFactory"/>
> > >   </url-factory>
> > > 
> > >  <role name="org.apache.cocoon.components.url.URLFactory"
> > >        shorthand="url-factory"
> > >       
> default-class="org.apache.cocoon.components.url.URLFactoryImpl"/>
> > > 
> > > Is the second one the definition for the role and the first one the
> > > configuration for this role? 
> > 
> > Here the role states that a component specified as <url-factory> 
> > (because of the 
> > shorthand attribute) represented by class 
> > org.apache.cocoon.components.url.URLFactoryImpl will implement 
> > the working 
> > interface org.apache.cocoon.components.url.URLFactory. It might 
> > be possible to 
> > rewrite that using a ComponentSelector similar to the 
> > specification of the 
> > DataSource component.
> > 
> > Generally the role element defines shorthands for component 
> > definition. Thus the 
> > complete definition for the URLFactory without a role definition will
> be:
> > 
> >  <component role="org.apache.cocoon.components.url.URLFactory"
> >            class="org.apache.cocoon.components.url.URLFactoryImpl">
> >    <protocol name="resource"
> >        class="org.apache.cocoon.components.url.ResourceURLFactory"/>
> >    <protocol name="context" 
> >        class="org.apache.cocoon.components.url.ContextURLFactory"/>
> >  </component>
> > 
> > And yes, the <protocol> elements are configurations for the 
> > url-factory only.
> > 
> And the lookup of the components is done via the role name, correct?
> So, looking up "org.apache.cocoon.components.url.URLFactory" would
> work. Would it be also sufficient to lookup "url-factory"?

No, it needs to be the working interface name (the value of the name attribute 
of the <role> element or the value of the role attribute of the <component> 
element). I don't know if this could be an enhancement to the ComponentManager 
system to lookup shorthands as well. Berin?

> I am asking this, because I want to use the Store for storing the
> cached content. This would allow to use existing interfaces and
> implementations for the caching.
> But I don't want to use the normal <store> component but an explicit
> Store for the caching which might have another implementation.
> Is this possible?

You have to use a ComponentSelector as component implementation in this case. 
With the Selector one is able to get a specific implementation by use of a 
"hint" (see datasources).

> I know, I could create another Interface, like XMLStore, which
> extends Store and implement that - but then I could not use any
> Store implementation for caching. An own (inheriting) implementation
> is required to implement the XMLStore interface.

I thought the Store is an object store but the cache store is something that 
keeps "compiled" SAX events. i don't know if setting up a different XMLStore 
will suit better. 

Giacomo

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message