Oh- of course. I overlooked the fact that it was a consuming route. Btw. Wmq sets a custom IBM prefixed property defining the sending charset. Ping me directly if you want me to look it up tomorrow at work where I have the code. Den 14. feb. 2013 16:44 skrev "Claus Ibsen" <[email protected]> følgende:
> On Thu, Feb 14, 2013 at 4:22 PM, yxzhao <[email protected]> wrote: > > We can verify that if the MQ message is sent with MQMessage.format = > > MQConstants.MQFMT_STRING, then our route will receive text message. > > Otherwise, it will receive a byte array. Actually, the sending app uses > the > > same write bytes method to put the message into the queue. The same > message > > can be received as bytes when using MQMessage.readFully method. > > > > Also, we need to know the charset that camel/jms uses to convert the > bytes > > into string to revert the text message back to bytes since we need to get > > the original binary values. > > > > It is not Camel doing anything there. Camel uses the JMS Client to get the > data. > > Camel receives a javax.jms.Message which comes in different > implementations. > So Camel check if instanceof TextMessage, then its a text. If > instanceof BytesMessages its a bytes message etc. > > Under the hood its the JMS client, and in your case IBM WebSphere > being the JMS client. > > > > Any suggestions? > > > > > > > > > > -- > > View this message in context: > http://camel.465427.n5.nabble.com/Always-receive-String-Message-even-with-jmsMessageType-set-to-Bytes-tp5727563p5727605.html > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: [email protected] > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen >
