davsclaus opened a new pull request, #29023: URL: https://github.com/apache/camel/pull/29023
Fixes [CAMEL-26198](https://issues.apache.org/jira/browse/CAMEL-26198). ### 1. A singleton DirContext bean fails on the second exchange **What was wrong:** `LdapProducer.process` closes the `DirContext` after each search. That is deliberate (CAMEL-1583): the docs ask for a prototype scoped bean (Spring `scope="prototype"`, Quarkus `@Dependent`), and closing frees the LDAP connection right away. A singleton `InitialDirContext` bean is dead after `close()`, so the second exchange failed with a confusing `NoInitialContextException` ("Need to specify class name in environment..."). The "Binding using credentials" example of the docs bound such a singleton `InitialLdapContext`. **What changed:** - The producer keeps the last `InitialContext` it closed. When the registry returns that same instance again, it fails with an `IllegalStateException` that names the bean and says to use a prototype scoped bean, or a `Hashtable`/`Map` bean with the environment. - Only an `InitialContext` is checked: a raw `DirContext` such as `com.sun.jndi.ldap.LdapCtx` connects again after `close()`, so a singleton of it keeps working as before (a test covers this). - The `dirContextName` description and the component doc say a `DirContext` bean is closed after each use. The credentials example now binds the `Properties` (a `Hashtable`) instead of a singleton context. **Not changed:** the proposal "leave a DirContext bean open" is not done. Prototype scoped beans are the documented setup, and neither Spring nor Quarkus closes a prototype/`@Dependent` instance, so each exchange would leak an LDAP connection. See the open question below. ### 2. No bean for dirContextName gives an NPE **What was wrong:** `getDirContext()` returned null when the lookup found nothing, and the search failed with a `NullPointerException`. **What changed:** it throws `NoSuchBeanException` with the bean name and the `DirContext` type. ### 3. The embedded ApacheDS of the ITs does not start **What was wrong:** the test helper `DirectoryExtension.updateTlsKey` (a workaround for old Java 8 releases that rejected small RSA keys) replaced the `privateKey`, `publicKey` and `userCertificate` of the admin entry, but not the `tlsKeyInfo` object class that `TlsKeyGenerator.addKeyPair` adds. ApacheDS 2.0.0.AM27 rejects that with `ERR_277 Attribute publicKey not declared`. **What changed:** `updateTlsKey` is removed. ApacheDS 2.0.0.AM27 already generates a 2048-bit key for the admin entry, and the ITs use plain LDAP. `LdapRouteManualIT` (4 tests) and `LdapRouteTwoManualIT` (1 test) pass again with `-Denable.ldap.itests=true`. They are still gated by that property. ### Tests - New `LdapProducerDirContextTest` (4 tests) with a fake `DirContext` from a test `InitialContextFactory`, no LDAP server needed: a `Hashtable` bean (new context per exchange, each closed), a singleton `InitialDirContext` bean (clear error on the second exchange), a singleton non-`InitialContext` `DirContext` bean (keeps working), and a missing bean (`NoSuchBeanException`). - Without the fix, 2 of them fail: `NoInitialContextException` instead of `IllegalStateException`, and `NullPointerException` instead of `NoSuchBeanException`. - `mvn clean install -Psourcecheck` in the module passes; the ITs pass with `-Denable.ldap.itests=true`. ### Generated files `ldap.json` (component and catalog), the catalog copy of `ldap-component.adoc`, and the endpoint DSL are regenerated for the new `dirContextName` description. No upgrade guide entry: both cases failed before and still fail, only with a clearer exception. ### Open question Should a singleton `DirContext` bean be supported (not closed), for example with a new endpoint option such as `closeDirContext=false`? This PR keeps the current close-after-use contract and makes the failure clear. _Claude Code on behalf of Claus Ibsen (davsclaus)_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
