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