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 (Cocoon.java 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.
www.site1.com -> /cocoon/mount/site1
www.site2.com -> /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
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
