On Thu, 28 Feb 2002, Stefano Mazzocchi wrote: > Antti Koivunen wrote: > > > > Stefano,
<snip/> > > Thanks, I like it too. Another even more general term would be simply > > 'Cocoon Module', but it might not have the same marketing value (and the > > acronym would be confusing :) > > Hmmm, what do others think of this? I'd like the name "Cocoon Component" or "Cocoon Application Component" or simply "Cocoon Application" because it is not focused on a given technology (like Web) so it could also be for Mail as well as for Commandline, etc. > > <skip/> > > >> > > >>>But a package manager alone would not something that would please my > > >>>search for a viable way to make cocoon web applications easily reused > > >>>between different projects. > > >>> > > >>I agree (and would love to see that repository of Cocoon modules :) > > >> > > > > > > Exactly and I think that in order to make sure they interoperate in a > > > nice and easy way, CWC polymorphism would be way cool! > > > > Absolutely. Perhaps it's time to get back to the root of this thread and > > start defining things in detail :) > > Yes, totally. Why don't you get back to my first email and comment on > the technical details that I expressed there? I'm sure this will start a > discussion and others might jump in. Which one do you mean. Your original RT from September 30 last year ;) There you have showed us the hole possibilities that we could add (like an Avalon Phoenix Kernel) which will be nice in the end but I'd propose to go there in steps. 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. 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). 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
