Re: Java API: LDAPMessage accessor for LDAPException

["Jim Sermersheim" <jimse@novell.com>]

>>>> Rob Weltman <robw@worldspot.com> 1/2/01 10:39:29 AM >>>
>Jim Sermersheim wrote:
>> 
>> Rob,
>> 
>> There are (perhaps) dozens of extended operations that are not described in Internet-Drafts. Some of these, as well as possible future IETF documented extended operatoins, have the ability to not only return one of the well known (and limited) LDAP error values, but return other "extended" error information as well (in the value of the extended resonse).
>> 
>> There must be some way of reading the information returned in the extended operation PDU whether or not an error value is present. To make the case more simple, the Java API is not allowing the client to read the entire allowable set of data being sent by the server.
>> 
>> Jim
>
>  Wouldn't such an extended operation return success as the LDAP return code (the extended operation was successfully delivered, processed, and a result returned), so there would be no exception? There is a difference between an LDAP protocol failure on the one hand and a privately defined operation result on the other.
>
>Rob

The particular extension that initially sparked this does not return success. Rather, it returns an error value and  also returns additional information in the extended response value. One could imagine an extended operation that returns timeLimitExceeded along with some extra information about the amount of work done before time ran out. These types of extensions aren't trying to augment information surrounding protocol failures per se. They're either trying to augment infromation surrounding othr types of errors (like insufficientAccessRights, noSuchObject, limits, etc).

The ability to do this does exist in the protocol as we know it today. It may be poor design on the extension writers behalf, but there isn't wording that I can find in the specification that warns or suggests not to do it. I believe that it is wrong for the API to hide this protocol information unless the specification explicitly states that when the extended response contains an ldapResult other than success (0), the response value MUST be empty (or ignored by clients).

I just looked at a few I-Ds and it seems to date, this is something that is specified by the extension specification, not the protocol. While some I-Ds specify that the response value is to be ignored in the presence of any result other than success, the LBURP draft defines an extended operation that allows an other (80) result to signify and that more information is held in the extended response value.

Whether this is a bad thing for extension writers to do is a discussion to be had at the protocol level. I don't think we should fix perceived shortcomings by restricting or augmenting the APIs. Until the protocol specification says something about this, I think the APIs need to allow access to this information.

Jim


> 
> >>> Rob Weltman <robw@worldspot.com> 12/27/00 8:54:52 PM >>>
> Jim Sermersheim wrote:
> >
> > I've heard a couple people ask how to solve this problem with synchronous calls:
> >
> > Client sends an extended operation to server. Server returns with extended response but an error condition is present. An LDAPException is thrown and caught by the application, but there is no way to read the extended response.
> >
> > Can we add a new method to LDAPException -- public LDAPMessage getLDAPMessage()? It would return null if no LDAPMessage is associated with the response.
> >
> > To date I've told people to use the async methods, but I'd rather the problem just be fixed.
> >
> > Jim
> 
> Jim,
> 
>   In what cases is there a valid response message as well as an error condition? For the other operation types there is either one or the other.
> 
> Rob