Claus Ibsen created CAMEL-13175:
-----------------------------------
Summary: Consider removing useOriginalMessage functionality
Key: CAMEL-13175
URL: https://issues.apache.org/jira/browse/CAMEL-13175
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Fix For: 3.0.0
This feature is a bit more complex and its intention/design was to in case of
an error during routing, you could say, that the original incoming message
should be restored as-is and used as "result", for example in case you want to
move that message to some dead letter queue or log it etc.
However people may mis-understand this, and think you can mix the original
message BODY only and enrich it with any existing headers at the time of error
- but that was not how it was designed/intended.
However a few EIPs and if you turned on shared unit of work, you could end up
with situations where it would mix the original message with the message of
error.
If the user wants to mix both the original message with the message at the
error, then they should use a bean/processor/aggregation strategy etc to
"merge" the data together as they want. NOT rely on just saying
useOriginalMessage and "hope for the best".
Also the original message body, can when you transfer messages over Camel
endpoints be stored at new endpoints such as JMS, direct-vm etc whom creates a
new exchange. And if you use direct, and other internals it would not. So it
can be a bit unclear where such original message would origin from.
Instead we should let the user use the Claim Check EIP pattern where you can
explict set safe points with the original message, and easily merge data back
agains, such as the message body only etc.
See for example
https://github.com/apache/camel/blob/camel-2.x/camel-core/src/test/java/org/apache/camel/issues/MulticastMixOriginalMessageBodyAndEnrichedHeadersTest.java
VS
https://github.com/apache/camel/blob/camel-2.x/camel-core/src/test/java/org/apache/camel/issues/MulticastMixOriginalMessageBodyAndEnrichedHeadersClaimCheckTest.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
