You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@sundn.de> on 2001/04/10 10:46:53 UTC
[C2]: Avalon Component Configuration
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".
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?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Avalon Component Configuration
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <cz...@sundn.de>:
>
> > > Berin Loritsch wrote:
> > > Giacomo Pati wrote:
> > > >
> > > > Quoting Carsten Ziegeler <cz...@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?
> > >
> > > This is possible. You don't even need the <parser/> element at all as
> > > long as you have a default-class mapped to a role name. I left
> > > the <parser/>
> > > element in the configuration file to show that it could be overridden.
>
> BTW: Take into account that the parser (as the only component in the system) is
> *not* added because of the configuration cocoon.xconf but because Cocoon adds it
> expicitly. Its because the hole configuration system needs a parser to read the
> cocoon.xconf file.
In that case, we should remove it from the cocoon.xconf file altogether.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Teaser] C2 Caching
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Matthew Langham <ml...@sundn.de>:
> Hi cache lovers :-)
>
> I have just taken a look at Carsten's first version of caching for C2.
> It is
> complete - but I will will leave the details to him.
>
> So anyway - we also checked out the gain in performance when using the
> "caching" version........
>
> .....How does from 40ms to now only 10ms sound for hello.html?
Sounds good. But I havn't seen any commit mails :)
Giacomo
>
> Regards
>
> Matthew
>
> --
> Open Source Group sunShine - Lighting up e:Business
> =================================================================
> Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
> =================================================================
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[Teaser] C2 Caching
Posted by Matthew Langham <ml...@sundn.de>.
Hi cache lovers :-)
I have just taken a look at Carsten's first version of caching for C2. It is
complete - but I will will leave the details to him.
So anyway - we also checked out the gain in performance when using the
"caching" version........
.....How does from 40ms to now only 10ms sound for hello.html?
Regards
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Avalon Component Configuration
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Carsten Ziegeler <cz...@sundn.de>:
> > Berin Loritsch wrote:
> > Giacomo Pati wrote:
> > >
> > > Quoting Carsten Ziegeler <cz...@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?
> >
> > This is possible. You don't even need the <parser/> element at all as
> > long as you have a default-class mapped to a role name. I left
> > the <parser/>
> > element in the configuration file to show that it could be overridden.
BTW: Take into account that the parser (as the only component in the system) is
*not* added because of the configuration cocoon.xconf but because Cocoon adds it
expicitly. Its because the hole configuration system needs a parser to read the
cocoon.xconf file.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Avalon Component Configuration
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Berin Loritsch wrote:
> Giacomo Pati wrote:
> >
> > Quoting Carsten Ziegeler <cz...@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?
>
> This is possible. You don't even need the <parser/> element at all as
> long as you have a default-class mapped to a role name. I left
> the <parser/>
> element in the configuration file to show that it could be overridden.
>
Thanks Berin, I think now I got it.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Avalon Component Configuration
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <cz...@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?
This is possible. You don't even need the <parser/> element at all as
long as you have a default-class mapped to a role name. I left the <parser/>
element in the configuration file to show that it could be overridden.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Avalon Component Configuration
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> > Giacomo Pati wrote:
> >
> > Quoting Carsten Ziegeler <cz...@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?
> >
> > > 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. That is a configuration time only convenience mapping.
> 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?
If the Component has a discrete role that is separate from the "store"
role, then it is a different role altogether. In other words, You
can use more than one instance of the MemoryStore component when the
roles are different. The <store/> instance is for caching of Templates
and other runtime objects. You can create a <cache/> role that uses
another instance of that Store object.
Or, you can simply share the MemoryStore object.
> 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.
The role name is a String, and by pattern, it is mapped to the Interface
that the Component implements. However, there can be deviations based
on certain criteria: Components that are accessed via selectors usually
append "Selector" to the interface name, and Components that share API
but not purpose may have an artificially distinct role name from the
interface--but try to maintain concistancy.
IOW:
Component Interface:
org.apache.cocoon.components.store.Store (Interface Name)
Roles:
org.apache.cocoon.components.store.Store (current role for object cache)
org.apache.cocoon.components.store.Repository (role for XSP repository)
org.apache.cocoon.components.store.Cache (new role for XML cache)
The Store and Cache roles can both implement instances of the MemmoryStore
object, and all three can share the Store interface, but the roles are
distinct from each other and follow Avalon patterns.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Avalon Component Configuration
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> Giacomo Pati wrote:
> > 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.
>
> I wouldn't. Use the Store interface if it works for your purpose. Use
> the role name "org.apache.cocoon.components.store.Cache" for that purpose.
Oops, I think we are arguing the same thing. Use the interface, creating
a new component type. But do use the afforementioned role name for accessing
the component type.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Avalon Component Configuration
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Berin Loritsch <bl...@apache.org>:
> Giacomo Pati wrote:
> >
> > Quoting Carsten Ziegeler <cz...@sundn.de>:
> >
> > 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.
>
> See my response to this. The ComponentManager has always been able to
> do this
> after my introduction of the shorthand name concept for the
> configuration
> file. Basically you just accept the defaults, and an empty
> Configuration
> object is passed to Configurable components that are not declared
> explicitly.
>
> > > 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 would strongly recommend not to do this. We spent alot of time on
> the Avalon project comming up with reasons for and against this. The
> bottom line is that the Contract with a Role has to be strong. It
> should
> not be weekened by aliases in the component management framework.
> Otherwise,
> what would happen is your code would break as soon as you changed the
> shorthand name for the Component.
>
> We came up with the standard of following interface names to avoid
> name claches in environments where Components are developed by various
> companies. With that tight coupling, you can be reasonably assured
> that the Component instance retrieved from the ComponentManager
> implements
> the API you depend on. We do allow for deviations in two cases:
> ComponentSelectors and Roles that share an interface but not a purpose.
> ComponentSelectors follow the pattern of the interface name with
> "Selector" appended to the end (e.g.
> "org.apache.cocoon.serializers.SerializerSelector").
> Roles that share an interface but a different purpose are still distinct
> roles. Therefore, the role name needs to remain as close to the
> interface
> name as possible, but you may deviate on where the Class name *would*
> be. Note: in cases where there is more than one interface in a package,
> you should append the diviation to the full interface name.
>
> > > 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).
>
> Not necessarily. They do not share the same ROLE. A Role is not just
> an
> interface, but a component with a specific purpose. SitemapComponents
> are
> accessed by ComponentSelectors because they share the same interface and
> purpose. The same applies to the other instances we use
> ComponentSelectors.
>
> We already use a divergent Role name with the Store interface because
> the
> Repository and the Store roles have distinct purpose--but share the same
> interface.
>
> > > 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.
>
> I wouldn't. Use the Store interface if it works for your purpose. Use
> the role name "org.apache.cocoon.components.store.Cache" for that
> purpose.
Ok :) you have convinced me for all issues.
Thanks for your clarifications.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Avalon Component Configuration
Posted by Berin Loritsch <bl...@apache.org>.
Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <cz...@sundn.de>:
>
> 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.
See my response to this. The ComponentManager has always been able to do this
after my introduction of the shorthand name concept for the configuration
file. Basically you just accept the defaults, and an empty Configuration
object is passed to Configurable components that are not declared explicitly.
> > 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 would strongly recommend not to do this. We spent alot of time on
the Avalon project comming up with reasons for and against this. The
bottom line is that the Contract with a Role has to be strong. It should
not be weekened by aliases in the component management framework. Otherwise,
what would happen is your code would break as soon as you changed the
shorthand name for the Component.
We came up with the standard of following interface names to avoid
name claches in environments where Components are developed by various
companies. With that tight coupling, you can be reasonably assured
that the Component instance retrieved from the ComponentManager implements
the API you depend on. We do allow for deviations in two cases:
ComponentSelectors and Roles that share an interface but not a purpose.
ComponentSelectors follow the pattern of the interface name with
"Selector" appended to the end (e.g. "org.apache.cocoon.serializers.SerializerSelector").
Roles that share an interface but a different purpose are still distinct
roles. Therefore, the role name needs to remain as close to the interface
name as possible, but you may deviate on where the Class name *would*
be. Note: in cases where there is more than one interface in a package,
you should append the diviation to the full interface name.
> > 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).
Not necessarily. They do not share the same ROLE. A Role is not just an
interface, but a component with a specific purpose. SitemapComponents are
accessed by ComponentSelectors because they share the same interface and
purpose. The same applies to the other instances we use ComponentSelectors.
We already use a divergent Role name with the Store interface because the
Repository and the Store roles have distinct purpose--but share the same
interface.
> > 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.
I wouldn't. Use the Store interface if it works for your purpose. Use
the role name "org.apache.cocoon.components.store.Cache" for that purpose.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Avalon Component Configuration
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Giacomo Pati <gi...@apache.org>:
> Quoting Carsten Ziegeler <cz...@sundn.de>:
>
> > > Giacomo Pati wrote:
> > >
> > > Quoting Carsten Ziegeler <cz...@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.
I was *wrong*! It is sufficent to define the <role> with a name and a default
class to define it as a component for the ComponentManager, sorry.
Giacomo
>
> > > > 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2]: Avalon Component Configuration
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati wrote:
>
>
> Quoting Carsten Ziegeler <cz...@sundn.de>:
>
> > > Giacomo Pati wrote:
> > >
> > > Quoting Carsten Ziegeler <cz...@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.
>
Yes, you're right. I will setup an own XMLStore for separating things.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2]: Avalon Component Configuration
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Carsten Ziegeler <cz...@sundn.de>:
> > Giacomo Pati wrote:
> >
> > Quoting Carsten Ziegeler <cz...@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
AW: [C2]: Avalon Component Configuration
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <cz...@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?
>
> > 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"?
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?
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.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Avalon Component Configuration
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Carsten Ziegeler <cz...@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?
> 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.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Avalon Component Configuration
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> 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"/>
The role entry describes the real role name (name attribute), the XML
element alias (shorthand attribute), and the default class (default-
class attribte). It is necessary for Cocoon to function if the explicit
Component has not been added. In fact, if the <parser class="@{class}"/>
entry uses the same class, the <parser/> element is not needed at all.
> Is the first one obsolete? I thought the second declaration adds
> a component with the role name "parser".
No. The second declaration tells the Avalon component management framework
what to do with the convenience element "parser". There is no role named
"parser". The role is named "org.apache.cocoon.components.parser.Parser".
> 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?
Again, the "role" element is the prototype for the Avalon component management
framework so that it knows what to do with the "url-factory" element. The
"url-factory" element is the Configuration element for the
"org.apache.cocoon.components.url.URLFactory" role.
This is instead of the long-hand version of the Component entry:
<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>
I am debating on whether to separate the role definitions from Cocoon.xconf. I think
it would alleviate allot of confusion--especially since the role definition entries
are developer concerns.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org