cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Morrison" <>
Subject RE: [Proposal: C2.1] Split CocoonServlet from Cocoon
Date Thu, 26 Jul 2001 19:07:35 GMT
Could Cocoon not be positioned as an alternative to Jasper and be coded as a
plug-in substitute?  A combination of information in the web.xml and a
flow-map would control it's ability for each context/webapp?  My only
concern then would be it's scalability.  In it's current configuration it's
easy to ensure scalability by creating another context/webapp which handles
some of the load (ie 2 (or more) cocoons), if there is a move to only one
(which is good from a disk size/management/memory point of view) then it
_must_ scale well.



> -----Original Message-----
> From: Berin Loritsch []
> Sent: Thursday, 26 July 2001 2:36 pm
> To:
> Subject: [Proposal: C2.1] Split CocoonServlet from Cocoon
> 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.

To unsubscribe, e-mail:
For additional commands, email:

View raw message