You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/07/26 15:36:22 UTC
[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.
Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Posted by Berin Loritsch <bl...@apache.org>.
giacomo wrote:
> On Thu, 26 Jul 2001, Berin Loritsch wrote:
>
>
>>* New CocoonTask environment: Allows for a new Ant task to build documentation using cocoon!
>>
>
> This would be very cool :)
>
>
>>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.
>>
>
> You mean an approach similar to the <init-param> init-classloader we
> have today and a path (probably absolute) where the libs are?
Yes. It also reduces the weight of each individual WAR file.
>>3) Copies the initialization parameters into a Map (generic java object).
>>
>
> This is to generalize the ServletConfig (and any other environment
> specifiy configuration methods/objects) into simple name/value pairs?
Pretty much. The other goal is to remove the requirement of other libs in the
classpath during init time.
>>4) instantiates a CocoonConfigurator object using reflection.
>>
>
> I don't get why there seems the need for "using reflection". What
> different constructors do you have in mind for the different
> environments?
After thinking on this a bit, we may need to have a CocoonAPI.jar file that
has all the interfaces and avalon-framework.jar in the classpath--if for no
other reason than being able to build out client systems. In that case,
we can use constructors. The requirement for reflection stems from having all
the classes in a separate ClassLoader that we are directly manipulating.
>>5) calls initialize(Map)
>>6) calls getProcessor().process() with the Environment object for each request.
>>
>
> How do you see the "cocoon-reload" is handled?
That is handled by the CocoonConfigurator object behind the scenes. That logic
will be the same regardless of environment--unless you forsee something different.
>>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.
>>
>
> +1
>
>
>>8) the Servlet package, and the implementations for all the Http environment
>> classes get moved into a "cocoon-servlet.jar"
>>
>
> +1
>
>
>>9) the Main class, and the implementations for all the CLI environment classes
>> get moved into a "cocooncli.jar"
>>
>
> +1
>
>
>>10) the CocoonConfiguratorImpl class is the same for all environments and is
>> included in the "cocoon.jar" along with all the other cocoon classes.
>>
>
> If the CocoonConfiguratorImpl is used by all environments whats the
> benefit of having a interface as well?
Implementation in one jar, interface used in the various cocooncli/servlet/etc jars.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Giacomo Pati wrote:
>
> Quoting Sylvain Wallez <sy...@anyware-tech.com>:
>
<snip/>
> > > > 3) Copies the initialization parameters into a Map (generic java
> > object).
> > >
> > > This is to generalize the ServletConfig (and any other environment
> > > specifiy configuration methods/objects) into simple name/value pairs?
> >
> > I once proposed to be able to "externalize" some of the values in
> > cocoon.xconf using a substitution syntax like "${name}". The purpose is
> > to avoid modifying cocoon.xconf during deployment (e.g. jdbc URLs, cache
> > sizes, etc). It seems like these values could be fetched from these
> > initialization parameters.
>
> I don't see how this relates. The mentioned Map contains the name/values
> specified in the web.xml file. There is no such things like pool sizes, dburls
> etc.
>
OK, maybe I wasn't clear : I would like the ability of some component
configuration values to be expressed in web.xml or other name/value
pairs sources such as property files. The purpose is to be able to set
some configuration values related to deployment without having to touch
cocoon.xconf.
For example, this would allow the following :
In web.xml :
...
<init-param>
<param-name>personnel-db-url</param-name>
<param-value>jdbc:oracle:thin:@host:1521:sid</param-value>
</init-param>
<init-param>
<param-name>personnel-db-maxconnections</param-name>
<param-value>15</param-value>
</init-param>
...
In cocoon.xconf :
...
<datasources>
<jdbc name="personnel">
...
<pool-controller min="5" max="${personnel-db-maxconnections}"/>
<dburl>${personnel-db-url}</dburl>
</jdbc>
</datasources>
...
By (bad) experience, I know that there are some customers sysadmins that
install applications we've made for them who don't even know what a
valid XML file is ! They're skilled to the GUI of their application
server, but don't like manual editing of cryptic configuration files.
This feature would allow them to set the values for the configuration
that they have to set, and only these ones, without allowing them to
change values they shouldn't modify or break the whole app by
accidentally erasing a ">" in cocoon.xconf.
<snip/>
> > > Giacomo (yes, I'm back from vacation but still some hundered mails
> > > away from the head :/ ).
> >
> > Still on vacation, and it's still raining :(
>
> I feel sorry for you.
>
Thanks, but, well, it gives me some time to improve my Cocoon and Avalon
knowledge :)
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Sylvain Wallez <sy...@anyware-tech.com>:
>
>
> giacomo wrote:
> >
> > On Thu, 26 Jul 2001, Berin Loritsch wrote:
> >
> > > * New CocoonTask environment: Allows for a new Ant task to build
> documentation using cocoon!
> >
> > This would be very cool :)
> >
> > > 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.
> >
> > You mean an approach similar to the <init-param> init-classloader we
> > have today and a path (probably absolute) where the libs are?
> >
> > > 3) Copies the initialization parameters into a Map (generic java
> object).
> >
> > This is to generalize the ServletConfig (and any other environment
> > specifiy configuration methods/objects) into simple name/value pairs?
>
> I once proposed to be able to "externalize" some of the values in
> cocoon.xconf using a substitution syntax like "${name}". The purpose is
> to avoid modifying cocoon.xconf during deployment (e.g. jdbc URLs, cache
> sizes, etc). It seems like these values could be fetched from these
> initialization parameters.
I don't see how this relates. The mentioned Map contains the name/values
specified in the web.xml file. There is no such things like pool sizes, dburls
etc.
>
> > > 4) instantiates a CocoonConfigurator object using reflection.
> >
> > I don't get why there seems the need for "using reflection". What
> > different constructors do you have in mind for the different
> > environments?
> >
> > > 5) calls initialize(Map)
> > > 6) calls getProcessor().process() with the Environment object for
> each request.
> >
> > How do you see the "cocoon-reload" is handled?
> >
> > > 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.
> >
> > +1
> >
> > > 8) the Servlet package, and the implementations for all the Http
> environment
> > > classes get moved into a "cocoon-servlet.jar"
> >
> > +1
> >
> > > 9) the Main class, and the implementations for all the CLI
> environment classes
> > > get moved into a "cocooncli.jar"
> >
> > +1
> >
> > > 10) the CocoonConfiguratorImpl class is the same for all
> environments and is
> > > included in the "cocoon.jar" along with all the other cocoon
> classes.
> >
> > If the CocoonConfiguratorImpl is used by all environments whats the
> > benefit of having a interface as well?
> >
> > Sounds like a good plan to me.
> >
> > Giacomo (yes, I'm back from vacation but still some hundered mails
> > away from the head :/ ).
>
> Still on vacation, and it's still raining :(
I feel sorry for you.
Giacomo
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
giacomo wrote:
>
> On Thu, 26 Jul 2001, Berin Loritsch wrote:
>
> > * New CocoonTask environment: Allows for a new Ant task to build documentation using cocoon!
>
> This would be very cool :)
>
> > 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.
>
> You mean an approach similar to the <init-param> init-classloader we
> have today and a path (probably absolute) where the libs are?
>
> > 3) Copies the initialization parameters into a Map (generic java object).
>
> This is to generalize the ServletConfig (and any other environment
> specifiy configuration methods/objects) into simple name/value pairs?
I once proposed to be able to "externalize" some of the values in
cocoon.xconf using a substitution syntax like "${name}". The purpose is
to avoid modifying cocoon.xconf during deployment (e.g. jdbc URLs, cache
sizes, etc). It seems like these values could be fetched from these
initialization parameters.
> > 4) instantiates a CocoonConfigurator object using reflection.
>
> I don't get why there seems the need for "using reflection". What
> different constructors do you have in mind for the different
> environments?
>
> > 5) calls initialize(Map)
> > 6) calls getProcessor().process() with the Environment object for each request.
>
> How do you see the "cocoon-reload" is handled?
>
> > 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.
>
> +1
>
> > 8) the Servlet package, and the implementations for all the Http environment
> > classes get moved into a "cocoon-servlet.jar"
>
> +1
>
> > 9) the Main class, and the implementations for all the CLI environment classes
> > get moved into a "cocooncli.jar"
>
> +1
>
> > 10) the CocoonConfiguratorImpl class is the same for all environments and is
> > included in the "cocoon.jar" along with all the other cocoon classes.
>
> If the CocoonConfiguratorImpl is used by all environments whats the
> benefit of having a interface as well?
>
> Sounds like a good plan to me.
>
> Giacomo (yes, I'm back from vacation but still some hundered mails
> away from the head :/ ).
Still on vacation, and it's still raining :(
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Posted by giacomo <gi...@apache.org>.
On Thu, 26 Jul 2001, Berin Loritsch wrote:
> * New CocoonTask environment: Allows for a new Ant task to build documentation using cocoon!
This would be very cool :)
> 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.
You mean an approach similar to the <init-param> init-classloader we
have today and a path (probably absolute) where the libs are?
> 3) Copies the initialization parameters into a Map (generic java object).
This is to generalize the ServletConfig (and any other environment
specifiy configuration methods/objects) into simple name/value pairs?
> 4) instantiates a CocoonConfigurator object using reflection.
I don't get why there seems the need for "using reflection". What
different constructors do you have in mind for the different
environments?
> 5) calls initialize(Map)
> 6) calls getProcessor().process() with the Environment object for each request.
How do you see the "cocoon-reload" is handled?
> 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.
+1
> 8) the Servlet package, and the implementations for all the Http environment
> classes get moved into a "cocoon-servlet.jar"
+1
> 9) the Main class, and the implementations for all the CLI environment classes
> get moved into a "cocooncli.jar"
+1
> 10) the CocoonConfiguratorImpl class is the same for all environments and is
> included in the "cocoon.jar" along with all the other cocoon classes.
If the CocoonConfiguratorImpl is used by all environments whats the
benefit of having a interface as well?
Sounds like a good plan to me.
Giacomo (yes, I'm back from vacation but still some hundered mails
away from the head :/ ).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
Posted by Berin Loritsch <bl...@apache.org>.
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
RE: [Proposal: C2.1] Split CocoonServlet from Cocoon
Posted by John Morrison <jo...@ntlworld.com>.
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: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