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<[email protected]> wrote:
> On Fri, Jul 31, 2009 at 3:51 AM, Zhi Zhou<[email protected]> 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?
>>>>
>
> 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

Reply via email to