You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2009/08/03 08:23:38 UTC
Re: JmsMessage headers and body
On Fri, Jul 31, 2009 at 3:51 AM, Zhi Zhou<zz...@gmail.com> wrote:
> Ashwin,
>
> Thank you very much for the reply.
> My further comments below.
>
> On Fri, Jul 31, 2009 at 3:29 AM, Ashwin Karpe<as...@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?
>>>
Yeah there is a point there. The Jms component is optimized for fast
message routing and thus it does some optimizations.
For example it tries to avoid populating the camel message with copies
from the jms message in case you just read from it as it can get the
data directly from the jms message, and thus it will be faster.
However there are an oversight as when you use getHeaders() the code
was not always in sync with the headers from the JMS message.
I am looking into this and see if we can get the code in sync so
getHeader and getHeaders works as expected. Wether or not you have
mutated the message or not using setHeader.
>>> 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.
>>
>>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: JmsMessage headers and body
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I have committed fixes to trunk that aligns using headers with the
camel-jms component.
Please test it on your systems with latest code from SVN or try using
2.0-SNAPSHOT versions.
Ticket is here:
https://issues.apache.org/activemq/browse/CAMEL-1867
Would be great to get this confirmed by end users before we build 2.0 final.
On Mon, Aug 3, 2009 at 8:23 AM, Claus Ibsen<cl...@gmail.com> wrote:
> On Fri, Jul 31, 2009 at 3:51 AM, Zhi Zhou<zz...@gmail.com> wrote:
>> Ashwin,
>>
>> Thank you very much for the reply.
>> My further comments below.
>>
>> On Fri, Jul 31, 2009 at 3:29 AM, Ashwin Karpe<as...@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?
>>>>
>
> Yeah there is a point there. The Jms component is optimized for fast
> message routing and thus it does some optimizations.
> For example it tries to avoid populating the camel message with copies
> from the jms message in case you just read from it as it can get the
> data directly from the jms message, and thus it will be faster.
>
> However there are an oversight as when you use getHeaders() the code
> was not always in sync with the headers from the JMS message.
>
> I am looking into this and see if we can get the code in sync so
> getHeader and getHeaders works as expected. Wether or not you have
> mutated the message or not using setHeader.
>
>
>>>> 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.
>>>
>>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus