directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: Configuration again ...
Date Fri, 15 Oct 2010 08:07:36 GMT
On Fri, Oct 15, 2010 at 4:59 AM, Emmanuel Lecharny <> wrote:
>  So I'm continuing playing with many concepts, and having some kind of fun
> with the new configuration system. However, that raises some interesting
> questions.
> 1) components
> Right now, we have some separate components, mainly servers. Some of them
> (most of them I should say) depends on a DirectoryService. Obviously, they
> are likely to share this component, as there is no rational to have one
> dedicated DS per server. However, one may want to instanciate 2 LdapServer
> with 2 different DS. Why would we forbid such a feature ?
cause it is not a feature required (or desired one) in a real
environment, and also note that
what makes it really difficult is to define a workdir for each DS
instance (there is a chicken-egg
problem between them, DS requires a workdir to start and we can only
read if we initialize the
config partition which again needs the workdir first to initialize itself)
and sorry to raise the same old thing, that I believe "we should stick
to one DS per config",

> 2) Relations between component and storage
> If we consider a LdpaServer, the following relations are obvious :
> LdapServer
>  -> DirectoryService
>      -> Partitions
>          -> Indexes
>      -> Journal
>      -> ChangeLog
>  -> Transports
>  -> Replication consumer
>      -> Transport
>  -> Replication provider
>      -> Transport
> As we can see, all those relations are hierarchical, and it will remain so
> for a *very* long time
yeap, they are fundamental representation of our design, so they live looooong
> 2) The question is how do we represent such relations in the configuration ?
> Right now, each component has its sub-component one level down the tree in
> the DIT, so when you read the DirectoryService configuration, you know that
> the configuration entries for the Partitions are one level down, and the
> configuration entroes for the index are 2 level down.
> That's ok, except for the DirectoryService which is *not* one level down the
> LdapServer entry, simply because it can be shared with other servers. That's
> annoyaing.
> Yesterday, I proposed to inject the dependent component as DN in the
> containing component. So the DirectoryService DN would have been present in
> the LdapServer DN. This will solve the previous issue, with one drawback:
> it's less comfy to manage from the user PoV.
> Another option would be to store the component ID instead of the DN : as
> each component has an unique ID? that should work, and the main advantage is
> that we don't depend on a position in the tree for each component, as we can
> do a search with a SUBTREE scope to retrieve the entry we are looking for.
> 3) Why do we need a reference to the underlying components in the parent
> component ?
> In other words, why should we have either the DN or the ID of the
> DirectoryService into the LdapServer ? Simply because having it allows us to
> write a reader which is using reflection to rad the configuration into some
> beans :
> for the BaseAdsBean ObjectClass, which is :
> dn: m-oid=, ou=objectClasses, cn=adsconfig,
> ou=schema
> createtimestamp: 20100116052129Z
> m-oid:
> entrycsn: 20100116105129.549000Z#000000#000#000000
> m-description: the base Bean
> objectclass: metaObjectClass
> objectclass: metaTop
> objectclass: top
> m-name: ads-baseAds
> creatorsname: 0.9.2342.19200300.100.1.1=admin,
> m-may: ads-description
> m-may: ads-enabled
> we have a bean like :
> public abstract class BaseAdsBean
> {
>    /** The enabled flag */
>    protected boolean enabled = false;
>    /** The description */
>    protected String description;
> ...
> We can load the entry, and instanciate the Bean using the m-name AT (minus
> the leading "ads-" and plus the "Bean"), then we can feed the fields, always
> using reflection ( the ads-description MAY value is associated with the
> description field in the class pretty easily).
> But in order to do that, we must have a way to know that a class field is
> associated with an entry, if this class field references a component. In our
> case, in LdapServer, we will have a directoryServer field and that means we
> will have a MUST value, ads-directoryServer in the LdapServer OC.
> If we do that, then we don't have to write some code to link the internal
> java representation with the entries : it's all about telling the server
> that the entries are in some place in the DIT, and asking it to load some
> predefined beans (those beans are POJOs) from the read entries, using
> reflection.
> It works. I have tested it. It's easy, it's maintainable, as we just have to
> be sure that the Beans are equivalent with the OCs.
> Does that sounds ok for you ?

it all sounds good to me, but I would like to propose that we go with
a mixed solution besides
just pure reflection to solve the above said problem by not using any
kind of "links"

i.e we manually inject the DS bean for all those types which depend on DS

in a code pov how about adding a field 'directoyService' to
and then we call setDirectoryService() after reading the corresponding
server's configuration?

thanks for putting your thoughts in ink

Kiran Ayyagari

View raw message