allthingssecurity opened a new pull request, #28759: URL: https://github.com/apache/camel/pull/28759
# Description [CAMEL-26303](https://issues.apache.org/jira/browse/CAMEL-26303) `BrowseEndpoint` kept the processor of its consumer from `createConsumer` on and called it for every exchange a producer sent to the endpoint. For a route `from("browse:orders")` next to routes that send `to("browse:orders")` (as in `BrowseRouteConsumeTest`): - When the consuming route was stopped, the producers still called the processor of the stopped route. On main the exchange then fails with `RouteStoppingException` (CAMEL-25502), so every route that sends to the endpoint failed for as long as the consuming route was stopped. - When the consuming route was removed, the core stopped the endpoint although the other routes still send to it, `doStop` set the list of exchanges to null, and every send failed with a `NullPointerException` until the route was added again. Changes: - The consumer sets the processor when it starts and clears it (only its own) when it stops. It is a new inner class `BrowseConsumer` (before, a plain `DefaultConsumer`), so its MBean and the consumer class shown by the dev consoles change name accordingly. - `doStop` clears the list of exchanges but keeps it, so the producers keep working after the endpoint was stopped. - No option, generated file or upgrade guide change. - Backport candidates, for the maintainers to label if wanted (contributors cannot set `port/*` labels): camel-4.22.x and 4.18.x have the same code (read, not run). There, without `RouteStoppingException`, a stopped consuming route still processes the exchanges. Tests: - New `BrowseRemoveRouteTest` in camel-core (where the browse tests are): `removeConsumerRoute` (NullPointerException) and `stoppedConsumerGetsNoMessage` (RouteStoppingException) fail on main (3 runs) and pass with the change. - The browse tests of camel-core (14 tests, 0 failures), the `ManagedBrowsable*` tests of camel-management (21 tests, 0 failures) and `BrowseDevConsoleTest` of camel-console (8 tests, 0 failures) pass. The formatter and import-sort plugins ran. How it was found: a code sweep for endpoints whose `doStop` releases something that other routes on the same uri still use, after a random lifecycle-sequence harness found the same kind of defect in camel-disruptor (CAMEL-26286). # 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-26303) filed for the change (usually before you start working on it): [CAMEL-26303](https://issues.apache.org/jira/browse/CAMEL-26303). # 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 camel-browse and the browse tests of camel-core and ran its tests, including the formatter and import-sort plugins. No generated file changes. 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]
