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—
