From an administrator's PoV, it would be nicer if all configuration could be done via an admin console, and for the repository to be stored in a not-necessarily-human-readable form which was updated as the config was changed via the admin console (e.g. Web app)
While this may be a matter of some personal preference, I tend to like config files over an admin cosole/webapp. Being able to administer/maintain via a command line is imporant to me.
I'm not sure that the two are incompatible. You can configure a repository-based system using command-line tools as well; just ones that are provided for you rather than vi/sed/whatever.
The big problems with XML files as I see them are:
o How would an XML file be treated if the server had to re-generate its config file (because administrator(s) made a remote change )?
o How would changes that a text editor made to an XML file be re-read by a config file?
When I was working on a wireless app server a couple of years ago, we always maintained application state via and XML file. Basically all our admin cosole was was a fancy way to retrieve the XML file the server/cluster was currently using, edit it, and push it back. We also had a command line utility that let you edit the XML files, then force the server to restart the application with the new config. It worked pretty well. We just persisted everything back to the filesystem on the servers when there was a change, and downed/re-inited the relevant systems in the application.
That's pretty much the problem with XML-based files; that's the /only/ way to do it, and it generates some ugliness. For one, it means that you have to be very careful when multiple administrators are using the file (and/or editing it on disk) at the same time. Not an issue for small systems where there's only one administrator (or developer), but across a system with multiple administrators these deficiencies may be magnified.
Thus, I propose that you can make a much better admin console (and command line tools to support batch changes) but without the file-backed system.
o Would you need to restart the server and/or dump the new config file to see the effect?
I should hope not. :) The system should be able to down/restart an app without the whole server bouncing.
Yes, but what about simple changes? Would you have to bounce an app to update it to use a new DB/PW, for example? What would happen to users that were logged into that app (i.e. had HttpSession state) whilst you bounced it? I've had conversations with administrators who complained with some early J2EE servers that the only way of picking up some changes was to bounce the app, which logged all the users off. Not great for trivial changes.
These are the sort of things I hope we can avoid, regardless of what kind of back-end-configuration-repository is used.
Alex.
