Claus Ibsen created CAMEL-26200:
-----------------------------------

             Summary: camel-ldif - the LdapConnection bean from the registry is 
closed after each exchange, so the next changes fail with only a status string
                 Key: CAMEL-26200
                 URL: https://issues.apache.org/jira/browse/CAMEL-26200
             Project: Camel
          Issue Type: Bug
          Components: camel-ldap
            Reporter: Claus Ibsen
             Fix For: 4.24.0


Found while adding the catalog body types of ldif (CAMEL-24961, PR #28416).

h4. 1. The registry LdapConnection bean is closed after each exchange

{{LdifProducer.processLdif}} (main 2a465aa4814c, line 134) closes the 
{{LdapConnection}} looked up from the registry ({{getLdapConnection}}, line 109 
to 111) with {{IOHelper.close(conn, ldifReader, reader)}}. The next exchange 
uses the closed connection: the client reconnects without the bind of the 
configured connection, and every change returns the status "modifications 
require authentication", with no exception. Checked on 4.24.0-SNAPSHOT with a 
local OpenLDAP container (osixia/openldap 1.5.0) and a bound LdapConnection 
bean.

Proposed: do not close the connection bean (close only the readers), or 
document that it must be a new connection per lookup.

h4. 2. A failure status is only the root cause message, empty for some failures

A failed change gives as status only the message of the root cause 
({{LdifProducer.getRootCause}}, line 188 to 197). OpenLDAP sends no message for 
"already exists" or "no such object", so the status is an empty String, with no 
result code. Checked on 4.24.0-SNAPSHOT with a local OpenLDAP container.

Proposed: include the LDAP result code (and the DN) in the failure status.

h4. 3. An empty or null body ends up null, not ""

For an empty body the producer sets "" (line 77 to 78), but line 100 then sets 
the body to the null result, so the body is null. Checked on 4.24.0-SNAPSHOT 
with a local OpenLDAP container.

Proposed: set the result body only when there was something to process.

_Claude Code on behalf of davsclaus_



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to