Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
Unknown
Description
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.