From dev-return-7867-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Thu Sep 15 02:13:54 2005 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 86489 invoked from network); 15 Sep 2005 02:13:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Sep 2005 02:13:53 -0000 Received: (qmail 57524 invoked by uid 500); 15 Sep 2005 02:13:53 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 57332 invoked by uid 500); 15 Sep 2005 02:13:52 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 57319 invoked by uid 99); 15 Sep 2005 02:13:51 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Sep 2005 19:13:51 -0700 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=HTML_10_20,HTML_MESSAGE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of nrhope@gmail.com designates 64.233.162.197 as permitted sender) Received: from [64.233.162.197] (HELO zproxy.gmail.com) (64.233.162.197) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Sep 2005 19:14:02 -0700 Received: by zproxy.gmail.com with SMTP id k1so59124nzf for ; Wed, 14 Sep 2005 19:13:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=UNJdYhdybsH63g7rWdfqbcRISRLOmuFyDf2Q+JMqKxQdYMFwXoyypYKBvN9Lo/D7fOdnhp9FFP8eV49fWn9bhqnhBKqRadfuTQ6w6mFAkugcDWHC/s0kQgjGOJfM+TX92Iiq+BAB78aWHvm53J+22QdAoQNl1aYtCuuThpidjVY= Received: by 10.36.119.15 with SMTP id r15mr2842121nzc; Wed, 14 Sep 2005 19:13:50 -0700 (PDT) Received: by 10.37.21.38 with HTTP; Wed, 14 Sep 2005 19:13:50 -0700 (PDT) Message-ID: Date: Thu, 15 Sep 2005 12:13:50 +1000 From: Norbet Reilly Reply-To: nrhope@gmail.com To: Apache Directory Developers List Subject: custom partition support (was "Re: dynamic schema support") In-Reply-To: <43210449.8090000@bellsouth.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12575_2168701.1126750430263" References: <431E3091.4090700@bellsouth.net> <43210449.8090000@bellsouth.net> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_12575_2168701.1126750430263 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > On 9/9/05, Alex Karasulu 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= =20 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= =20 ApacheDS one. My problem was originally that I was peforming the LDAP bind= =20 to the remote directory proxied by my custom partition lazily (as the proxy= =20 had to insert itself into the middle of the start up sequence of an externa= l=20 server), and only retrieving the schema when the lazy bind was eventually= =20 performed. I now perform the LDAP bind in the custom partition's doInit()= =20 method and query the schema and add entries from it to the GlobalRegistries= =20 (I no longer use the IETF LDAP classes and now use vanilla JNDI, which is a= =20 bit of a pain for schema stuff but at least removes a dependency), resultin= g=20 in an uber-schema which JXplorer happily displays. I read RFC 3672 and have followed the recent additions to DS to support it.= =20 My gut feeling is that the subtree specification syntax is the icing on the= =20 cake, and that when custom partitions are implemented at the back-end the= =20 default behaviour should be to delegate all operations (schema/bind etc) to= =20 them based on DN suffix as happens for the other JNDI operations like=20 search/lookup etc. So perhaps the lion's share of the work is going to be= =20 achieving this delegation more then driving the delegation using the subtre= e=20 syntax. Which brings me to the one remaining short-term hurdle I am facing:=20 delegation of binds to my custom partition based on DN suffix. At the momen= t=20 the BindHandler passes information from JXplorer through to the=20 SimpleAuthenticator, which always does its checks against the static=20 environment specified in my apacheds.xml server configuration. Hence the=20 only credentials which will be accepted are the global DS admin credentials= :=20 "uid=3Dadmin,ou=3Dsystem". What I would like to achieve is delegating binds to my custom partition=20 based on the DN suffix of the loginDN presented. I can see two ways of doin= g=20 this: 1. Add an "environment" properties object to a class extending=20 ContextPartitionConfiguration and change BindHandler to query all partition= =20 configs for instances of it. On finding one BindHandler would check for a= =20 suffix match, and if one is found will use its "environment" instead of the= =20 global when attempting its ctx =3D new InitialLdapContext(). 2. Similar approach to 1., but instead of simply substituting an alternativ= e=20 environment add a "bind()" call on the partition and have the bind handler= =20 call in on a suffix match. I see no obvious way for the BindHandler to get= =20 hold of the relevant ContextPartitionNexus instance (and don't really=20 understand the architecture well enough to know if this would be a "bad=20 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= =20 notion of bind delegation and/or the two approaches above? I suspect that ultimately schema retrieval/normalisation semantics may=20 follow a similar path for custom partitions: by default they will perform= =20 their own schema checking/normalisation for operations which deal with thei= r=20 subtree, and their schema contents won't appear in the global schema unless= =20 there is some explicit configuration stating that they should. Any comments/feedback much appreciated... Thanks > ------=_Part_12575_2168701.1126750430263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > On 9/9/05, A= lex Karasulu <aok123@bellsou= th.net> wrote:

>Glad to see your interest.  Hope to see you contribute one da= y.

>Cheers,
>Alex

Thanks for your help, and I hope to contribute once I'm less of a DS noob a= nd 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=3Dadmin,ou=3Dsystem".

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 =3D n= ew InitialLdapContext().
     2. Similar approach to 1., but instead of simply substituting an alternative environment add a "bind()" cal= l 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



------=_Part_12575_2168701.1126750430263--