Don't assume that a bad implementation invalidates the idea of a registry-based system. Websphere 2.0 and 3.0 had... well, 'issues' is probably the diplomatic word to use. ;) Check out the Wiki - Alex Blewitt has put together a couple of pages describing the pros and cons of flat files and registers for storage of config information, and there might be some ideas there you hadn't considered. Even if there aren't, you can probably add some insight to them.
Providing a mechanism for translating between registry and flat file format (a la xmlconfig in Websphere) addresses some of the complaints people have with the registry model (such as allowing it to be managed by CVS). Adrian -----Original Message----- From: Heikki [mailto:[EMAIL PROTECTED] Sent: 12 August 2003 11:43 To: [EMAIL PROTECTED] Subject: Re: [JNDI] [Config] Configuration: flat file or registry? Hi all, I have just joined the list and have had only little time to browse through the list archives. 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. Directory is good for many things. As have been pointed out in this discussion already, user information in many UNIXes (Linux PAM) has been successfully transferred from /etc files to directories. How ever, user information is quite simple when compared to J2EE server configuration. There's only two datatypes (user, group) both very simple and the relations between these to datatypes are very simple. And there's no need to look at multiple users at once. 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. 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. 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). Heikki Vesalainen, Mermit : GSM +358.50.3695362 : [EMAIL PROTECTED]
