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