Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 209.85.128.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding:from;
        b=mgTSrPokhYbnI/8KI12dByYEM0w5yOn1xNqhGsufiD/YR+5t/UXH9Ac3PRyHUSsBGv
         rSr6z8hZd0WuLgo9x0T/dqnujC4ODQ9f1s7ZK3KuUH1HRXHmullKFgYJvXtOCpRi0bVL
         wTpbLJ7JhfI9PRdWtG33zSfhIK4QCbCS7364I=
Message-ID: <48DE071D.8000005@nextury.com>
Date: Sat, 27 Sep 2008 12:12:45 +0200
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: JNDI vs protocol vs Core API
References: <48DD237F.2040907@nextury.com>
	 <a32f6b020809261237k5b36e20ax18da486efe6524e4@mail.gmail.com>
	 <48DD800C.40903@nextury.com>
 <a32f6b020809262025g4d0bb846w2fae68b7664acb7e@mail.gmail.com>
In-Reply-To: <a32f6b020809262025g4d0bb846w2fae68b7664acb7e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Emmanuel Lecharny <elecharny@gmail.com>

Alex Karasulu wrote:
>> well, I don't think we should see the referral handling this way. IIf you
>> see it from another perspective, ie, from the user POV, a referral is just
>> an indirection. Now, the way the server manage it is pretty much a black box
>> for the client, as soon as the client is informed that the entry is not
>> present in the server. If you consider that you want to embed the server,
>> but without using JNDI, you are in a dead end.
>>     
>
>
> I don't think we're in a dead end.  It's up to the user of the CoreSession
> and Entry interfaces to determine what to do with the referral if they don't
> want to use the JNDI wrapper.  It's that simple.
>
> What more do you think needs to be done?  For example if you do a lookup
> via:
>
>     session.lookup( "ou=People,dc=foo" )
>
> and dc=foo is a referral to dc=bar but ou=People does not exist.  In this
> case what exception do you throw? Something telling you the entry does not
> exist or an exception stating a referral needs to be handled? If you want
> referral handling to occur here in CoreSession methods then, the exception
> thrown will depend on the presence of the ManageDsaIT control's presence.
>   
A NoSuchObjectException, from the top of my head, which is not good 
enough for the client. I think that the core session should throw a 
PartialResultException if one of the ancestor is a referral, or a 
ReferralException if the entry is a referral and there is no ManageDsaIT 
control.

In fact, the little thin layer (or may be some small modification in 
CoreSession) should just do that : check if the ManageDsaIt control is 
present (it may be a simple boolean passed into the OpContext, no need 
to pass the full control), and throw the correct exception or the entry, 
depending on the cases.

The JNDI and protocol layers will then just have to deal with those 
exceptions accordingly to their own semantic.

One last thing is that we may have to implement the 'follow' mechanism 
into the JNDI layer, as it's very specific to JNDI.
> If you don't implement referral handling here then upper levels must check
> with the ReferralManager to see if the dn of the missing entry has a
> referral ancestor.  I guess this is a good argument to implement some
> minimal referral handling in the CoreSession then.
>   
Yep.
> What does the Netscape API do?  Maybe that may shed some light.
>   
I can check that.