cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject Re: Move to Xalan2J
Date Fri, 20 Oct 2000 11:36:29 GMT
> --- Paul Russell <> wrote:
> > On Fri, Oct 13, 2000 at 07:00:01AM +0200, Giacomo Pati wrote:
> > > Paul Russell (sorry, I've misspelled your name in the cvs
> > > commits) has implemented a component manager for the general
> > > components (not sitemap components) which respects the new
> > > interfaces from the new avalon release. These interfaces are
> > > used to mark classes as ThreadSafe, SingleThreaded, Poolable
> > > or Recyclable. With this base implementation we are able to
> > > (finally) use the Store to save objects for multiple uses (i.e
> > > pregenerated or compiled stylesheets).
> > 
> > Heh. That's okay, I'm used to it. There's also another slight
> > issue. The code I sent you deals with handing out components
> > from pools etc etc, however it doesn't deal with getting them
> > back into the pools afterwards. I'm not entirely sure how to
> > deal with this - I still feel it needs a subinterface to
> > ComponentManager that lets it accept components which people
> > have finished with. I've mentioned this to the Avalon peeps
> > before I think, and not had any joy. Any thoughts?

It may need a sub-interface, something like a ComponentManagerPool
and ComponentSelectorPool to expose the method to put them back.
Just because Avalon doesn't include it as a standard interface
doesn't mean that we can't put it here in Cocoon.  Who knows, if
it becomes painfully obvious we may incorporate something like it
in Avalon.

<snip on="holder discussion"/>
> Another BTW. Excuse my namings. I'm very bad in naming things. I you
> all feel "holder" is a bad name for what it does. I was lead by
> thinking that these objects "hold" a/many component(s). Feel free to
> suggest a propper name for it :)

Is it technically a "Pool", or more like a "Cache"?  Until we have
an epiphony, Holder is fine.  BTW, when I made the integration to
Avalon 3, I didn't touch the holder classes--I didn't need to.

> > > Further, the component defined in a sitemap are now available
> > > to sub sitemaps (sitemap component inheritance). This means
> > > that you can use sitemap components defined in the parent
> > > sitemap without the need to redeclare them. 


> > > - Fully integration of the new avalon release.

This is now done.

> > Happy to contribute on the status and profiling side, obviously.
> > I'll try and look over the new sitemap.xsl asap and post a slightly
> > more involved (and better written ;) e-mail about it...
> > 
> > What's left to do on the avalon integration?


> The new avalon has changed many method names. There is some work to
> rename them. Also the NamedComponentManager has been replaces by a
> ComponentSelector which I think works different (haven't looked into
> the code yet).

Some things to keep in mind for future development:

A ComponentManager looks up Components by Role.  A role is defined as
the fully qualified name of the work interface (with one exception).

A ComponentSelector selects Components by Hint.  A ComponentSelector
is a Component, and is the one exception.  The Role for the
ComponentSelector is the work interface of the target Component plus
the word "Selector" attached to the end.  A ComponentSelector selects
from a group of Components that implement the same interface.


We have one Parser Component needed:

Parser parser = (Parser) manager.lookup("org.apache.cocoon.components.parser.Parser");

// Rewritten using the Roles interface:

Parser parser = (Parser) manager.lookup(Roles.PARSER);

Example 2:

We have multiple Markup Languages:

ComponentSelector selector = (ComponentSelector) manager.lookup(Roles.MARKUP_LANGUAGE);
MarkupLanguage markup = (MarkupLanguage)"sitemap");

// the full role for the selector is:
// org.apache.cocoon.components.language.markup.MarkupLanguageSelector

View raw message