You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/10/15 01:29:42 UTC
Configuration again ...
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
Re: Configuration again ...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Oct 15, 2010 at 4:59 AM, Emmanuel Lecharny <el...@gmail.com> 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=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 ?
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
DirectoryBackedServiceBean
and then we call setDirectoryService() after reading the corresponding
server's configuration?
thanks for putting your thoughts in ink
Kiran Ayyagari
Re: Configuration again ...
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Definitely +1
Regards,
Pierre-Arnaud
On 15 oct. 2010, at 10:48, Emmanuel Lecharny wrote:
> On 10/15/10 10:29 AM, Stefan Seelmann wrote:
>> Hi,
>>
>> On Fri, Oct 15, 2010 at 1:29 AM, Emmanuel Lecharny<el...@gmail.com> 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.
>>> 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
>> I wonder if another hierarchy (DIT structure) makes more sense:
>>
>> DirectoryService
>> -> Partitions
>> -> Indexes
>> -> Journal
>> -> Changelog
>> -> Servers
>> -> LdapServer
>> -> Transports
>> -> Replication consumer
>> -> Replication provider
>> -> KerberosServer
>> -> ...
>>
>> This way it should also be possible to define multiple directory
>> services with their own servers.
>
> This is an option. It reverts the logic we currently have in place, but it's smart, assuming it covers both concerns we have :
> - with such a hierarchy, we allow someone to define 2 servers having 2 different DS
> - we also have all the elements cleanly linked together.
>
> I +1 this proposal !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: Configuration again ...
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, Oct 15, 2010 at 12:09 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> On 10/15/10 10:50 AM, Stefan Seelmann wrote:
>
>> On Fri, Oct 15, 2010 at 10:48 AM, Emmanuel Lecharny<el...@gmail.com>
>> wrote:
>>
>>> On 10/15/10 10:29 AM, Stefan Seelmann wrote:
>>>
>>>> I wonder if another hierarchy (DIT structure) makes more sense:
>>>>
>>>> DirectoryService
>>>> -> Partitions
>>>> -> Indexes
>>>> -> Journal
>>>> -> Changelog
>>>> -> Servers
>>>> -> LdapServer
>>>> -> Transports
>>>> -> Replication consumer
>>>> -> Replication provider
>>>> -> KerberosServer
>>>> -> ...
>>>>
>>>> This way it should also be possible to define multiple directory
>>>> services with their own servers.
>>>>
>>> This is an option. It reverts the logic we currently have in place, but
>>> it's
>>> smart, assuming it covers both concerns we have :
>>> - with such a hierarchy, we allow someone to define 2 servers having 2
>>> different DS
>>> - we also have all the elements cleanly linked together.
>>>
>> One issue is that not all servers (only NTP atm?) have a relationship
>> to the directory service. But I think the main purpose of ApacheDS is
>> to provide services the need a hierarchical data store underneath.
>>
> Yes, NTP has no relation with the DS, except that it's only needed by the
> KerberosServer. The other server which has no relation with DS is
> HtppServer, but as it's a server used to have a HTTP connection with the DS,
> it's somehow related.
>
> So at the end, I still think that it's all about DS on top, and all the
> server under.
>
>
I think all server/services even NTP and HTTP will have their configurations
backed in the DIT. So the relation holds.
Great idea Stefan!
Regards,
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: Configuration again ...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Oct 15, 2010 at 2:39 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 10/15/10 10:50 AM, Stefan Seelmann wrote:
>>
>> On Fri, Oct 15, 2010 at 10:48 AM, Emmanuel Lecharny<el...@gmail.com>
>> wrote:
>>>
>>> On 10/15/10 10:29 AM, Stefan Seelmann wrote:
>>>>
>>>> I wonder if another hierarchy (DIT structure) makes more sense:
>>>>
>>>> DirectoryService
>>>> -> Partitions
>>>> -> Indexes
>>>> -> Journal
>>>> -> Changelog
>>>> -> Servers
>>>> -> LdapServer
>>>> -> Transports
>>>> -> Replication consumer
>>>> -> Replication provider
>>>> -> KerberosServer
>>>> -> ...
>>>>
>>>> This way it should also be possible to define multiple directory
>>>> services with their own servers.
>>>
>>> This is an option. It reverts the logic we currently have in place, but
>>> it's
>>> smart, assuming it covers both concerns we have :
>>> - with such a hierarchy, we allow someone to define 2 servers having 2
>>> different DS
>>> - we also have all the elements cleanly linked together.
>>
>> One issue is that not all servers (only NTP atm?) have a relationship
>> to the directory service. But I think the main purpose of ApacheDS is
>> to provide services the need a hierarchical data store underneath.
>
> Yes, NTP has no relation with the DS, except that it's only needed by the
> KerberosServer. The other server which has no relation with DS is
> HtppServer, but as it's a server used to have a HTTP connection with the DS,
> it's somehow related.
it is indeed deeply related when we have web app deployed which work based on
the DS data (e.x a DSML or JSON gateway)
>
> So at the end, I still think that it's all about DS on top, and all the
> server under.
>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
Re: Configuration again ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 10/15/10 10:50 AM, Stefan Seelmann wrote:
> On Fri, Oct 15, 2010 at 10:48 AM, Emmanuel Lecharny<el...@gmail.com> wrote:
>> On 10/15/10 10:29 AM, Stefan Seelmann wrote:
>>> I wonder if another hierarchy (DIT structure) makes more sense:
>>>
>>> DirectoryService
>>> -> Partitions
>>> -> Indexes
>>> -> Journal
>>> -> Changelog
>>> -> Servers
>>> -> LdapServer
>>> -> Transports
>>> -> Replication consumer
>>> -> Replication provider
>>> -> KerberosServer
>>> -> ...
>>>
>>> This way it should also be possible to define multiple directory
>>> services with their own servers.
>> This is an option. It reverts the logic we currently have in place, but it's
>> smart, assuming it covers both concerns we have :
>> - with such a hierarchy, we allow someone to define 2 servers having 2
>> different DS
>> - we also have all the elements cleanly linked together.
> One issue is that not all servers (only NTP atm?) have a relationship
> to the directory service. But I think the main purpose of ApacheDS is
> to provide services the need a hierarchical data store underneath.
Yes, NTP has no relation with the DS, except that it's only needed by
the KerberosServer. The other server which has no relation with DS is
HtppServer, but as it's a server used to have a HTTP connection with the
DS, it's somehow related.
So at the end, I still think that it's all about DS on top, and all the
server under.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Configuration again ...
Posted by Stefan Seelmann <se...@apache.org>.
On Fri, Oct 15, 2010 at 10:48 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 10/15/10 10:29 AM, Stefan Seelmann wrote:
>> I wonder if another hierarchy (DIT structure) makes more sense:
>>
>> DirectoryService
>> -> Partitions
>> -> Indexes
>> -> Journal
>> -> Changelog
>> -> Servers
>> -> LdapServer
>> -> Transports
>> -> Replication consumer
>> -> Replication provider
>> -> KerberosServer
>> -> ...
>>
>> This way it should also be possible to define multiple directory
>> services with their own servers.
>
> This is an option. It reverts the logic we currently have in place, but it's
> smart, assuming it covers both concerns we have :
> - with such a hierarchy, we allow someone to define 2 servers having 2
> different DS
> - we also have all the elements cleanly linked together.
One issue is that not all servers (only NTP atm?) have a relationship
to the directory service. But I think the main purpose of ApacheDS is
to provide services the need a hierarchical data store underneath.
Kind Regards,
Stefan
Re: Configuration again ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 10/15/10 10:29 AM, Stefan Seelmann wrote:
> Hi,
>
> On Fri, Oct 15, 2010 at 1:29 AM, Emmanuel Lecharny<el...@gmail.com> 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.
>> 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
> I wonder if another hierarchy (DIT structure) makes more sense:
>
> DirectoryService
> -> Partitions
> -> Indexes
> -> Journal
> -> Changelog
> -> Servers
> -> LdapServer
> -> Transports
> -> Replication consumer
> -> Replication provider
> -> KerberosServer
> -> ...
>
> This way it should also be possible to define multiple directory
> services with their own servers.
This is an option. It reverts the logic we currently have in place, but
it's smart, assuming it covers both concerns we have :
- with such a hierarchy, we allow someone to define 2 servers having 2
different DS
- we also have all the elements cleanly linked together.
I +1 this proposal !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Configuration again ...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Oct 15, 2010 at 1:59 PM, Stefan Seelmann <se...@apache.org> wrote:
> Hi,
>
> On Fri, Oct 15, 2010 at 1:29 AM, Emmanuel Lecharny <el...@gmail.com> 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.
>
>> 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
>
> I wonder if another hierarchy (DIT structure) makes more sense:
>
> DirectoryService
> -> Partitions
> -> Indexes
> -> Journal
> -> Changelog
> -> Servers
> -> LdapServer
> -> Transports
> -> Replication consumer
> -> Replication provider
> -> KerberosServer
> -> ...
>
> This way it should also be possible to define multiple directory
> services with their own servers.
+1 sounds perfect, might solve many linking issues
Kiran Ayyagari
Re: Configuration again ...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Sat, Oct 16, 2010 at 3:56 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Guys,
>
> one thing that might not be clear in my previous mails : as Stefan pointed
> out, what I'm talking about seemed to be relative to a multiple ldif files
> layout, when we want to have one single ldif file to store all the config.
>
> My bad.
>
ah this is the reason exactly why I used the 'defeats purpose..', I
understood that as multiple
files which we didn't want to use
> In fact, I don't really care about the file system layout, whether it's a
> single ldif file or a multiple ldif file : I *never* get the entries from
> the disk, I'm always addressing the config partition to fetch them.
yes, relying on config partition makes the location of config transparent
and we can modify even a remote server configuration
(by using a network connection based config partition on the client side)
Kiran Ayyagari
Re: Configuration again ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
Guys,
one thing that might not be clear in my previous mails : as Stefan
pointed out, what I'm talking about seemed to be relative to a multiple
ldif files layout, when we want to have one single ldif file to store
all the config.
My bad.
In fact, I don't really care about the file system layout, whether it's
a single ldif file or a multiple ldif file : I *never* get the entries
from the disk, I'm always addressing the config partition to fetch them.
However, It changes nothing when it comes to the DIT structure.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Configuration again ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 10/16/10 10:28 AM, Kiran Ayyagari wrote:
> hi Emmanuel,
>
> On Sat, Oct 16, 2010 at 5:41 AM, Emmanuel Lecharny<el...@gmail.com> 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
Re: Configuration again ...
Posted by Kiran Ayyagari <ka...@apache.org>.
hi Emmanuel,
On Sat, Oct 16, 2010 at 5:41 AM, Emmanuel Lecharny <el...@gmail.com> 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
>
> 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.
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.
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
think we are going in a counter intuitive direction from user pov.
Kiran Ayyagari
Re: Configuration again ...
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
Re: Configuration again ...
Posted by Stefan Seelmann <se...@apache.org>.
Hi,
On Fri, Oct 15, 2010 at 1:29 AM, Emmanuel Lecharny <el...@gmail.com> 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.
> 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
I wonder if another hierarchy (DIT structure) makes more sense:
DirectoryService
-> Partitions
-> Indexes
-> Journal
-> Changelog
-> Servers
-> LdapServer
-> Transports
-> Replication consumer
-> Replication provider
-> KerberosServer
-> ...
This way it should also be possible to define multiple directory
services with their own servers.
Kind Regards,
Stefan