On Mon, Nov 1, 2010 at 12:29 PM, Emmanuel Lecharny <email@example.com>
There are more extensions point : ExtendedOperations, Schema normalizers/SyntaxCheckers/Compartors.
On 11/1/10 11:04 AM, Alex Karasulu wrote:
On Mon, Nov 1, 2010 at 9:51 AM, Kiran Ayyagari<firstname.lastname@example.org> wrote:
On 11/1/10, Emmanuel Lecharny<email@example.com> wrote:
Yes exactly! This has to be done for all extension points in the server.
One thing I forgot to say : the current configReader is not able to
in order to support all those 'dynamic extension' things talked about
process anything but JdbmIndex atm. It has to evolve to be able to do so
(probably using reflection to do so)
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.
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
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.