allthingssecurity opened a new pull request, #27461: URL: https://github.com/apache/camel/pull/27461
# Description [CAMEL-25073](https://issues.apache.org/jira/browse/CAMEL-25073) Addresses item 3 of CAMEL-25073, which @davsclaus listed after his deep review of #26959 (CAMEL-25065): two endpoints that only differ in a masked secret get the same object name, and removing one unregisters the other's MBean. With `mask=true` (the default) `DefaultManagementObjectNameStrategy` sanitizes the endpoint uri in the MBean name, so `stub:foo?password=a` and `stub:foo?password=b` are both `endpoints,name="stub://foo\?password=xxxxxx"`. Only the first one is registered (the agent skips a name that is already registered). `onEndpointRemove` unregistered by name, so removing the second endpoint removed the MBean of the first one, which is still in use. This also happens for an endpoint with that name that was never registered, such as one created at runtime (`registerNewRoutes` only registers endpoints while routes are being started). `JmxManagementLifecycleStrategy` now keeps, for each endpoint MBean name it registered, the endpoint it registered it for (a `ConcurrentHashMap`, cleared in `doStop`). Endpoints can be added and removed from several threads, so the registration or unregistration of an endpoint MBean and the update of its owner happen under one `ReentrantLock`: without it, two endpoints with the same name added at the same time could both see the name as free, and the one whose registration was skipped could be recorded as the owner (then removing the real owner left an MBean of a removed endpoint, and removing the recorded one unregistered the MBean still in use). The lock is only taken when an endpoint is added to or removed from the registry, not per message. `onEndpointRemove` does not unregister the name while it belongs to another endpoint that is still in the endpoint registry. When no owner is known it unregisters as before, so an endpoint that `ManagedCamelContext.createEndpoint` registere d directly with the agent is still unregistered by `removeEndpoints`. Two details of the owner check: the endpoint registry can hold an intercepting endpoint (`interceptSendToEndpoint`, mock endpoints) that wraps the endpoint whose MBean was registered, so both sides compare the original endpoint (without that, removing the route of an intercepted endpoint left its MBean registered); and `addEndpoint` can replace an endpoint in the registry without removing it, so an owner that is no longer in the registry does not keep the MBean. An entry stays in the map until its endpoint is removed. An endpoint that leaves the registry another way (eviction from the dynamic endpoint cache, which does not stop or remove it) keeps its MBean registered as before, and the entry refers to the same endpoint the MBean already holds, so it adds no reference; when another endpoint with that name is removed, the evicted owner is no longer in the registry and the MBean is unregistered as before. Not changed: the second endpoint still has no MBean of its own (it has the same name), as before. Giving it one would need a different (unmasked or numbered) name, which users would see; I left that out. No upgrade guide entry: nothing that worked before behaves differently. Related: the other items of CAMEL-25073 come as separate PRs, opened together with this one: item 1 (a CamelContext name with characters that are not allowed in an ObjectName, branch `camel-management-context-name-object-name`); item 2 (the shared MBean of a context-scoped onException, branch `camel-management-onexception-shared-mbean`); item 4 (thread pools of the same source, branch `camel-management-thread-pool-source-id`); item 5 (components registered with mbeansLevel=ContextOnly, branch `camel-management-contextonly-components`). Items 1, 2, 3 and 5 change different methods of `JmxManagementLifecycleStrategy`; all five merge cleanly with each other in any order, and the camel-management tests pass with all five merged. Tests: new `ManagedRemoveEndpointMaskedSecretTest` (3), `ManagedRemoveInterceptedEndpointTest` (1) and `ManagedAddEndpointMaskedSecretRaceTest` (1). `testRemoveEndpointCreatedAtRuntime` (remove an endpoint created after start), `testRemoveEndpointOfOtherRoute` (remove the endpoint of another route) and `testRemoveInterceptedEndpointWithMaskedSecret` (the same with `interceptSendToEndpoint`) fail on main (`The MBean of the endpoint of route a should still be registered ==> expected: <true> but was: <false>`). They also check that removing the endpoint that owns the MBean still unregisters it. `testAddEndpointsWithTheSameNameAtTheSameTime` adds two endpoints with the same masked name from two threads (`registerAlways=true`), holding the first one right after it found the name free; it fails on main (the MBean is unregistered when the other endpoint is removed) and without the lock (`The MBean should be the one of endpoint x, which is still in use ==> expected: <Started> but was: <St opped>`). `testRemoveEndpointThatReplacedTheOwner` passes on main; it is kept because it is the only test of the registry check (without `isEndpointRegistered` it fails with `Should no longer be registered`). Whole `camel-management` module: 536 tests, 0 failures (1 skipped). # 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). # 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 and tested `core/camel-management`, including the formatter and import-sort plugins. No generated files change. I did not run the full root build.) # 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]
