directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: Simplified server configuration with xbean-spring
Date Fri, 06 Jul 2007 12:10:31 GMT
Hi Dave,

I have not spent much on this thread so I may not be up to date however I
think I can answer
some of your questions below.

On 7/3/07, David Jencks <> wrote:
> On Jul 2, 2007, at 11:55 PM, Emmanuel Lecharny wrote:
> > Hi guys,
> >
> > sorry for the "deafening silence" ... We were quite busy those last
> > days, up to a point we let this important mail dying silently ...
> >
> > ok, I agree with David that the current server.xml is, to say the
> > least, not very easy to handle, as it does not carry a lot of
> > semantic.
> >
> > Now, from our users perspective, we have two problems :
> > 1) current users don't manipulate a lot this file, as you don't fix
> > something which work, as soon as it's complicated to male it work
> > again, due to the complexity of the current configuration file ( kind
> > of circular situation ... )
> > 2) new users are simply afraid to touch this configuration file,
> > because it's too complex...
> >
> > We have two ideas to help solving those problems :
> > 1) Apache Directory Studio contains a GUI which helps to manupulate
> > this file. Not sure that users are aware of that ...
> > 2) we really want to move almost all of this configuration into the
> > DIT in the next few months, so that we will be able to avoid having
> > such a massive configuration file
> >
> > The second solution will obviously be coupled with a new version of
> > the first one.
> >
> > I would add that there is no good solution to such a problem. We went
> > from property file to spring configuration because the property file
> > was ugly and didn't carried enough semantic. Now it's the same problem
> > again. Pushing all the configuration into the DIT won't add extra
> > semantic... This is a dead end. Wat I would suggest in this case is
> > the least we change the configuration, the more likely users will get
> > used with it. And I pretty much favor a move to the DIT for the sake
> > of completeness : using LDAP to manage itself.
> >
> > Let's face the reality : whatever level of semantic you add to a
> > configuration file, you will _always_ need a good doco and nothing
> > will replace the RTFM credo...
> Having a grammar for the config helps a lot in my experience.  xml
> schema is the only grammar language I'm familiar with that is
> reasonably comprehensible and has a lot of easily available grammar-
> aware editors.  I think writing your own language and tools to edit
> it may not necessarily make a lot of friends.
> I don't understand a couple details of this plan...
> - Isn't there a bootstrap or chicken/egg problem with getting a
> server to the point of being able to read its own configuration?  Or
> is the plan to bootstrap a simple server with no external
> connectivity, use it to read the config and start the real server,
> and then throw it away?

Something like that. The thing is you don't start the entire server but just
up the system partition to look up the configuration.

- Does this mean that the spring xml files or xbean-spring xml file
> will be replace by a server.ldif file, in terms of being able to edit
> the configuration?  Or is the plan to force anyone who want to look
> at or modify the server config to fire up Apache Directory Studio?
> It's hard for me to see either of these as an advance over editing
> even the current server.xml files.  Being able to edit the server
> config in vi or emacs has its advantages.
> - Is the plan to completely ditch spring and write your own wiring
> framework?

I'd like to load the configuration out of the DIT and not bother with spring
at all.


View raw message