cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist ...@wrinkledog.com>
Subject Re: best practice for configuration
Date Fri, 24 Nov 2006 19:08:35 GMT

On Nov 23, 2006, at 3:14 PM, Eiko Thomas wrote:

> [...snip] I'm also interested how do you handle this problem in your 
> application?

Here's my approach:

1) I have an application-specific config/ directory at the same level 
as webapp/, which is not an "updateable" part of the project.  Since I 
use Subversion for my projects, for me this means that config/ is 
uncontrolled.  If you are not using Subversion you can probably adapt 
this approach just by locating your "config/" outside of whatever you 
consider your application to be (e.g. the directory structure in a 
tarball, or whatever).  In order that I keep some formal knowledge of 
what config/ is "supposed" to look like, I maintain a "template" config 
directory, called "config.tmpl/", as a Subversion-controlled resource, 
also at the same level as config/.  Then, if I want to build a new 
instance of the product, I "svn checkout" the tree, then cd into it and 
do "svn export config.tmpl config" — voilà, there's my config/ 
directory, and I can edit the contents to customize this instance of 
the application.

2) I think it's desirable, as far as it is possible, to use a single 
configuration mechanism for all configuration items.  It's 
simpler/cleaner that way.  So, this mechanism must be the most flexible 
available, which I decided was (but see below :-)... Java properties.  
I therefore use properties files in config/ for almost everything.  
Then these can be referenced by Java code (I use Jakarta Commons 
Configuration for this, BTW... makes things smoother) — and they can 
also be referenced from the sitemap by configuring the appropriate 
PropertiesFileModule(s).  Note that (a) if you like XML instead, you 
can put the XML config files here and use XMLFileModule; (b) if you are 
using Commons Configuration to configure the Java bits, I think using 
XML config files instead of  properties files (or in addition to them) 
is pretty transparent; and (c) My thinking that properties are the most 
flexible is probably wrong, it's really XML, and so I should probably 
have gone the XML way instead.  Or (d) it doesn't really matter, use 
either or both :-)

3) Of course there are some things that can't be represented as 
properties... typically because they are XML.  So there are a few XML 
files in config/, but (in my current practice — see above) anything 
that can be a property is a property.

4) webapp/ contains a symbolic link to ../config to make config/ 
visible from within the webapp context.

I think that's it, HTH... :-)
—ml—


Mime
View raw message