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<[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.
