custom partition support (was "Re: dynamic schema support")

[Norbet Reilly <nr...@gmail.com>]

> On 9/9/05, Alex Karasulu <ao...@bellsouth.net> wrote:

>Glad to see your interest. Hope to see you contribute one day.

>Cheers,
>Alex

Thanks for your help, and I hope to contribute once I'm less of a DS noob 
and have more to offer!

This is just to report on my progress and brain dump...

I managed to get my custom partition contributing its schema to the global 
ApacheDS one. My problem was originally that I was peforming the LDAP bind 
to the remote directory proxied by my custom partition lazily (as the proxy 
had to insert itself into the middle of the start up sequence of an external 
server), and only retrieving the schema when the lazy bind was eventually 
performed. I now perform the LDAP bind in the custom partition's doInit() 
method and query the schema and add entries from it to the GlobalRegistries 
(I no longer use the IETF LDAP classes and now use vanilla JNDI, which is a 
bit of a pain for schema stuff but at least removes a dependency), resulting 
in an uber-schema which JXplorer happily displays.

I read RFC 3672 and have followed the recent additions to DS to support it. 
My gut feeling is that the subtree specification syntax is the icing on the 
cake, and that when custom partitions are implemented at the back-end the 
default behaviour should be to delegate all operations (schema/bind etc) to 
them based on DN suffix as happens for the other JNDI operations like 
search/lookup etc. So perhaps the lion's share of the work is going to be 
achieving this delegation more then driving the delegation using the subtree 
syntax.

Which brings me to the one remaining short-term hurdle I am facing: 
delegation of binds to my custom partition based on DN suffix. At the moment 
the BindHandler passes information from JXplorer through to the 
SimpleAuthenticator, which always does its checks against the static 
environment specified in my apacheds.xml server configuration. Hence the 
only credentials which will be accepted are the global DS admin credentials: 
"uid=admin,ou=system".

What I would like to achieve is delegating binds to my custom partition 
based on the DN suffix of the loginDN presented. I can see two ways of doing 
this:
1. Add an "environment" properties object to a class extending 
ContextPartitionConfiguration and change BindHandler to query all partition 
configs for instances of it. On finding one BindHandler would check for a 
suffix match, and if one is found will use its "environment" instead of the 
global when attempting its ctx = new InitialLdapContext().
2. Similar approach to 1., but instead of simply substituting an alternative 
environment add a "bind()" call on the partition and have the bind handler 
call in on a suffix match. I see no obvious way for the BindHandler to get 
hold of the relevant ContextPartitionNexus instance (and don't really 
understand the architecture well enough to know if this would be a "bad 
thing") so I suspect approach 1. is the better option.

Does anyone who is not so much a DS noob as myself have any opinions on the 
notion of bind delegation and/or the two approaches above?

I suspect that ultimately schema retrieval/normalisation semantics may 
follow a similar path for custom partitions: by default they will perform 
their own schema checking/normalisation for operations which deal with their 
subtree, and their schema contents won't appear in the global schema unless 
there is some explicit configuration stating that they should.

Any comments/feedback much appreciated...

Thanks


>