OK overall you have me convinced. I was wrong. Let's go ahead and affect the changes to CoreSession.
Alex On Sat, Sep 27, 2008 at 6:12 AM, Emmanuel Lecharny <[EMAIL PROTECTED]>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. > >
