cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Date Tue, 07 Aug 2001 21:08:26 GMT
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?

> 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 :/ ).



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


Mime
View raw message