directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: ApacheDS ConfigNG
Date Wed, 18 Mar 2009 19:22:23 GMT
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/slapd.pid
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
www.iktek.com
directory.apache.org



Mime
View raw message