cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [RT] user-components.xconf
Date Wed, 06 Mar 2002 08:44:42 GMT
On Tue, 5 Mar 2002, Nicola Ken Barozzi wrote:

> From: "Sylvain Wallez" <>


> > In the interpreted sitemap engine, the <map:components> section is
> > handled as regular component manager configuration (i.e. a .xconf file),
> > so you can add any component you wish in it.
> >
> > The only piece that's missing is a classloader per subsitemap to load
> > additionnal jars. But we should be careful with that since this places
> > code in areas that are potentially visible from the client browser (the
> > servlet engine hides the contents of WEB-INF). A solution could be for
> > the sitemap engine (or Cocoon itself ?) to forbid access to all URIs
> > containing 'WEB-INF/'.
> I'm definately +1 on having some kind of user.xconf.
> I'd be +10 for a directory where you can plug in Cocoon blocks. Yes, block.

user.xconf as well as user.roles must be organized so that every Cocoon
Block has at least a set of it (we can discuss if it should be bound to
a sitemap, and thus be hierarchically organized instead of flat, but ...

> From a previous interesting discussion on the list, I understood that Cocoon
> needs 3 levels of pluggability: components, blocks and apps. This is
> probably reflected from the fact that it uses Avalon, and Phoenix is
> organized this way.
> 1 Components
> -------------------
> Components are all components under ./components. Some are of Cocoon proper,
> some used only by blocks.
> 2 Blocks
> ----------
> blocks are the Cocoon proper components (Generators, Transformers, etc).
> They may need Components, and they must not need other blocks. They should
> be IMHO easily deployable.

As you mentioned Avalon Phoenix there Blocks CAN use other Blocks as a
Block is defined as a Service.


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

View raw message