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.
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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
