directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: Configuration again ...
Date Sat, 16 Oct 2010 08:28:35 GMT
hi Emmanuel,

On Sat, Oct 16, 2010 at 5:41 AM, Emmanuel Lecharny <> wrote:
>  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/
>  ads-directoryServiceId=myDS/
>  ads-directoryServiceId=myDS.ldif
> ou=config.ldif
> 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
> directory.
> In this directory, as myDS will have partitions, interceptors, servers, we
> will have :
> ou=config/
>  ads-directoryServiceId=myDS/
>    ou=ads-servers/
>    ou=ads-partitions/
>    ou=ads-interceptors/
>    ads-changeLog=myCL.ldif
>    ads-journal=myJournal.ldif
>    ads-passwordPolicy=myPolicy.ldif
> 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.
this structure completely defeats the current idea of keepin all
config in single file
> For instance, we have a LdapServer which id is "myLdapServer", then the DIT
> will look like :
> ou=config/
>  ads-directoryServiceId=myDS/
>    ou=ads-servers/
>      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 reflection.
> 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
> (costly)
> - 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 problem).
> Thoughts ?

IMHO , this is config and we need to have tight control over how we
read and use the elements
rather than twisting it for ease of reading, using reflection is good
but I only apply it
to Index and Partition config entries only cause this is the *only*
place where a user
can define something which is NOT part of our standard distribution
and requires custom settings.

OTOH we can make any change to this config partition structure and can
keep in the way we want
if we never want to directly let the user edit it by hand but only
through a tool.

But our original idea is to have this config human readable and
requires nothing or limited knowledge of how this data internally gets
read applied

think we are going in a counter intuitive direction from user pov.

Kiran Ayyagari

View raw message