The discussion of a database (directory) vs. flat-file based configuration
made me recall all the horrors our development team had with both IBM
WebSphere and Sun IPlanet J2EE servers few years ago. As some of you might
know both of these had database/directory backed configuration.
Yes, but the initial releases of WebSphere hid a lot of it from you. As things moved on, they provided more interfaces to the repository, including the ability to pull out an XML-representation of the repository.
When you look at an J2EE server, this is not the case. There are many things to configure and the relationships between the entities are complex. Multiple entities belong to the same group and their configuration affect each other. Having the configuration in a format where you can only see a glipse of the whole at once is a bad idea.
This is why tools exist to pull out formats of the repository in known formats. However, managing relationships between naming services is in fact very easy; you simply have forward references to the components you are relating to.
Where WebSphere fell over was hiding this all from the end user. If we can provide a well-defined naming convention (in the same way as you might provide a well-defined XML schema) then these can become much less problematic.
With files you can easily take backups of the configuration and revert to
earlier configurations when something goes sour. As mentioned by others,
configuration files can be version controlled with, for example CVS. Also
fixing broken configurations (inconsistent links, etc) is much easyer with
file-based configuration.
This has been raised before a few times, with a couple of suggestions:
o Take backups of the registry storage itself. This can be done if the naming backend is a DB or even flat-file based. An advantage of taking a backup of the registry is that it's much faster to restore, and has all information encoded within.
o Export it to a text file and store that in CVS.
With both WebSphere (2.0 and 3.0) and Iplanet (don't remember the
version), the configuration database could easily be driven into an
incosistent state, from where the only way out was to re-install the whole
server and start from scratch. I have never seen this happen with
file-based configuration (WebLogic, JBoss, orion-server, etc).
I think that it's equally possible that you can get an XML file without a required entity, in much the same way that a repository can get into an inconsistent state.
Again, you raise an interesting point that should the repository be hosed/become inconsistent, then it's somewhat more problematic to get out of. I'm sure the same is true if a file format was used as well, but the key point is that it should be easy to recover from a hosed configuration, whatever the format of the configuration.
You might like to add your thoughts to the http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/Configuration pages.
Alex.
