JNDI supports pretty much everything you need -- contexts (one per server/node/app/ejb/servlet/whatever) and an unlimited amount of configuration entries (poolsize, max thread, min thread).
And if the JNDI is going to be backed by Technology X, then that provides a way for users to administer the data directly. But a app configurator can just be based on reading/writing JNDI values.
JNDI also not only supports tree-like structures, but also references to other parts of the tree as well which would be ideal (for instance) to represent relationships like 'App Y is in node Z'
And lastly, XML extraction of a JNDI source would be a doddle, or even be backed by the JNDI-XML server (though IMHO a JNDI-DB server will be more scalable for read-write data synchronised across multiple nodes for clustering).
Can anyone think of a good reason why JNDI cannot/should not be used as /the/ place to store config information? That way, the server will only need one start-up parameter -- the JNDI server to connect to.
Alex.
PS Isn't this what Windows 2000 uses for its registry, and what Windows XP uses to mount its Active Directory? Certainly, Mac OS X is moving more towards a directory-managed approach (be it backed by LDAP or whatever) -- so why don't we do the same for Geronimo?
