directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: JNDI vs protocol vs Core API
Date Sat, 27 Sep 2008 15:15:13 GMT
OK overall you have me convinced.  I was wrong.  Let's go ahead and affect
the changes to CoreSession.


On Sat, Sep 27, 2008 at 6:12 AM, Emmanuel Lecharny <>wrote:

> 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.

View raw message