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 (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? 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. > > 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. 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 environment. > 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. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
