Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 21853 invoked from network); 12 Feb 2007 16:18:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Feb 2007 16:18:32 -0000 Received: (qmail 63260 invoked by uid 500); 12 Feb 2007 16:18:38 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 63228 invoked by uid 500); 12 Feb 2007 16:18:38 -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 63213 invoked by uid 99); 12 Feb 2007 16:18:38 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Feb 2007 08:18:37 -0800 X-ASF-Spam-Status: No, hits=3.0 required=10.0 tests=HTML_IMAGE_ONLY_28,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of elecharny@gmail.com designates 66.249.92.170 as permitted sender) Received: from [66.249.92.170] (HELO ug-out-1314.google.com) (66.249.92.170) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Feb 2007 08:18:28 -0800 Received: by ug-out-1314.google.com with SMTP id 71so539263ugh for ; Mon, 12 Feb 2007 08:18:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=ezJonOTT9b3RjvoXKKXd5eJAM6zgHxoUDCxBYTdrbeXHcr2Qhm1LzfgD7dYFEW4AWMvXrwVTHvN3WZqiNSyvzYMIz8KpRX4vApOm7efLtX7Xf6NJ8uwZkFVv/d9drMqqV/OoHRpmGvb1Ja4dgMfFTXO1VEbCQhB/Ryn+/YyvfDY= Received: by 10.78.170.17 with SMTP id s17mr70540hue.1171297081398; Mon, 12 Feb 2007 08:18:01 -0800 (PST) Received: by 10.78.177.15 with HTTP; Mon, 12 Feb 2007 08:18:01 -0800 (PST) Message-ID: Date: Mon, 12 Feb 2007 17:18:01 +0100 From: "Emmanuel Lecharny" Reply-To: elecharny@iktek.com To: "Apache Directory Developers List" Subject: [Referrals] How do we handle Context.REFERRAL property inside the server MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49284_28012545.1171297081357" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_49284_28012545.1171297081357 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi guys, we have had a short convo yesturday with Alex about how the server is supposed to handle the JNDI Context.REFERRAL property. Basically, tis property can be set by a JNDI client to enforce a behavior when the server send back a referral : " A JNDI application uses the Context.REFERRAL [image: (in the API reference documentation)]( "java.naming.referral") environment property to indicate to the service providers how to handle referrals" However, the server might not be seen as a Ldap Service Provider per se. If= g you read the tutorial further, there is a clear indication that the server does not handle this property : " Continuation references can be mixed in with search results returned by a= n LDAP "search" operation. For example, when searching a directory, the serve= r might return several search results, in addition to a few continuation references that show where to obtain further results. These results and references might be interleaved at the protocol level. When the Context.REFERRAL property is set to "follow", the LDAP service provider processes all the normal entries first, before following the continuation references. When this property is set to "throw", all of normal entries are returned in the enumeration first, before the ReferralException is thrown." So far, so good. But we have a problem : ADS is offering a JNDI interface, thus must handle this Context.REFERRAL property. So the question is : - How do we have to handle this poperty into the server? Should we simply ignore it, just dealing with the control, or should we try to implement all the mechanism to handle the FOLLOW ? wdyt ? --=20 Cordialement, Emmanuel L=E9charny www.iktek.com ------=_Part_49284_28012545.1171297081357 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi guys,

we have had a short convo yesturday with Alex about how the= server is supposed to handle the JNDI Context.REFERRAL property. Basically= , tis property can be set by a JNDI client to enforce a behavior when the s= erver send back a referral :
" A JNDI application uses the Context.REFERRAL 3D"(in ("java.naming.referral") environment property to indicate to the service providers how to handle referrals"

However, the server might not be seen = as a Ldap Service Provider per se. Ifg you read the tutorial further, there= is a clear indication that the server does not handle this property :

" Continuation references can be mixed in with search results returned by an LDAP "search" operation. For example, when searching a directory, the server might return several=20 search results, in addition to a few continuation references that show wher= e=20 to obtain further results. These results and references might be interleaved at the protocol level. When the Context.REFERRAL property is set to=20 "follow", the LDAP service provider processes all the normal entries first, before following the continuation references. When this property is set to "throw", all of normal entries are returned in the enumeration first, before the ReferralException is thrown."

So far= , so good. But we have a problem : ADS is offering a JNDI interface, thus m= ust handle this Context.REFERRAL property. So the question is :
-  = How do we have to handle this poperty into the server? Should we simply ign= ore it, just dealing with the control, or should we try to implement all th= e mechanism to handle the FOLLOW ?

wdyt ?
--
Cordialement,
Emmanuel L=E9charny
www.iktek.com ------=_Part_49284_28012545.1171297081357--