Hi What version of Camel do you use?
Try upgrading to a newer release, to see if its fixed. And read this FAQ when working with a processor http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html On Mon, Jul 9, 2012 at 3:58 PM, SimonH <smh...@scottlogic.co.uk> wrote: > 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. -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
