geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: One True Way (TM) of handling configuration files
Date Fri, 08 Aug 2003 17:29:25 GMT
> 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.


View raw message