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:37:56 GMT
On Tue, 5 Mar 2002, Sylvain Wallez wrote:

> Bertrand Delacretaz wrote:
> >On Tuesday 05 March 2002 09:21, Torsten Curdt wrote:
> >
> >>. . .
> >>We should be able to have a separate configuration besides the
> >>configuration for the core components. We should be able to define a
> >>user.xconf. (or better user-components.xconf?)
> >>. . .
> >>
> >
> >From a user's point of view, being able to drop the .xconf and required
> >jars in a directory under mount/ would IMHO be a great first step
> >towards "pluggable cocoon apps":
> >
> >mount/my-app
> >  sitemap.xmap
> >  cocoon-config/my-components.jar
> >  cocoon-config/my-jdbc-driver.jar
> >  cocoon-config/my-app.xconf
> >  docs/index.xml
> >  . . .
> >
> >Currently this mount thing works great (even without stopping cocoon)
> >if you need just a sitemap and content files, but as you mention more
> >than that needs editing the global cocoon.xconf and/or copying jars
> >under WEB-INF.

This leads IMO to a concept where Cocoon has a default or built-in
root-sitemap which only contains the deploying and mouning steps for
Cocoon Blocks. A "DeployerAction" can handle expansion of a jar with a
well-known structure (similay to the SAR concept in Avalon-Phoenix)

> 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.

But without having the ability to specify a roles file for abbreviating
the configuration specification, right?

> 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/'.

Yes, it make absolutely sense to have a classloader per sitemap which is
able to hot deploy or redeploy whenever you drop in a Cocoon Block jar.


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

View raw message