cocoon-dev mailing list archives

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

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

As long as no java classes are deployed, yes. But as soon as you have to
deploy additional classes you go into trouble.

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

I don't understand what you are asking for.

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

If you use Apache virtual hosts you should also use Apache
mod_rewrite/mod_proxy for that and your scenario is easy possible with
only one Cocoon instance.

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

You simply need a test environment which reflects your production

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

See above.


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

View raw message