cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject Re: [RT] Cocoon Web Applications
Date Fri, 01 Mar 2002 08:36:03 GMT
giacomo wrote:

> We have a procedure in our company how to build and deploy Cocoon
> Application Components 'by hand' (shure we use Ant for that). It is
> based on the sub-sitemap concept (in a sub-directory of the webapps
> context root) and the root sitemap only mounts those Applications into
> the URI space Cocoon is managing (well, the root-sitemap also defines
> the most commonly used sitemap components).
> Granted, this procedure show clearly the leaks:
> 1. You have to change the root sitemap for every new Application that
> should be deployed.
> 2. cocoon.xconf is not able to be structured hierachically like the
> sitemap.xmap (which would enable to have separate .roles files as well
> for configuration abbreviations)
> 3. there is only one lib directory for all jars (WEB-INF/lib).
> 4. You have to stop and start your servlet engine.

I never have to stop and restart the servlet engine when deploying a 
subsitemap, using Tomcat.

> To solve these deficiencies to finally enable Stefano's vision of
> deployable Application over the net we can do:
> For 1: The Deploying Engine ( today) needs to directly use
> some kind of URI-Matcher to mount the sub-sitemap of an Application. It
> could done by dynamically add those mounts to the root sitemap when
> using the interpreted sitemap treeprocessor. there will also be a method
> of dynamically specify the deployment (i.e. looking into the webapps
> context directory for newly added Cocoon Application Component archives
> or the technologically more advanced 'net deployment' procedure).

Isn't this what the "mount" mechanism is about?

> For 2: A simple way could be to change how we do it today (cocoon.xconf
> references the sitemap.xmap file). If the sitemap references the
> cocoon.xconf it would be automatically bound into the sitemap hierarchy.
> But this is a total change of the concept we have designed it. The
> original thought was that a sitemap maintainer should not mess around
> with the cocoon.xconf file and the administrator (which is messing
> around with cocoon.xconf) should be able to state where the initial
> sitemap.xmap file is.
> For 3: We definitively need to change the classloader design to have
> Application specific jars located and loaded separate for each
> Application.
> And for 4: A good architecture on 3. will solve this as well.
> Comments?
> Giacomo

I used to think that having a single instance of Cocoon and mounting 
applications in subsitemaps was the best solutions, but recently I have 
changed my mind. There are two reasons for this:

1. I use Apache virtual hosts to map hostnames to subsitemaps, e.g. -> /cocoon/mount/site1 -> /cocoon/mount/site2

Unfortunately, I have discovered that the servlet container is supposed 
(according to the Servlet spec) to instantiate one webapp PER vhost. 
Thus I ended having multiple instances of Cocoon, each one carrying with 
itself all the components defined in cocoon.xconf and all the 
subsitempas. Not very efficient IMHO.

2. The second problem is that sometimes I want to use some new feature 
or need some bugfix that is available only in CVS or i a more recent 
release. If I substitute some of the core JARs, I risk breaking 
compatibility with all the already deployed applications in subsitempas.

So I am trying to prepare a "core" Cocoon webapp, without optional 
components and without samples, just the status page to check that it is 
running and use it as a template for new webapps.

If the vhost "problem" has no solution, I see no advantage in deploying 
different subsitemaps under the same Cocoon instance (unless you are not 
using vhosts, that is).


Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail:

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

View raw message