On deployment, the running configuration would be determined by: 1) the configuration in the repository 2) the configuration in the deployment unit 3) per-server defaults[1] 4) per-domain defaults[1]
I think a big question which has to be answered before picking up these changes is: how is the configuration repository going to work? IMHO storing a single config file in an XML file may result in a file easier for humans to read (and, for that matter, servers to process) but /really/ breaks down when you've got to manage changes. Even simple things like installing a new app can be a big headache when the config file is a file.
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)
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?
o Would you need to restart the server and/or dump the new config file to see the effect?
Ideally, the server should just be able to start w/o any forms of configuration, and then for the rest of the configuration to be managed dynamically. My preference, esp. for distributed clusters, would be to use some kind of central repository config that elements interacted with, and for that to be backed by some kind of DB. That way, the DB can be replicated across multiple machines, edited synchronously and minor changes won't need huge restarts.
Of course, the config may be seeded by/extracted as an XML document, but I don't think that necessarily having the config stored as an XML file is necessarily the right way to go.
Alex.
