One of the big challenges is to configure Cocoon when the same
application is used in different environments. For example when each
developer uses his own database.
With 2.2 things get easier: first, the big cocoon.xconf is split into
various little parts that can be handled more easily. But that allone
doesn't really help. There are more configuration values hidden in web.xml.
So I have the following suggestion that I already implemented as a
prototoype:
a) Use of properties in all xconf files. If you write ${my.property}
then this is replaced during loading of the xconf with the actual
value of the property. - for compatibility, if there is no value
for this property, the reference is left in place.
There are different ways to specify properties as you will see soon,
for now this is just a system property: so if you start Cocoon with
-Dmy.property=something it gets replaced.
b) The web.xml is imho a bad place for Cocoon configurations as these
are not very visible, and even more important you don't have a
web.xml in other environments like the cli. So you end up with
different places for configuration for different environments.
To solve this I added a property configuration mechanism, so every
configuration value (that is not servlet specific) can be configured
in a properties file.
Cocoon uses the following sources to detect properties:
- First the resource "cocoon-settings.properties" is read from the
classpath. This is the location were we can define all the default
values. It's better to have default values in a separate file than
somewhere hidden in the Java source.
- Second, the configuration from web.xml is read and this overrides
values from the first phase (only for servlet env of course).
- Third, if a system property "org.apache.cocoon.settings"
is specified, the appropriate file is read and settings from here
override those of the two preceeding phases.
- Finally system properties are evaluated and may define the final
configuration value.
Example:
cocoon-settings.propeties:
org.apache.cocoon.allow.reload=false
org.apache.cocoon.configuration=/WEB-INF/cocoon.xconf
web.xml:
parameter for allow-reload with the value "false"
System Property on startup: -Dorg.apache.cocoon.allow.reload=true
Then the allow-reload is set to true as the system properties have
the last saying.
With this dynamic property configuration, it's easy to configure
Cocoon for different environments. Each developer can start Cocoon
with his own settings without changing the configuration files.
With the second option from above, each developer can have his own
properties file overriding specific values, so there is no need to
specify all properties as system properties on startup.
c) Next to the settings of Cocoon, all property files can have
additional properties, for example:
myapplication.databaseurl=jdbc://
All these properties, defined as system properties or in the property
files read by Cocoon, can be used in the xconf files, so
you can just write ${myapplication.databaseurl} and it get's
properly replaced.
Now, I think this is a very handy feature: each developer just has his
own configuration file with his local settings and specifies this on
startup and things like database connections etc. are properly replaced.
There is no need to hand edit the configuration files anymore.
In addition, if you just want to change a value for testing, specify
it on startup. Just try starting Cocoon with
-Dorg.apache.cocoon.allow.reload=true
and the cocoon.xconf get's reloaded (ok, there's the ehcache problem).
Internally, I created a new bean: the settings object that holds all the
core configuration. The settings can be seen by the status generator and
are logged (using DEBUG log level).
All names for the properties are defined in the Settings file; I just
randomly choose some names; I guess they need some cleanup.
I implemented this as a prototype for the servlet environment, the other
environments are a todo.
So, WDYT?
