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
