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.
Thoughts?
J.
> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 26 July 2001 2:36 pm
> To: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
