Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates
 74.125.83.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :content-type:content-transfer-encoding;
        b=b5K9g9f5RYq7co+NJiUZj86I7hl6w4QTjouWug9ph7XNZGwD5HcuGmCUgpixbgE743
         I0TZs7o+FDUI0mB0/1WecL2FMva3cZB/HT5ahB1snC6PZo6qWXst2Qp+ofkDhHMkKcms
         UUMqABaKd98tjA4PR5gvH3NDWzo6m7XDqTU38=
Message-ID: <4CB79266.2050005@gmail.com>
Date: Fri, 15 Oct 2010 01:29:42 +0200
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Configuration again ...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

  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 ?

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

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=1.3.6.1.4.1.18060.0.4.1.3.804, ou=objectClasses, cn=adsconfig, 
ou=schema
createtimestamp: 20100116052129Z
m-oid: 1.3.6.1.4.1.18060.0.4.1.3.804
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,2.5.4.11=system
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 ?

-- 
Regards,
Cordialement,
Emmanuel L�charny
www.iktek.com