Re: Open issues with the Java LDAP API draft

[Rob Weltman <robw@worldspot.com>]

  I'm changing the signature of LDAPReferralException to take Throwable as argument, and changing getFailureException() to getCause(), as per the new Java API for nested exceptions.

  As for specifying when a referral exception is thrown on search(), isn't the following text from the draft explicit enough?

"If automatic referral following is disabled or a referral was not followed, next() will throw an LDAPReferralException when the referral is received."

Rob


Steve Sonntag wrote:

>  That is only partially true.  The connect call can get various IOExceptions orUnknownHostException which gets generalized to a less specific - more generalerror CONNECT_ERROR.  Presumably, malformed URL could also be returnedas CONNECT_ERROR, but I like more information rather that less, so I agreewith your comment.  This would also change the LDAPUrl class which hasmethods that return MalformedURLException. I think the method name should be more descriptive of its function: public String getFailedReferral() Is is correct to presume that the status for the operation that generatedthe referrals would the status of a referral that failed.  In the case ofsearch, should all other data be returned to the application before throwingthe Exception, or should the exception be thrown immediately?The desired  behavior should be mentioned in the ID. -Steve  >>> Rob Weltman <robw@worldspot.com> 25-Jan-01 10:18:13 AM >>>
>   It could be Exception rather than LDAPException, although it might be better to add a result code for MalformedURL to LDAPException. LDAPException encapsulates more semantic information about the types of referral failures than other low-level exception classes.
>
>   I wouldn't overload matchedDN for relaying the failed URL. It's meaning is, if anything, the opposite: the part of the DN of the URL that did match. Better to provide a new method to retrieve the invalid URL from LDAPReferralException:
>
> public String getReferral()
>
>   If there were multiple references processed, and all of them failed, this would report one of them.
>
> Rob
>
>
> Steve Sonntag wrote:
>
> >  Actually, I was only taking the information given in the constructor
> > and copying it to the introduction of the class.   public LDAPReferralException(String message,
> >                                 LDAPException rootException)    Constructs a default exception with a specified string as additional
> >    information and an exception that indicates a failure to follow a
> >    referral.  This exception applies only to synchronous operations and
> >    is thrown only on receipt of a referral when the referral was not
> >    followed. As I was looking at this, I wondered if LDAPException is
> > too restrictive.  For example what is reported for a malformed URL?
> > We cannot report MalformedURLException as it is of type Exception.
> > Should the rootException be simply of type Exception? Should the ReferralException class use matchedDN to indicate
> > which referral caused the problem, or is that overloading that field too much. -Steve
> > Rob Weltman wrote: > Steve Sonntag wrote:
> > >
> > > >   LDAPReferralException 4.27 public class LDAPReferralException
> > > >                   extends LDAPException
> > > >
> > > >    This exception, derived from LDAPException, is thrown when a server
> > > >    returns a referral and automatic referral following has not been
> > > >    enabled.Add to the above     or automatic referral following could not follow any referrals. -Steve
> > >
> > >   That sounds hard to handle for a client. Are you thinking of the case where the referral points to a server which is inaccessible or which doesn't accept the credentials of the requestor? How would the client know which of those problems was being flagged if there is only a referral exception? And consequently, how would the client know what to do about it?
> > >
> > > Rob
>
>
>
>