cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [Proposal: C2.1] Split CocoonServlet from Cocoon
Date Thu, 26 Jul 2001 13:36:22 GMT
First let describe the problem:

* Servlet Containers differ: the classloaders and the list of packages
                             in each classloader cannot be easily predetermined,
                             nor can a special case be applied for each one.

* Duplication of libraries: In it's current state, Cocoon must have a copy of
                            all libraries in each webapp context.  Many times
                            it is better to install it once (like an application),
                            and have the servlet reference the lib directory.
                            This also reduces the weight of a WAR file (currently
                            10-13 MB)

* Library management: If you have 5 contexts filled with all the libraries, performing
                      upgrades to all 5 contexts can be daunting--you may even miss
                      a library or two.

What the solution provides:

* The Cocoon environment is standard: You are always working with a known classloader
                                      with known abilities.  You are always accessing
                                      the libraries you desire.

* One location for libraries: You know have the ability to install Cocoon once, and
                              reference the libraries from as many contexts as you like.
                              each context has it's own classloader.  Also, you are not
                              locked into that approach--you MAY specify another directory
                              in your context to load the libraries from.

* Library management: When all the libraries are in one place, you automatically upgrade
                      all contexts that reference the libraries.

* Application of Filters:  The servlet can be extended to implement Servlet 2.3 compliant
                           filters that will allow you to handle HttpServletRequest object
                           substitution, etc.  That means that the deployer has control over
                           whether we use MaybeUpload or com.oreilly for binary uploads.

* Separation of environment: The Cocoon code works the same no matter what.  The method of
                             specifying environments is tied to the environment package.
                             separating the environment code and the cocoon code allows
                             for easier creation and maintenance of the different environments
                             apart from the Cocoon project (easier embeddability in unknown

* New CocoonTask environment: Allows for a new Ant task to build documentation using cocoon!

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.
3) Copies the initialization parameters into a Map (generic java object).
4) instantiates a CocoonConfigurator object using reflection.
5) calls initialize(Map)
6) calls getProcessor().process() with the Environment object for each request.
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.
8) the Servlet package, and the implementations for all the Http environment
   classes get moved into a "cocoon-servlet.jar"
9) the Main class, and the implementations for all the CLI environment classes
   get moved into a "cocooncli.jar"
10) the CocoonConfiguratorImpl class is the same for all environments and is
    included in the "cocoon.jar" along with all the other cocoon classes.
View raw message