cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [RT] Cocoon Web Applications
Date Fri, 01 Mar 2002 17:45:51 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message