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 <elecharny@gmail.com> 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

   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.

What does the Netscape API do?  Maybe that may shed some light.
I can check that.