cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Date Thu, 09 Aug 2001 12:02:35 GMT


giacomo wrote:
> 
> On Thu, 26 Jul 2001, Berin Loritsch wrote:
> 
> > * New CocoonTask environment: Allows for a new Ant task to build documentation using
cocoon!
> 
> This would be very cool :)
> 
> > How to perform the solution:
> >
> > We need a generic Servlet that performs the following things:
> >
> > 1) Create a CocoonConfigurator Interface with an "initialize" method that
> >    accepts a map and a getProcessor() method that handles Cocoon creation
> >    and useage.
> 
> > 2) Loads the classes into a known ClassLoader.
> 
> You mean an approach similar to the <init-param> init-classloader we
> have today and a path (probably absolute) where the libs are?
> 
> > 3) Copies the initialization parameters into a Map (generic java object).
> 
> This is to generalize the ServletConfig (and any other environment
> specifiy configuration methods/objects) into simple name/value pairs?

I once proposed to be able to "externalize" some of the values in
cocoon.xconf using a substitution syntax like "${name}". The purpose is
to avoid modifying cocoon.xconf during deployment (e.g. jdbc URLs, cache
sizes, etc). It seems like these values could be fetched from these
initialization parameters.

> > 4) instantiates a CocoonConfigurator object using reflection.
> 
> I don't get why there seems the need for "using reflection". What
> different constructors do you have in mind for the different
> environments?
> 
> > 5) calls initialize(Map)
> > 6) calls getProcessor().process() with the Environment object for each request.
> 
> How do you see the "cocoon-reload" is handled?
> 
> > 7) the Processor interface, and the environment interfaces, and the new
> >    CocoonConfigurator interface should be packaged into a "cocoon-env.jar"
> >    that is used for environment adapting.
> 
> +1
> 
> > 8) the Servlet package, and the implementations for all the Http environment
> >    classes get moved into a "cocoon-servlet.jar"
> 
> +1
> 
> > 9) the Main class, and the implementations for all the CLI environment classes
> >    get moved into a "cocooncli.jar"
> 
> +1
> 
> > 10) the CocoonConfiguratorImpl class is the same for all environments and is
> >     included in the "cocoon.jar" along with all the other cocoon classes.
> 
> If the CocoonConfiguratorImpl is used by all environments whats the
> benefit of having a interface as well?
> 
> Sounds like a good plan to me.
> 
> Giacomo (yes, I'm back from vacation but still some hundered mails
> away from the head :/ ).

Still on vacation, and it's still raining :(
-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message