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
