geronimo-dev mailing list archives

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


Mime
View raw message