directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: Moving the configuration beans to core-api
Date Mon, 01 Nov 2010 10:55:36 GMT
On 11/1/10 11:36 AM, Alex Karasulu wrote:
> On Mon, Nov 1, 2010 at 12:29 PM, Emmanuel Lecharny<elecharny@gmail.com>wrote:
>
>> On 11/1/10 11:04 AM, Alex Karasulu wrote:
>>
>>> On Mon, Nov 1, 2010 at 9:51 AM, Kiran Ayyagari<kayyagari@apache.org>
>>>   wrote:
>>>
>>>   On 11/1/10, Emmanuel Lecharny<elecharny@gmail.com>   wrote:
>>>>> One thing I forgot to say : the current configReader is not able to
>>>>> process anything but JdbmIndex atm. It has to evolve to be able to do
so
>>>>> (probably using reflection to do so)
>>>>>
>>>> in order to support all those 'dynamic extension' things talked about
>>>> in this thread
>>>> we have to depend extensively on reflection,
>>>> e.x instead of having a separate OC for each index implementation type
>>>> we need to
>>>> have a single OC like 'ads-index' with a MUST AT 'ads-indexClass' so
>>>> that we can
>>>> instantiate the class using default constructor and then inject all
>>>> the configured attribute
>>>> values into that object.
>>>>
>>>>   Yes exactly! This has to be done for all extension points in the server.
>>> What are those extension points?
>>>
>>> - Partitions and their associated classes.
>>> - Interceptors and their associated classes.
>>> - Authenticators and their associated classes.
>>> - LDAP Protocol Handlers and their associated classes.
>>>
>>> I guess there might be more extension points but this is what I see off
>>> the
>>> top of my head. And these things need to be using reflection with the same
>>> MUST AT to class load the respective implementation that users might
>>> provide.
>>>
>> There are more extensions point : ExtendedOperations, Schema
>> normalizers/SyntaxCheckers/Compartors.
>>
>>
> ExtendedOperations are part of the LDAP Protocol Handlers.
>
> And we don't need an extension point for Schema since the Schema Subsystem
> already has this capability built in with updates via the protocol to extend
> Schema. The schema extensions are directly loaded into the DIT and a
> reflection mechanism is already in place to load them appropriately.

Tight.

Anyway, we have to focus on Partitions/Store/Index atm, this is the key 
element at stake atm.

Note : this is *not* urgent. I opened the discussion, but I'm not sure 
we want to do that before 2.0-RC1 is out.


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message