> On 9/9/05, Alex Karasulu <email@example.com> wrote:
>Glad to see your interest. Hope to see you contribute one day.
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
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
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
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
Any comments/feedback much appreciated...