Hi Cocooners,
While deploying a C2 application, I identified what seems to me a mixing
of concerns in cocoon.xconf. Below are those concerns definitions and a
proposal to separate them and ease the deployment of C2 applications.
Cocoon.xconf describes the whole configuration of the components that
compose the system : cache, url resolvers, markup-to-code engines (XSP
and Sitemap), database pools, etc.
The configuration elements in cocoon.xconf can be classified in two
categories :
- Structural configurations
These define the actual components used (through the roles or class
names) and their operating modes (e.g. autocommit mode for jdbc
connections). These result from design choices made by the application
developer and changing them can greatly alter or break the application
function.
- Runtime (or deployment) parameters
This is what defines the running parameters for the components defined
in the structural configuration. This is for example jdbc urls, cache
sizes, and so on. These parameters can be tuned to optimize performance
or availability according to the actual hardware/software deployment
environment, but changing their value does not break the application.
To illustrate this, let's consider the following cocoon.xconf snippet :
<stream-cache class="org.apache.cocoon.caching.StreamMemoryCache">
<parameter name="freememory" value="1000000"/>
<parameter name="heapsize" value="60000000"/>
<parameter name="objectlifetime" value="300"/>
<parameter name="interval" value="10"/>
<parameter name="maxobjects" value="100"/>
<parameter name="usethread" value="false"/>
<parameter name="threadpriority" value="5"/>
</stream-cache>
<event-cache class="org.apache.cocoon.caching.EventMemoryCache">
<parameter name="freememory" value="1000000"/>
<parameter name="heapsize" value="60000000"/>
<parameter name="objectlifetime" value="300"/>
<parameter name="interval" value="10"/>
<parameter name="maxobjects" value="100"/>
<parameter name="usethread" value="false"/>
<parameter name="threadpriority" value="5"/>
</event-cache>
<datasources>
<jdbc name="personnel">
<pool-controller min="5" max="10"/>
<auto-commit>false</auto-commit>
<dburl>jdbc:hsqldb:${install.war}/cocoon/WEB-INF/db/cocoondb</dburl>
<user>sa</user>
<password></password>
</jdbc>
</datasources>
We clearly see the two types of configuration intermixed : the cache
class names and jdbc autocommit are structural, while memory sizes and
jdbc url are deployment parameters.
The good thing in cocoon.xconf and the Avalon Configuration is that it's
located in a single file. Moreover, a component doesn't have to make a
difference between structural and deployment parameters, and this is
really important considering that the notion of runtime parameter may
depend on the application or the context in which it is deployed.
So, in order to cleanly separate structural configuration and
deployement parameters without impacting the current configuration
system, we should be to be able to "outsource" those parameters from
cocoon.xconf.
To achieve this, I propose to augment the current syntax of the
configuration to allow parameter substitution, using the now classical
"{param}" notation already used in many places in Cocoon (sitemap, i18n
transformer, XSL). There's a premise of that in the above snippet with
"${install.war}" which is resolved by the ant built process (and
therefore uses the Ant syntax).
This mechanism allows to export out of the configuration only the
parameters whose export is relevant from a given application point of
view.
Our cocoon.xconf snippet could then become :
<event-cache class="org.apache.cocoon.caching.EventMemoryCache">
<parameter name="freememory" value="{cache.freememory}"/>
<parameter name="heapsize" value="{cache.heapsize}"/>
<parameter name="objectlifetime" value="300"/>
<parameter name="interval" value="10"/>
<parameter name="maxobjects" value="100"/>
<parameter name="usethread" value="false"/>
<parameter name="threadpriority" value="5"/>
</event-cache>
<stream-cache class="org.apache.cocoon.caching.StreamMemoryCache">
<parameter name="freememory" value="{cache.freememory}"/>
<parameter name="heapsize" value="{cache.heapsize}"/>
<parameter name="objectlifetime" value="300"/>
<parameter name="interval" value="10"/>
<parameter name="maxobjects" value="100"/>
<parameter name="usethread" value="false"/>
<parameter name="threadpriority" value="5"/>
</stream-cache>
<datasources>
<jdbc name="personnel">
<pool-controller min="5" max="10"/>
<auto-commit>false</auto-commit>
<dburl>{personnel.url}</dburl>
<user>{personnel.user}</user>
<password>{personnel.password}</password>
</jdbc>
</datasources>
What we can see in this revised snippet is that we have chosen to export
database connection info, but not the pool size, and that stream and
event caches share the same memory configurations which can be tuned
externally, but not the object lifetime and other parameters which the
developper chose to kept fixed.
Handling of this syntax can be done with a Parameterizable subclass of
Avalon's DefaultConfiguration that transparently substitutes parameters
in attributes and values.
Now where do these runtime parameters come from ? In servlet
environment, we can fill a Parameters object with the servlet init
parameters. In command line environment, we can build a Parameters
object from command line parameters or from a properties file also
specified as a command line parameter.
I like all this because it offers much control in the choice of runtime
parameters. Also, it allows the deployer to use the tools provided by
the servlet container (or the web.xml file) to configure the
application, whithout having to scroll through a lengthy and obscure
(for him) xml file which could easily be accidentaly damaged (believe
me, I've seen customers sysadmins that were deploying our apps but
didn't know about XML syntax).
Thoughts, comments ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
