Hi. Thank you for the response. I dug a little deeper and found out the middleware was removing the headers although they were delivered just nicely to it. If I changed a mode as described in http://www-01.ibm.com/support/docview.wss?uid=swg21573858 it worked ok. So not a camel problem - but a WMQ one (surprise, surprise!)
Sorry for the noise 2014-05-31 8:45 GMT+02:00 Claus Ibsen <[email protected]>: > Hi > > I wonder if <constant>true</constant> renders a boolean or string. > And whether a boolean type is jms compliant. > > You can enable TRACE or DEBUG logging on > org.apache.camel.component.jms, and see if Camel says anything about > dropping a header as its not spec compliant. > > Also Camel logs the JMS being sent with its content, so you ought to > see if your header is there. > > > > On Fri, May 30, 2014 at 2:25 PM, David Karlsen <[email protected]> > wrote: > > Sorry, I don't get you. > > I've read the specs (and looked into camels code) > > As far as I can see I'm playing by the rules: > > > > The exchange that is sent over the JMS wire must conform to the JMS > Message > > spec <http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html>. > > > > For the exchange.in.header the following rules apply for the header > *keys*: > > > > - Keys starting with JMS or JMSX are reserved. > > - exchange.in.headers keys must be literals and all be valid Java > > identifiers (do not use dots in the key name). > > - Camel replaces dots & hyphens and the reverse when when consuming > JMS > > messages: > > . is replaced by _DOT_ and the reverse replacement when Camel consumes > > the message. > > - is replaced by _HYPHEN_ and the reverse replacement when Camel > > consumes the message. > > - See also the option jmsKeyFormatStrategy, which allows use of your > own > > custom strategy for formatting keys. > > > > For the exchange.in.header, the following rules apply for the header > > *values*: > > > > - The values must be primitives or their counter objects (such as > Integer > > , Long, Character). The types, String, CharSequence, Date, BigDecimal > > and BigInteger are all converted to their toString() representation. > > All other types are dropped. > > > > > > ans also the only ones that get filtered on inbound messages are the > > default JMSX ones: > > protected void initialize() { > > // ignore provider specified JMS extension headers see page 39 of > > JMS 1.1 specification > > // added "JMSXRecvTimestamp" as a workaround for an Oracle > bug/typo > > in AqjmsMessage > > getOutFilter().add("JMSXUserID"); > > getOutFilter().add("JMSXAppID"); > > getOutFilter().add("JMSXDeliveryCount"); > > getOutFilter().add("JMSXProducerTXID"); > > getOutFilter().add("JMSXConsumerTXID"); > > getOutFilter().add("JMSXRcvTimestamp"); > > getOutFilter().add("JMSXRecvTimestamp"); > > getOutFilter().add("JMSXState"); > > } > > > > > > 2014-05-30 13:58 GMT+02:00 pradeep <[email protected]>: > > > >> Hi, > >> > >> In the above code snippet the camel header is set. So when the JMS > >> consumer(WMq consumer) receives the actual message then this camel > header > >> will be lost. Instead of camel header you can set camel jms header. > Have a > >> look at the camel jms headers details documented in this link: > >> http://camel.apache.org/jms.html > >> > >> Regards, > >> PradeepN > >> > >> > >> > >> -- > >> View this message in context: > >> > http://camel.465427.n5.nabble.com/Add-custom-stringproperty-to-jms-message-tp5751745p5751747.html > >> Sent from the Camel - Users mailing list archive at Nabble.com. > >> > > > > > > > > -- > > -- > > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: [email protected] > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > hawtio: http://hawt.io/ > fabric8: http://fabric8.io/ > -- -- David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
