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 Thu, 28 Feb 2002 21:41:55 GMT
On Thu, 28 Feb 2002, Stefano Mazzocchi wrote:

> Antti Koivunen wrote:
> >
> > Stefano,


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

And for 4: A good architecture on 3. will solve this as well.



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

View raw message