You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by giacomo <gi...@apache.org> on 2001/08/07 23:08:26 UTC
Re: [Proposal: C2.1] Split CocoonServlet from Cocoon
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>.
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