directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Configuration again ...
Date Sat, 16 Oct 2010 00:11:19 GMT
  Hi guys,

considering we want to store the config the way Stefan suggested, ie :
> DirectoryService
> ->  Partitions
>      ->  Indexes
> ->  Journal
> ->  Changelog
> ->  Servers
>      ->  LdapServer
>          ->  Transports
>          ->  Replication consumer
>          ->  Replication provider
>      ->  KerberosServer
>      ->  ...
we will need some refactoring in the config OC ad DIT structure.

For instance, for a specific DS (with a specific ID), we will have the 
following DIT :

ou=config being the root for all the configuration

The ads-directoryServiceId=myDS.ldif file will contain all the config 
for myDS DS, except the data stored into the ads-directoryServiceId=myDS 

In this directory, as myDS will have partitions, interceptors, servers, 
we will have :


the ldif will contain all the elements for the journal, changeLog and 
passwordPolicy, and they are LDIF files because the DS OC has those 
elements as SINGLE-VALUED ATs. For the partitions, servers and 
interceptors, as they are MULTI-VALUED, we have one intermediate level, 
described by the ou=ads-servers, ou=ads-partitions and ou=ads-interptors.

the so rule is quite simple :
- if a Bean OC has single valued composite AT, like Journal or 
ChangeLog, then the associated informations are stored into a ldif file 
one level  below.
- if a Bean OC has multi-valued composite AT, like partitions or 
interceptors, then we will find the associated ldif files under an 
ou=<attributeName> branch, so 2 levels below. as we store the ID of such 
elements, it will be easy to retrieve them with a lookup.

For instance, we have a LdapServer which id is "myLdapServer", then the 
DIT will look like :

       ads-server=myLdapServer/     --> there will have some more entries
       ads-server=myLdapServer.ldif --> the entry containing the config 
for the myLdapServer instance

This will be the same thing for all the components.

Note that we deduce the DN by concatenating the AT name (ads-server) 
with the server id (myLdapServer), so this work can be done through 

One slight issue is that we have to know if an AT is a component or a 
simple type (String, int, long or boolean). If we store the ID, then we 
have three options :
- check in the DIT to see if we have some entries having the given ID 
- define a specific AT for components (which can be inherited by the 
composite AT), so if the AT has this specific SUP, then we know it's a 
component. For instance, ads-server AT will have the ads-component AT as 
a SUPERIOR and ads-component AT will have 'name' as a SUPERIOR).
- Add a X-COMPONENT extension in the AT definition for components.

I think that option 2 or 3 are way easier.

With those modifications, I think we can completely read the config 
using reflection at a small cost and with little sweat (the biggest 
effort would be to carefully check the existing OC and AT to avoid any 

Thoughts ?

Emmanuel L├ęcharny

View raw message