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 marco.zapletal@gmail.com
 designates 209.85.161.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=CcD4CxDFa6KL2rAhf5oD8EupKZ/S/7KUdsxlMSXXrZnO6Tz1pkEXKP8dVAoSileoiJ
         U8W36Ixdw8IijsdLgIm9JPaxrOiy9jKgtkYztUjbepqCTVZ/v5Q25LbumJrpM+AKHvoO
         yOr3SDrP0FrJGBt160QAfmxgQqm+zhNLI7/Ag=
Sender: Marco Zapletal <marcozapletal@gmail.com>
Message-ID: <4DEFB85F.8060109@gmail.com>
Date: Wed, 08 Jun 2011 19:58:55 +0200
From: Marco Zapletal <marco.zapletal@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: users@camel.apache.org
Subject: Re: Using properties or headers to persist meta information on the
 exchange?
References: <4DEFA20B.8000300@gmail.com> <4DEFA2C3.2030501@catify.com>
 <4DEFA500.2010500@gmail.com>
 <BANLkTinsu_rwCmrYuhcf8C3VLtt_hPyp+w@mail.gmail.com>
In-Reply-To: <BANLkTinsu_rwCmrYuhcf8C3VLtt_hPyp+w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yes, I've read that. Actually, I just wanted to keep my (String) 
properties when the exchange goes through the JMS queue (similar like 
headers are kept over JMS queues).

If it is the intended behavior that exchange properties are stripped 
away by the JMS component, I am fine with using headers instead. 
However, this contradicts then in my opinion to the discussion in [1], 
where it is mentioned that exchange properties should be used for 
durable storing (serializable) meta information on the exchange.

--
The problem with the non-serializable MessageInfo (which violates the 
JMS spec) occurs only if I set the transferExchange property on the JMS 
component to true (which I tried only as a workaround).

regards,
marco

[1] 
http://camel.465427.n5.nabble.com/How-long-do-the-camel-headers-live-in-routes-td474477.html


On 08.06.2011 19:41, Claus Ibsen wrote:
> The JMS spec limits what can be send as JMS headers. Read more details
> on the Camel JMS wiki page. And for example in the JMS java doc.
>
>
> On Wed, Jun 8, 2011 at 6:36 PM, Marco Zapletal<marco.zapletal@gmail.com>  wrote:
>> Hi,
>>
>> thanks for the quick response. Yes, I've tried this, but this opens up
>> another problem if you use a CXF endpoint on your route. The CXF endpoint
>> seems to store an instance of org.apache.cxf.service.model.MessageInfo on
>> the exchange, which is not serializable. This results in a runtime
>> exception, which cancels the execution of the process instance.
>>
>> regards,
>> marco
>>
>>
>> On 08.06.2011 18:26, Claus Straube wrote:
>>>
>>> Hi Marco,
>>>
>>> have you tried 'transferExchange=true' inside your JMS route? That could
>>> be a solution for your JMS problem.
>>>
>>> Best regards - Claus
>>>
>>> On 08.06.2011 18:23, Marco Zapletal wrote:
>>>>
>>>> Hi,
>>>>
>>>> I learned from this thread
>>>>
>>>> (http://camel.465427.n5.nabble.com/How-long-do-the-camel-headers-live-in-routes-td474477.html)
>>>> that one should use properties instead of headers in order to durable
>>>> store meta information on an exchange (acc. to one of the postings,
>>>> headers can get lost at endpoints).
>>>>
>>>> I would like to know whether this in principle correct. If so, I ran
>>>> into the problem that properties seem to stripped away if an exchange
>>>> goes through a JMS queue. Could anyone tell me what's the recommended
>>>> approach to keep meta information durable on the exchange.
>>>>
>>>> thanks,
>>>> marco
>>>>
>>>
>>
>>
>
>
>