gnodet opened a new pull request, #28083: URL: https://github.com/apache/camel/pull/28083
## What changed `JmsMessage.copyFrom()` overrides `MessageSupport.copyFrom()` without calling `super`, so it copies body + headers but never copies `MessageTrait.ATTACHMENTS`. This causes attachments to be silently dropped whenever a JMS-originated exchange is copied, for example by the **Multicast EIP**. ## Root cause The fix was first introduced in **CAMEL-23193** (commit `8731df17e97c`). It was then removed in **CAMEL-24365** (commit `40ca925c96de`), which assumed that the `AbstractExchange.newOutMessage()` attachment copy covered the same code path. It does not — `newOutMessage()` handles `exchange.getOut()`, while `copyFrom()` is called when an exchange is fully copied. ## Fix Restore the `ATTACHMENTS` trait copy in `JmsMessage.copyFrom()`, mirroring what `MessageSupport.copyFromWithNewBody()` already does (lines 232–235). ## Test Added `JmsMessageCopyFromAttachmentsTest` — a pure unit test (no broker needed) with two cases: 1. `copyFromPreservesAttachments` — verifies the trait is copied and defensively cloned. 2. `copyFromWithNoAttachmentsLeavesTraitNull` — verifies no stale trait is introduced when the source has none. The original CAMEL-23193 fix had no test, which is why the regression went unnoticed. ## Related - CAMEL-25779 - CAMEL-23193 (original fix) - CAMEL-24365 (regression) _This PR was generated by an AI coding agent (Hermes/Claude) on behalf of gnodet._ -- 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]
