allthingssecurity opened a new pull request, #28644: URL: https://github.com/apache/camel/pull/28644
# Description [CAMEL-25950](https://issues.apache.org/jira/browse/CAMEL-25950) `SjmsMessage.copyFrom` overrides `MessageSupport.copyFrom` without calling it. It copies the body and the headers, but not the `MessageTrait.ATTACHMENTS` payload, where the attachments of a message are kept (camel-attachments `AttachmentMessage` stores them there). So when an exchange received from an sjms endpoint is copied, the copy has no attachments. Multicast, Recipient List, Split and Wire Tap all work on copies, and so does a mock endpoint. A route like `from("sjms:queue:in")` that adds attachments and then multicasts or splits sends the copies on without them, and nothing is logged. Until CAMEL-21755 (4.10.1) the attachments were exchange properties, and every exchange copy kept them. CAMEL-21755 moved them into a message trait, which only `MessageSupport.copyFromWithNewBody` copies. camel-jms had the same gap in `JmsMessage.copyFrom`: CAMEL-23193 fixed it, CAMEL-24365 removed that copy, and CAMEL-25779 (#28083) restored it. `SjmsMessage` never got the copy. Changes: - `SjmsMessage.copyFrom` copies the `ATTACHMENTS` trait into a new map, the same way as `MessageSupport` and `JmsMessage` (#28083). - camel-sjms2 uses the same `SjmsMessage`, so it is fixed as well. - A pooled `SjmsMessage` is not affected: `DefaultMessage.reset()` already removes the trait. - No option, generated file or upgrade guide change: nothing for users to migrate. - Backport: camel-4.23.x and 4.22.x have the same `SjmsMessage` as main. camel-4.18.x and 4.14.x differ in other parts of the class, but their `copyFrom` does not copy the attachments either. I read the code on those branches but did not run the tests there. Not changed: `MailMessage.copyFrom` (camel-mail) does not copy the trait either when `mapMailMessage=false`. In that mode the consumer does not extract attachments, so only attachments added by the route are affected. I can file a follow-up JIRA if wanted. Tests: - New `SjmsMessageCopyAttachmentsTest` (JUnit assertions, as in the module). It uses the embedded in-VM Artemis broker of the other sjms tests (`JmsTestSupport`). - Fail on main: - `multicastCopyKeepsTheAttachmentsOfAnSjmsMessage`: a route from sjms adds an attachment and multicasts to a mock. Result: `the copy made by the multicast must keep the attachments ==> expected: not <null>`. - `copyKeepsTheAttachments` (`SjmsMessage.copy()`): `copy() must keep the attachments ==> expected: not <null>`. - `copyOfAMessageWithoutAttachmentsHasNone` is a control that passes on main and with the fix. - camel-sjms unit tests: 142 run, 0 failures, 5 skipped. The formatter and import-sort plugins ran. I built offline with `-Dasm-version=9.11` because asm 9.11.1 was not in my local repository. # 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-25950](https://issues.apache.org/jira/browse/CAMEL-25950). # 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-sjms 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]
