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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
