Hi Shawn, 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.
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
-- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: api-unsubscr...@directory.apache.org For additional commands, e-mail: api-h...@directory.apache.org
