cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Date Thu, 26 Jul 2001 19:17:01 GMT
John Morrison wrote:
> 
> 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.

That was not my intention in the proposal.  My proposal does not change the
number of instances of Cocoon, nor does it change the servlet contracts.  It
merely protects Cocoon from unknown environments, and eases management when
there is a large number of sites with Cocoon installed.

Replacing a Servlet Container vendor's JSP implementation is highly vendor
specific--so it is not what we want to accomplish.  Besides, Cocoon does much
more than Jasper or JSP in general.

> 
> Thoughts?
> 
> J.
> 
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Thursday, 26 July 2001 2:36 pm
> > To: cocoon-dev@xml.apache.org
> > 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Mime
View raw message