> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 26 July 2001 8:17 pm
> To: [EMAIL PROTECTED]
> Subject: Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
>
>
> 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.
Yeah, I understand - just thought I'd throw it in for conversation ;)
> 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.
I'm developing on Catalina and deploying on (ATM) ServletExec3.1 with the
_possiblity_ of migrating the deployment platform to iPlanet (needs _lots_
more investigation). Basically, what I'm trying to say, is that _anything_
to increase portability would be welcomed. SE3.1 is _seriously_ messed up
with classloaders (unfortunately I've no choice what I deploy too).
> Replacing a Servlet Container vendor's JSP implementation is
> highly vendor
> specific--so it is not what we want to accomplish.
Fair enough. Just thought it could have been a nice idea ;)
> Besides,
> Cocoon does much
> more than Jasper or JSP in general.
Tell me about it ;D
If it's something I can help with I will. I *did* like the proposal.
>
> >
> > 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]
>
=======================================================================
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other commitment through the use
of this email.
Experian Limited (registration number 653331).
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
