Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.198.250 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=L5twGzHFxxbCcR+jOLx7HKq42zQdcblu2ZMeBVhXn0uOZTPLjwUBanQQMIBRKtmVGX
         OPzJYldemmn9YeUqBBZyWmmORhCwJZe0rmkbux60kr6egYRZrGY8PAhJ7+x94rXlZDgz
         JGn51czvKVuHAXuMjVTGZQz1e2SCY27k/rVvA=
Message-ID: <4A72B10D.3030300@gmail.com>
Date: Fri, 31 Jul 2009 16:53:33 +0800
From: Willem Jiang <willem.jiang@gmail.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: users@camel.apache.org
Subject: Re: JmsMessage headers and body
References: <bf4544560907291913w9e1530ap23a65b0d1b14f452@mail.gmail.com>
	 <24745828.post@talk.nabble.com>
 <bf4544560907301851v553cd373yf56c2b524e597dd8@mail.gmail.com>
In-Reply-To: <bf4544560907301851v553cd373yf56c2b524e597dd8@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi，

Why did you need set the message body to be null ?
Will you route the message to the other 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.

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<askarpe@progress.com> 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.
>>
>>
>