On 10/16/10 10:28 AM, Kiran Ayyagari wrote:
hi Emmanuel,
On Sat, Oct 16, 2010 at 5:41 AM, Emmanuel Lecharny<[email protected]> wrote:
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.
this structure completely defeats the current idea of keepin all
config in single file
The structure I describe is the *exact* structure we currently have...
If it defeats the current idea we have, then what we have is actually
completely wrong :)
ou=config/
ads-directoryServiceId=default/
ou=interceptors/
ads-interceptorId=aciAuthorizationInterceptor.ldif
ads-interceptorId=authenticationInterceptor.ldif
...
ou=partitions/
ads-partitionId=example/
ou=indexes/
ads-indexAttributeId=1.3.6.1.4.1.18060.0.4.1.2.1.ldif
...
ou=indexes.ldif
ads-indexAttributeId=1.3.6.1.4.1.18060.0.4.1.2.1.ldif
...
ads-partitionId=system/
ads-partitionId=example.ldif
ads-partitionId=system.ldif
ou=interceptors.ldif
ou=partitions.ldif
ads-directoryServiceId=default.ldif
ou=config.ldif
How is it different from what I describe, except that I changed a few
names so that the RDN and the AT in OC are equivalent ? (note that we
can ename ads-partitions to partitions for clarity sake, if needed)
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 ?
IMHO , this is config and we need to have tight control over how we
read and use the elements
rather than twisting it for ease of reading, using reflection is good
but I only apply it
to Index and Partition config entries only cause this is the *only*
place where a user
can define something which is NOT part of our standard distribution
and requires custom settings.
We have tight control over the configuratio through the structure we use
to describe the configuration, ie the ObjectClasses and the underlying
structure, if only we had DSR implemented. In other words, with DSR, we
can't put partitions in any other place but under the DS they are
associated with.
If we follow this scheme, then using reflection is just using a tool to
read something which is already well structured. Now, in order to use
reflection, we need to have a consistent naming scheme, that's all what
I am proposing.
OTOH we can make any change to this config partition structure and can
keep in the way we want
if we never want to directly let the user edit it by hand but only
through a tool.
In any case, the user will be able to manipulate the config. Reflection
is totally out of scope here, because it does not force any constraints
on how the data are structured. It just works *if* the data are
structured, which they have to be anyway. If if they are, then it's a no
brainer to use reflection instead of a crippled and error prone hand
written reader.
But our original idea is to have this config human readable and
requires nothing or limited knowledge of how this data internally gets
read applied
Absolutely. But it requires a structure and naming consistency.
think we are going in a counter intuitive direction from user pov.
I don't think so. Trust me on that, I'm not focusing on making
reflection works, I'm much more focusing on making the whole config
structure coherent, so coherent we can use a tool like refection to read
it :) Tools are so damn stupid that if we can use them to actually do
something, then I think a human being can easily understand how the data
are structured...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
