cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Date Thu, 09 Aug 2001 12:56:43 GMT
Quoting Sylvain Wallez <sylvain.wallez@anyware-tech.com>:

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

I don't see how this relates. The mentioned Map contains the name/values 
specified in the web.xml file. There is no such things like pool sizes, dburls 
etc.

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

I feel sorry for you.

Giacomo

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

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


Mime
View raw message