allthingssecurity opened a new pull request, #29791: URL: https://github.com/apache/camel/pull/29791
# Description [CAMEL-26887](https://issues.apache.org/jira/browse/CAMEL-26887) Three of the follow-ups named in #29671 (CAMEL-26870, merged). The fourth, the JMX attributes of `MasterConsumer` before the first start and after a stop, is not changed: the consumer MBean is registered only while the consumer runs, so only a narrow window shows it. `ZookeeperGroupSupport` is the base of the group listeners of the master consumer and of `MasterRoutePolicy`, and of the component's own support: - *A closed client is reused after a restart.* When no curator is set, the group factory strategy calls `call()`, which built and started a `CuratorFramework` and kept it in the `curator` field; the group factory (which owns it) closed it when the support stopped. A start of the same support after its stop found the closed client in the field and used it (and registered its listener on it, the second point of the review of #29671), so the group could not connect. That is the component's own support when the component instance outlives a CamelContext stop (a `MasterComponent` bean of the registry, started again; its consumers then get the closed client), or a `ZookeeperGroupSupport` used directly. A route restart is not affected: the master consumer and `MasterRoutePolicy` create a new support at each start. - *A group factory of the registry is closed by every stop.* A `ManagedGroupFactory` found in the registry (or set on the support) was closed and dropped in `doStop`, although the component and all consumers and route policies find the same bean: the stop of one route closed the factory (and, when it owns it, the client) of the others. - *The `zookeeper.password` system property is ignored.* `call()` read it when no password was configured but discarded the value (`System.getProperty(ZOOKEEPER_PASSWORD);`), so the client connected without the digest authorization. Change, in `ZookeeperGroupSupport` only: it remembers the client `call()` created and the group factory `doStart` created, and `doStop` closes and drops only those (the client also when a custom `ManagedGroupFactoryStrategy` wraps it without closing it; a start after the stop creates new ones); a client or a group factory of the registry or set by the user is kept, as Camel never closed the registry "curator" bean either. `call()` assigns the system property to the password. Tests, new `ZookeeperGroupSupportLifecycleTest` (no ZooKeeper: the client is created and started against an address where nothing listens, and does not connect): - `testCreatedClientIsNotReusedAfterAStop`: after a stop and a start, the support uses a new, started client; - `testClientSetByTheUserIsKeptAfterAStop`: a control, a client set by the user stays started and is used again; - `testGroupFactoryOfTheRegistryIsNotClosedByAStop`: a group factory of the registry is not closed by two stops, and is used again by the next start; - `testPasswordFromTheSystemProperty`: with the `zookeeper.password` system property, the client built by `call()` has the digest authorization (read from the private `authInfos` of the Curator client by reflection, which fails loudly if Curator renames it; the builder's getter is not reachable from a test without a new seam in `call()`). Without the change the other three fail on main (the same closed client, the factory closed once, no authorization); the control passes. With it the camel-zookeeper-master unit tests pass (28 run, 0 failures). The ITs need a ZooKeeper container and were not run locally (CI runs them). No documentation or upgrade guide change: a group factory bound in the registry is no longer closed by the stop of a consumer or route policy, which only matters to an application that relied on that to close it. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-26887](https://issues.apache.org/jira/browse/CAMEL-26887). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built the core modules and camel-zookeeper-master with the formatter and import-sort plugins and ran its unit tests. I did not run the full root build. The ITs, which need a ZooKeeper container, were not run locally; CI runs them.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 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]
