allthingssecurity opened a new pull request, #28326:
URL: https://github.com/apache/camel/pull/28326

   # Description
   
   [CAMEL-25853](https://issues.apache.org/jira/browse/CAMEL-25853)
   
   The toD optimisation of camel-paho, camel-paho-mqtt5 and camel-hivemq puts 
the resolved topic in the override topic header (`CamelPahoOverrideTopic` for 
camel-paho, `CamelPahoMqtt5OverrideTopic` for camel-paho-mqtt5, 
`CamelHiveMQOverrideTopic` for camel-hivemq) and sends to one static endpoint. 
The header stayed on the message after the send (there was no post processor, 
and the producers read the header without removing it), and the pre processor 
keeps an override topic it finds on the message. So a second toD of the same 
exchange, for example 
`.toD("paho:status/${header.id}").toD("paho:audit/${header.id}")`, or a toD 
inside a `loop`, published to the topic of the first toD, without any error.
   
   Changes:
   - `PahoSendDynamicAware`, `PahoMqtt5SendDynamicAware` and 
`HiveMQSendDynamicAware`: `createPostProcessor` returns a processor that 
removes the override topic header the pre processor has set. When the route set 
the header itself before the toD, nothing is removed (same condition as the pre 
processor).
   
   The header is no longer on the message after a toD that set it. camel-kafka, 
camel-jms, camel-sjms and camel-spring-rabbitmq already remove their override 
headers in the producer. Doing the same in these producers would also remove a 
header the route set itself after the first send, which they keep today; the 
post processor removes only the header the toD optimisation added, so no 
upgrade guide entry.
   
   Tests:
   - New `PahoToDTwiceTest`, `PahoMqtt5ToDTwiceTest` and `HiveMQToDTwiceTest` 
(2 tests each, no broker: a mocked paho `MqttClient` on the component, a 
recording client for hivemq). The paho tests use JUnit assertions, as the other 
tests of those modules, the hivemq test AssertJ, as camel-hivemq. Without the 
change all six fail, for example `expected: <[status/1, audit/1]> but was: 
<[status/1, status/1]>`, and `but was: <[devices/0/cmd, devices/0/cmd, 
devices/0/cmd]>` for the loop. All pass with the change.
   - Unit tests with the change: camel-hivemq 26 run, 0 failures; 
camel-paho-mqtt5 19 run, 0 failures; camel-paho 30 run, 8 errors in 
`PahoComponentTest` and `PahoManualAcksTest` (route start fails with 
`Connection lost (32109) - java.io.EOFException` against the embedded broker), 
which fail the same way without the change in my environment.
   
   How it was found: a review of the `SendDynamicAware` implementations, 
comparing what each one leaves on the message after the send with what its 
producer reads, then the JUnit tests.
   
   What was not run: a test against a real MQTT broker; the full root build.
   
   # 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-25853](https://issues.apache.org/jira/browse/CAMEL-25853).
   
   # 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 camel-paho, camel-paho-mqtt5 and camel-hivemq. No 
option changed. 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]

Reply via email to