You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "shashank (Jira)" <ji...@apache.org> on 2026/10/22 03:45:00 UTC

[jira] [Created] (CAMEL-25950) camel-sjms - SjmsMessage loses its attachments when the exchange is copied (Multicast, Split, Recipient List, Wire Tap)

shashank created CAMEL-25950:
--------------------------------

             Summary: camel-sjms - SjmsMessage loses its attachments when the exchange is copied (Multicast, Split, Recipient List, Wire Tap)
                 Key: CAMEL-25950
                 URL: https://issues.apache.org/jira/browse/CAMEL-25950
             Project: Camel
          Issue Type: Bug
          Components: camel-sjms, camel-sjms2
            Reporter: shashank
            Assignee: shashank


{{SjmsMessage.copyFrom}} (main 9f839f4bcc9d) overrides {{MessageSupport.copyFrom}} without calling it. It copies the body and the headers, but not the {{MessageTrait.ATTACHMENTS}} payload, which is 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. Exchanges are copied by the Multicast, Recipient List, Split and Wire Tap EIPs, and by a mock endpoint, among others. A route such as {{from("sjms:queue:in")}} that adds attachments and then multicasts (or splits) sends the copies on without them, silently.

Until CAMEL-21755 (4.10.1) the attachments were exchange properties, which every exchange copy keeps. 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 restored it. {{SjmsMessage}} never got the copy.

*Fix*: {{SjmsMessage.copyFrom}} copies the {{ATTACHMENTS}} trait into a new map, the same way as {{MessageSupport}} and {{JmsMessage}}. camel-sjms2 uses the same {{SjmsMessage}}, so it is fixed as well.

*Tests*: new {{SjmsMessageCopyAttachmentsTest}} (3 tests, JUnit assertions as in the module). It uses the embedded in-VM Artemis broker of the other sjms tests. Fail on main:
* {{multicastCopyKeepsTheAttachmentsOfAnSjmsMessage}} (a route from sjms that adds an attachment and multicasts to a mock): {{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 with the fix: 142 run, 0 failures, 5 skipped.

*How it was found*: regression mining. CAMEL-25779 restored a fix (CAMEL-23193) that a later change (CAMEL-24365) had removed from {{JmsMessage}}. The same override exists in {{SjmsMessage}}, where the attachments have been lost on copy since CAMEL-21755.

*Affected*: main, camel-4.23.x, camel-4.22.x, camel-4.18.x and camel-4.14.x ({{SjmsMessage.copyFrom}} is the same on these branches; read, not run).

_Filed with Claude Code on behalf of allthingssecurity._



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)