> On Apr 5, 2021, at 4:12 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > > Stefan is correct. > > There was a discussion about how to react to server's errors. We wanted to > distinguish between technical errors and logical errors (ie server responses > containing LdapResult which is not SUCCESS). > > In these last cases, throwing an exception would have make it a bit more > complicated for the client to handle the root cause, as we would have had > either to map an exception by error type, or include the response into the > exception, and expecting the client to pull it out of the exception to do > something with it. We found it more convenient to let the client directly > deal with the LapResult in the Response and act upon its need. >
Makes sense. Thanks for the background story. It helps to understand the why along with the how it works. — Shawn > And I agree with Stefan too: if it's not clear, then more doco is necessary. > > On 05/04/2021 21:32, Stefan Seelmann wrote: >> Hi Shawn, >> I can only speak for API V2 but I think for V1 it's similar. >> I also was surprised by that behavior, but it's "as designed" and makes >> sense and is consistent :) >> The LdapConnection methods that take a raw XyzRequest object also return >> a raw XyzResponse object. Those only throw an exception if a network >> level exceptions happens. But if the LDAP server properly returns a >> response (be is positive or negative) the raw response is returned to >> the caller and the caller has to inspect it. >> There are other methods like add(Entry) or delete(Dn) or modify(Dn, >> Modification) which return void. For those methods it's different and >> the response from the server is processed by >> ResultCodeEnum.processResponse() which throws LDAP specific exceptions >> for non-successfule responses. >> If you use the raw request/response methods you can use that utility >> method too if you like. >> I agree that it looks surprising, propbably we should improve the javadoc? >> Kind Regards, >> Stefan >> On 4/5/21 8:30 PM, Shawn McKinney wrote: >>> Hello, >>> >>> Stumbled on this today. The error occurs adding entry to directory and >>> constraint violation occurs. The error is expected as I’m manipulating an >>> pw policy attribute that is DSA controlled. >>> >>> I’ve changed the code on adds to be able to forward the DSA control: >>> >>> ``` >>> AddRequest addRequest = new AddRequestImpl(); >>> addRequest.setEntry( entry ); >>> if ( setManagedDsa ) >>> { >>> ManageDsaIT mControl = new ManageDsaITImpl(); >>> mControl.setCritical( true ); >>> addRequest.addControl( mControl ); >>> } >>> AddResponse response = connection.add( addRequest ); >>> ``` >>> >>> FWIW I’ve also done it this way: >>> >>> ``` >>> addRequest.addControl( new ManageDsaITImpl(); ); >>> ``` >>> >>> With this newly modified code I wouldn’t expect to get an error from >>> server, but let’s set that concern aside for a moment. >>> >>> What I REALLY don't expect is for the server exception to be eaten by the >>> API. >>> >>> It happens line 566 of class (v1.3): >>> >>> >>> } else { >>> LOG.debug("Add failed : {}", addResponse); >>> } >>> >>> I’ve stepped through it, the server returns in response to the add (with >>> pwpolicy operational attr): >>> >>> ``` >>> Ldap Result >>> Result code : (CONSTRAINT_VIOLATION) constraintViolation >>> Matched Dn : '' >>> Diagnostic message : 'pwdPolicySubentry: no user modification allowed’ >>> ``` >>> >>> A more complete excerpt of LDAP API code add method: >>> >>> >>> ``` >>> LdapNetworkConnection >>> public AddResponse add(AddRequest addRequest) throws LdapException { >>> ... >>> >>> try { >>> AddResponse addResponse = (AddResponse)addFuture.get(this.timeout, >>> TimeUnit.MILLISECONDS); >>> if (addResponse == null) { >>> LOG.error("Add failed : timeout occurred"); >>> throw new LdapException("TimeOut occurred"); >>> } else { >>> if (addResponse.getLdapResult().getResultCode() == >>> ResultCodeEnum.SUCCESS) { >>> LOG.debug("Add successful : {}", addResponse); >>> } else { >>> LOG.debug("Add failed : {}", addResponse); >>> } >>> >>> return addResponse; >>> } >>> … >>> ``` >>> >>> Please advise on if you think this is a bug (eating exception). I’ll >>> follow-up with another thread on the *why* the server's returning the >>> exception in the first place but I need to investigate a bit more (may be >>> problem on server OpenLDAP 2.5.3 beta). >>> >>> — >>> Shawn >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: api-unsubscr...@directory.apache.org >>> For additional commands, e-mail: api-h...@directory.apache.org >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: api-unsubscr...@directory.apache.org >> For additional commands, e-mail: api-h...@directory.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: api-unsubscr...@directory.apache.org For additional commands, e-mail: api-h...@directory.apache.org