directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: Spring config / Config in DIT
Date Thu, 12 Jul 2007 06:09:21 GMT
Well, what I was thinking was storing a representation of the XML in
DIT, instead of the raw XML. So I think it may be better to use the
DIT as a configuration store for Spring (as they also support Java
Configuration files for example).

BTW, I like Spring too!

On 7/12/07, Chris Custine <> wrote:
> This is basically a response to some of the other threads regarding
> server.xml and Config in DIT, but I don't want to derail those threads if
> this turns out to be a stupid idea.
> I have been thinking about this for a while, and I have to admit that I am
> one of the guys that likes Spring and the xml config files.  Because of that
> I have been thinking about possible interim steps so that we can get a good
> grip on the needs and wants of the users while still solving some of our
> internal problems that we want to address in the short term.  Based on the
> recent threads about this topic, I get the distinct feeling that we might be
> underestimating the affect this subject has as far as user impact and user
> preferences and stand a good chance of irritating some people.
> My latest idea seems really obvious the more I think about it...  For the
> time being, why don't we just move towards storing the server.xml in its
> entirety as a string attribute under ou=system somewhere and restructure the
> startup sequence to properly read and load the Spring context from there?
> This sounds crazy, but bear with me for a moment...  This would give us the
> ability to "configure in DIT" so to speak, but would also expose some really
> interesting options for remote configuration, like modifying the current
> Apache DS Configuration plugin that Pierre-Arnaud has already written to
> just read from and save to the server it is currently connected to.  We
> could also do an interceptor or something similar on the server to write the
> file out to disk after a remote edit and allow a startup option or quick
> command line script to load a new file after you edit it in vi or similar.
> This CLI could even put the data directly to the JDBM tables so that you can
> make edits without the server running.
> I have a couple of reasons for bringing this to the table.  First of all, I
> am one of those dirty, sadistic perverts that likes editing xml files by
> hand as opposed to many other forms of config...  xml is like a second
> language to me  :-)
> Second and most importantly for ApacheDS, is that an approach like this will
> give us a great short term benefit of remote config and admin capability,
> without all of the work.  The server config editor that PAM wrote looks
> fantastic to me and (hopefully) we can just extend the concept and hack it
> to do what is needed for this without re-writing all of it.  This way we can
> do the Config in DIT in an incremental fashion and possibly save some grief
> that we may encounter later.  We will also be able to move on more quickly
> to more serious tasks and implement high visibility features.
> I am sure there are some technicalities that may be obstacles to this
> idealistic approach, but I have had worse ideas, so I thought I would bring
> it up and present it.  What do you guys think?
> Thanks,
> Chris

Ersin Er

R.A. and Ph.D Student at the Dept. of Computer Eng. in Hacettepe University

Committer and PMC Member of The Apache Directory Project

View raw message