cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: AW: [C2]: Avalon Component Configuration
Date Tue, 10 Apr 2001 14:23:24 GMT
Giacomo Pati wrote:
> Quoting Carsten Ziegeler <>:
> 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

> > 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 "" for that purpose.

To unsubscribe, e-mail:
For additional commands, email:

View raw message