Hi Willem, Your reply is much appreciated. See my comments below to your questions.
On Fri, Jul 31, 2009 at 4:53 PM, Willem Jiang<[email protected]> wrote: > Hi， > > Why did you need set the message body to be null ? I would expect that camel producers have the chance to treat a "" body and null body differently in their behavior. For example, I may want to send it to another JMS queue. I am kind of expecting the jms producer to send a TextMessage with an empty string, i.e. "" if I use "" in body, but without payload at all if it's null. that sounds different semantics to me in many contexts. > Will you route the message to the other queue ? > Yes, it can be another Jms queue. > As you know camel has it's Message wrapper for all the other components' > message, we may extend the DefaultMessage to hold the reference of under > layer's component message, If you want deal with the JMS Message you can get > it from the JMSMessage which extends from the DefaultMessage by using the > getJmsMessage() method. > I think I agree with Ashwin earlier that manipulation directly on the jms message is not desired. My expectation is simply from a user point of view to have setHeader consistent with getHeader for any camel message implementation including JmsMessage. for example, if my route received a jms message that contains a header "a" with value "value1". one of my processor sets it to value2 by calling setHeader("a", "value2"). somewhere later in the route, I am expecting to get "value2" returned by calling getHeader("a"), but for the current camel-jms, I would get "value1" instead. I would have to use getHeaders().get("a") to get "value2" back. I do believe in many other components, this is not the case. > Since JMSMessage maps header with under lay's JMS message with the JMS > properties, you'd better don't use the getHeaders method. > > Maybe we need to find way to avoid this kind issue of message header > mapping. > > Willem > > Zhi Zhou wrote: >> >> Ashwin, >> >> Thank you very much for the reply. >> My further comments below. >> >> On Fri, Jul 31, 2009 at 3:29 AM, Ashwin Karpe<[email protected]> wrote: >>> >>> Hi, >>> >>> There is no need for a fix. Please find the answers to your questions >>> below. >>> >>>> 1. I can't use setBody(null) to remove the payload of the message. >>>> instead, I have to use setBody("") or similar value to represent an >>>> empty payload, which can be problematic in some cases, as NULL and >>>> non-NULL value will suggest completely different to other components. >>> >>> If you wish to use a payload with no body element, please use the Message >>> base class.This message type is used for event notification and does not >>> have a payload. If you any of the other Message Types (BytesMessage, >>> TestMessage, StreamMessage, MapMessage, ObjectMessage) a body object is >>> assumed and needed. This is per the JMS spec. >>> >> >> This makes sense. >> >> In my particular case, I have a route consuming from a jms queue and >> sending to another endpoint after removing the payload. forgive me if >> it's dumb, but I don't have a chance to use other message class than >> JmsMessage during the processing of the route, do I? >> >> >>>> 2. getHeader(key) and getHeaders().get(key) can return different >>>> results, because getHeader will look first in the original jms message >>>> if the header is available, but the same header in the internal map >>>> may be modified as setHeader will only modify the internal map. this >>>> is all very confusing and 'inconsistent' if people don't know. Since >>>> the original properties of the jms message are copied into the >>>> internal map, why do we ever need to have these operations like >>>> set/getBody, set/getHeader and removeHeader have to tackle on the >>>> original jms message? >>> >>> These are APIs to easily parse JMS messages and simply stated needed to >>> prevent folks from doing exactly what you have stated above. Directly >>> manipulating JMS data structures is not good programming practise. It is >>> better accomplished using helper classes. >>> >> >> In fact, what I want to do is not changing the JMS data structure. >> what I am trying to process is the camel >> message populated from the received JMS message. shouldn't we just >> keep the original JMS message as reference inside >> the camel's JmsMessage? >> >>> From the user point of view, it just surprises me hard when I find >> >> JmsMessage.getHeader(key) and JmsMessage.getHeaders().get("headerA") >> can return completely different results. >> >>> Hope this clarifies things. >>> >>> Cheers, >>> >>> Ashwin... >>> >>> >>> Zhi Zhou wrote: >>>> >>>> Hi, >>>> >>>> I've been working with camel 2.0-m2 so far. Some behaviors related to >>>> getting and setting JmsMessage header and body appear very annoying. >>>> >>>> Just try to confirm/discuss here if they are like so in design or >>>> require >>>> a fix: >>>> >>>> 1. I can't use setBody(null) to remove the payload of the message. >>>> instead, I have to use setBody("") or similar value to represent an >>>> empty payload, which can be problematic in some cases, as NULL and >>>> non-NULL value will suggest completely different to other components. >>>> >>>> 2. getHeader(key) and getHeaders().get(key) can return different >>>> results, because getHeader will look first in the original jms message >>>> if the header is available, but the same header in the internal map >>>> may be modified as setHeader will only modify the internal map. this >>>> is all very confusing and 'inconsistent' if people don't know. Since >>>> the original properties of the jms message are copied into the >>>> internal map, why do we ever need to have these operations like >>>> set/getBody, set/getHeader and removeHeader have to tackle on the >>>> original jms message? >>>> >>>> Thanks! >>>> >>>> Zhi >>>> >>>> >>> >>> ----- >>> --- >>> Ashwin Karpe, Principal Consultant, PS - Opensource Center of Competence >>> Progress Software Corporation >>> 14 Oak Park Drive >>> Bedford, MA 01730 >>> --- >>> +1-972-304-9084 (Office) >>> +1-972-971-1700 (Mobile) >>> ---- >>> Blog: http://opensourceknowledge.blogspot.com/ >>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/JmsMessage-headers-and-body-tp24731110p24745828.html >>> Sent from the Camel - Users mailing list archive at Nabble.com. >>> >>> >> > >
