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
environments).
* 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.
S/MIME Cryptographic Signature
