cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject [RT] Configuring Cocoon
Date Wed, 16 Feb 2005 17:28:40 GMT
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?

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/




Mime
View raw message