directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: Question about the configuration layout
Date Wed, 13 Oct 2010 08:03:34 GMT
Hi Emmanuel,

On Wed, Oct 13, 2010 at 2:40 AM, Emmanuel Lecharny <> wrote:
>  Hi guys,
> as I was writing the configuration documentation, based on the way we
> initialize the server, I went through the objectClasses we use to define the
> configuration for each element. That raised a question in my mind :
> - why don't we link the elements together ?
> Right now, we expect some code to put the glue between those elements (ie
> teh LdapServer OC does not contain any AT defining the DS to use, the DS
> does not contain the list of Partitions it uses, etc). Wouldn't it be better
> to add some AT in each elements to completely define, say, the LdapServer
> configuration from the LdapServer entry, following the contained ATs ?

I'd say it depends on the kind of relationship of those elements.

If the relationship is a composition (i.e. the nested element can't
live without the wrapping element) then we should use a hierarchical
mapping. In that case an attribute in the parent entry that contains a
DN pointing to the child entry should be avoided because of duplicate

> One more thing : we should probably define an Abstract ads-oc OC containing
> the 'description' and 'ads-enabled' elements, which are present in all the
> OCs ? I propose such an OC to handle those informations :
> *A[ads-base]
>  m-may: description
>  m-may: ads-enabled


> I have gathered all the existing OC with there MAY and MUST ATs, and listed
> them here. The A[xxx] notation describes an ABSTRACT OC. The --> notation
> defines a hierarchical relation between 2 OCs (ie OC2 --> OC1 means that OC1
> is the SUP in OC2). The * notation means that we may have from 0 to N
> distinguishedName in an AT. The ATs pointing to other ads OCs are also
> noted.
> With a little effort, I also think that reading such a hierarchy, we could
> automatically generate the beans using introspection, instead of writing a
> reader for each of those elements.

My idea here was to use a persistence framework, like DataNucleus that
is an JDO implementation. But I guess that's not so easy because when
reading the config we only have the raw partition.

Kind Regards,

View raw message