directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ersin ER <>
Subject Re: ApacheDS ConfigNG
Date Wed, 18 Mar 2009 19:27:59 GMT
One of the things we should consider for a configuration mechanism is that
whether this configuration format is for humans or is for tools. If it's for
humans neither XML nor LDIF are good candidates. If it's for tools, both are
fine and then there can be other criteria to select one or also both can be
supported. I don't think one if superior to other in terms of

On Wed, Mar 18, 2009 at 21:22, Emmanuel Lecharny <>wrote:

> David Jencks wrote:
>> A couple comments...
>> 1. in your list below there are at least 2 kinds of "type" info for the
>> parameters: known types (int) and objects where the main choice is which
>> class you use to implement an interface (Interceptor). I think these are
>> sort of qualitatively different but that is not clear from your notation.
>>  As a sub-comment I don't know how you'd specify the implementation class
>> for a component in DIT but this is probably my own ignorance.
> You're right : I forgot to give some clues to understand the list... So
> here they are :
> - Standard values (ie, Java types) don't have any + or * in front of them
> - Complex objects (ie objects which are defined somewhere else in the
> project have a '+'
> - Collections of Objects have a '*'. If it's a collection of complex
> object, then the class is given
>> 2. Despite the unpleasantness of getting poked by all the pointy brackets
>> in xml it does make it pretty easy to express the tree structure of wired
>> together components in an easy to understand way.  It's much less good at
>> showing non-tree graphs (you have to use some kind of reference).  I think
>> this is pretty useful information that AFAIK would be completely obscured in
>> a DIT configuration model.  On the other hand this wiring info is mostly
>> useful for advanced users that need to assemble a custom server; people
>> using a more or less plain server probably only need to change a few
>> "primitive" parameters.
> IMO, the ConfigurationNG should be agnostic. Ie, I don't really mind if
> someone want to define a configuration using Spring, as soon as it has no
> impact on the code. For instance, OpenLDAP stilll have to ways to see the
> configuration : as a big slapd.conf property file, and as a config in the
> DiT (LDIF with sub-directories where you can find the children).
> Regarding the config in the DiT, the biggest advantage is that you keep the
> hierarchical vision, as LDAP is hierarchical. So you get the Tree structure
> for free. What is a bit more problematic is the attributeType you may have
> to define. OpenLDAP have created one AttributeType per object. here is an
> example :
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcArgsFile: /var/run/slapd/slapd.args
> olcLogLevel: sync
> olcPidFile: /var/run/slapd/
> olcToolThreads: 1
> structuralObjectClass: olcGlobal
> olcServerID: 1
> (this is for the root configuration)
> We can also define one single AttributeType, and use options. Something
> like :
> dn: cn=replicationPerrConfig,cn=ldapService,cn=config
> objectClass: adsConfig
> cn: replicationPeerConfig
> adsConfig;interval: 30000
> adsConfig;password: secret
> adsConfig;principalDN: uid=admin,ou=system
> adsConfig;producer: ldap://localHost:10489/dc=example,dc=com
> adsConfig;refreshOnly: true
> This is just an option. It might be better to define attributeTypes for
> each parameter (I see two advantages to do so : (1) you can define the AT
> syntax and (2) you won't have a confusion between two AT with the same name)
> For composite Objects (for instance, in a Server, we define a Transport, it
> can be done using a DN pointing to the associated transport.
> In any case, there is no real problem to express the full server
> configuration using this notation.
> But we will have to define something we had in ancient age, a
> ServerConfiguration bean which will be in charge of loading the
> configuration. The fact is that we decided (O tempora, O mores ...) to
> replace it by Springshlplut... We were lazzy and in a hurry, and didn't
> resisted enough. That's our mistake. Anyway.
> If we have this configuration bean back, then it should be easy to
> implement a configuration reader based on the DIT, a propertyFile, JSon, XML
> or even Spring with xbeans !
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny

Ersin ER

View raw message