> On Apr 5, 2021, at 4:12 PM, Emmanuel Lécharny <[email protected]> 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: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
