There seems to be a problem with the way a Jms-to-Jms InOnly route: modifications to the message body during a 'processRef' node are not included in the sent message to the second Jms Endpoint.
*Problem Case* JmsBinding::makeJmsMessage sometimes returns the original javax.jms.Message instead of making a new one; it seems that the Jms endpoint then just fires on the original 'content' byte array - meaning we lose any modifications made to the org.apache.camel.component.jms.JmsMessage 'body' Object. The makeJmsMessage method takes this action when JmsMessage::shouldCreateNewMessage returns false, which it does when the 'headers' field is null. I don't understand why this is a reason to not create a new message? Other use cases of ours don't have this problem, although this seems to be by accident: *Alternative Case 1*: If the incoming javax.jms.Message does not have a Camel 'breadcrumb' header on it from a previous Camel route, then DefaultUnitOfWork::init constructor method will generate a breadcrumb and set it onto the org.apache.camel.component.jms.JmsMessage - thus causing the 'headers' field to be non-null. Note that if the javax.jms.Message *does* have a breadcrumb header, it is not copied to the org.apache.camel.component.jms.JmsMessage (which seems like strange behaviour to me) *Alternative Case 2*: If the modifications occur in a 'beanRef' node on the pipeline instead of a 'processRef' node, then the BeanProcessor::process method looks up the 'CamelBeanMethodName' header on the org.apache.camel.component.jms.JmsMessage. The inherited getHeader method from DefaultMessage is used, and this particular variant of 'getHeader' initialises the 'headers' field if it is not already. Once again, this initialisation of 'headers' means that, down the line, JmsBinding:makeJmsMessage will choose to make a new javax.jms.Message rather than re-use the old unmodified one. So, to *summarise*: - is it right that JMS headers are not always copied over to the new org.apache.camel.component.jms.JmsMessage? - is it right that the absence of these headers cause an outbound JMS endpoint to re-use the content of the original javax.jms.Message, discarding any modifications made to the org.apache.camel.component.jms.JmsMessage 'body'? /On a related note/, I found some strange behaviour regarding the org.apache.camel.component.jms.JmsMessage 'getHeader' methods: There are four overloaded signatures of this method - three inherited from DefaultMessage, and one overriding DefaultMessage. Two of them - the ones that have a 'default' argument - have a side effect of initialising the 'headers' map, while the other two do not necessarily initialise the map (depending on if the required header can be found in the underlying javax.jms.Message). -- View this message in context: http://camel.465427.n5.nabble.com/Jms-component-discarding-transformations-tp5715738.html Sent from the Camel - Users mailing list archive at Nabble.com.
