cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Date Wed, 08 Aug 2001 12:52:34 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?

Yes.  It also reduces the weight of each individual WAR file.

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

Pretty much.  The other goal is to remove the requirement of other libs in the
classpath during init time.

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

After thinking on this a bit, we may need to have a CocoonAPI.jar file that
has all the interfaces and avalon-framework.jar in the classpath--if for no
other reason than being able to build out client systems.  In that case,
we can use constructors.  The requirement for reflection stems from having all
the classes in a separate ClassLoader that we are directly manipulating.

>>5) calls initialize(Map)
>>6) calls getProcessor().process() with the Environment object for each request.
>>
> 
> How do you see the "cocoon-reload" is handled?

That is handled by the CocoonConfigurator object behind the scenes.  That logic
will be the same regardless of environment--unless you forsee something different.

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

Implementation in one jar, interface used in the various cocooncli/servlet/etc jars.


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


Mime
View raw message