Hi All,

My personal experience with the current server.xml has been while producing my 
own distribution of ApacheDS with some of my own custom interceptors and 
partitions.  I found it very powerful and being able to play around with the 
low level structure of ApacheDS without making changes to the source was very 
useful.  For distribution however, I am making my own configuration file format 
which will only offer our users the ability to change basic options such as 
administrator password and listening port number.  The distribution is for a 
very specific purpose and the users should not be messing around with the 
internals.  The server.xml will still be there but it will be hidden away as 
just another data file rather than something the user is expected to edit.

I wonder if ApacheDS itself shouldn't be doing the same thing?  If a systems 
administrator just wants an LDAP server they shouldn't have to be editing a 
large XML file with lots of low-level implementation details such as the 
ordering of interceptors.  Perhaps we should have a simple configuration file 
for administrators that just want to get a server up and running, and a 
separate one for developers that gives the full power of the current server.xml.

To me the xbeans make the file a little easier to read but I think the biggest 
problem is the structure and sheer amount of configuration that we make 
available.

As for moving the configuration into the DIT - I think that would be great as 
it would instantly give several nice features: global configuration for all 
replicas, a way to manage the server remotely, and possibly "live" 
configuration (no restart required).  I do, however, agree with others that 
this would be losing the ability to hand edit if things go wrong and makes it a 
little harder to backup.

Perhaps we could have a configuration partition which reads from / writes to 
the XML configuration file(s)?  I think the XML configuration files could map 
almost directly into LDAP entries.  I think this would give us the best of both 
worlds.

Cheers,

Martin



Reply via email to