On Fri, 1 Mar 2002, Stefano Mazzocchi wrote: > giacomo wrote: > > > > 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. > > Hmmm, good point. > > What about 'Cocoon Block'? It uses the same Avalon patterns, just onto a > different level.
As I'm in the process of writing some Avalon Blocks for my next project so I do like it :) > 'Cocoon Module' is the second best, even if almost everyone has a > different opinion of what a 'module' is. Yup. And also Module is kinda dusty (Cobol, PL/1, Modula) > > > > > <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. > > Agreed. > > > 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. > > right > > > 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) > > right > > > 3. there is only one lib directory for all jars (WEB-INF/lib). > > exactly! > > > 4. You have to stop and start your servlet engine. > > yep, Cocoon needs an hotly extensible classloader, just like Tomcat has > (you can hotdeploy new wars on tomcat without restarting, this should be > possible for Cocoon as well). > > Ugo, sure it's possible to mount new sitemaps on top of a running > cocoon, but not if they connect to components that are to be deployed > with jars along with the sitemap and the other resources. This is the > real point. > > > 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). > > Yes, we need a 'block manager', possibly with a secure web interface. > > > 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. > > No, we should leave things as back compatible as possible....hmmm, I'll > think about it. I know. maybe we can make it both ways. > > > 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. > > Absolutely agreed. > > Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
