[
https://issues.apache.org/jira/browse/CAMEL-25951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-25951.
---------------------------------
Resolution: Fixed
Fixed by https://github.com/apache/camel/pull/28531 (merged to main as
477925e33f78).
> camel-jms, camel-sjms - an InOut request/reply drops the attachments of the
> exchange
> ------------------------------------------------------------------------------------
>
> Key: CAMEL-25951
> URL: https://issues.apache.org/jira/browse/CAMEL-25951
> Project: Camel
> Issue Type: Bug
> Components: camel-jms, camel-sjms
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
>
> When an exchange is sent InOut to a jms or sjms endpoint, the reply manager
> sets the reply as a new OUT message: {{exchange.setOut(new JmsMessage(...))}}
> in camel-jms {{ReplyManagerSupport.handleSuccessfulReply}}, and the same with
> {{SjmsMessage}} in camel-sjms (main 9f839f4bcc9d). The attachments of a
> message are its {{MessageTrait.ATTACHMENTS}} payload, and the new reply
> message does not have it. So after every request/reply the exchange has lost
> its attachments. A route that receives a mail with attachments, asks a JMS
> service for something (InOut) and then forwards the mail sends it without the
> attachments, and nothing is logged.
> CAMEL-21755 (4.10.1) moved the attachments from exchange properties into the
> message trait. CAMEL-24365 (4.22) then copied them into an OUT message
> created by {{exchange.getOut()}}, so that camel-http and other producers keep
> them. The 4.22 upgrade guide calls this "restoring the pre-4.10.1 behavior
> where attachments survived across the exchange". The JMS and SJMS reply
> managers do not use {{exchange.getOut()}}, so they still drop the attachments.
> *Fix*: the two reply managers copy the {{ATTACHMENTS}} trait of the IN
> message into the reply message before {{exchange.setOut(response)}}, the same
> way as {{AbstractExchange.newOutMessage}}. camel-amqp uses the camel-jms
> reply manager, so it is fixed as well.
> *Tests*: new {{JmsInOutKeepsAttachmentsTest}} (camel-jms) and
> {{SjmsInOutKeepsAttachmentsTest}} (camel-sjms), 2 tests each, JUnit
> assertions as in the modules. They use the embedded in-VM Artemis broker of
> the other tests of these modules. A route sends InOut to a queue whose
> consumer answers with "Bye " + body.
> * {{replyKeepsTheAttachmentsOfTheRequest}} fails on main in both modules:
> {{the reply must keep the attachments of the exchange ==> expected: not
> <null>}};
> * {{replyToARequestWithoutAttachmentsHasNone}} is a control that passes on
> main and with the fix.
> Unit tests with the fix: camel-jms 478 run (three surefire executions: 456,
> 16 and 6), 0 failures, 11 skipped; camel-sjms 141 run, 0 failures, 5 skipped.
> *How it was found*: regression mining. CAMEL-24365 restored the attachments
> for one code path of the CAMEL-21755 change, and CAMEL-25779 had to restore
> another one in {{JmsMessage}}. The reply managers are a third path with the
> same loss.
> *Not changed* (follow-up JIRAs if wanted): the producers of camel-netty
> ({{ClientChannelHandler}}) and camel-undertow ({{UndertowClientCallback}})
> also set the response as a new message and drop the attachments.
> *Affected*: main, camel-4.23.x and camel-4.22.x (same reply managers).
> camel-4.18.x and camel-4.14.x have the same reply managers, and do not have
> the CAMEL-24365 change either. Read, not run.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
