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.
'Cocoon Module' is the second best, even if almost everyone has a
different opinion of what a 'module' is.
> > > <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.
> 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.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
