On Mon, Nov 22, 2010 at 4:14 PM, Tim wrote:
> Yea I thought about that but isn't that a hack solution as it now ties
> you to Camel in what was just a pojo?
>
Yeah that would tie it to the Camel API.
I have created a ticket
https://issues.apache.org/activemq/browse/CAMEL-3354
To see if we can a
Yea I thought about that but isn't that a hack solution as it now ties
you to Camel in what was just a pojo?
On Mon, Nov 22, 2010 at 8:57 AM, Claus Ibsen wrote:
> Then return an empty Message object instead of null.
>
>
>
> On Mon, Nov 22, 2010 at 3:55 PM, Tim wrote:
>> Sorry Claus, Maybe I didn
Then return an empty Message object instead of null.
On Mon, Nov 22, 2010 at 3:55 PM, Tim wrote:
> Sorry Claus, Maybe I didn't represent the problem correctly.
> I DO want to alter the body. In this case the result of processing the
> body should be null.
>
> Think of this example (not exactly
Sorry Claus, Maybe I didn't represent the problem correctly.
I DO want to alter the body. In this case the result of processing the
body should be null.
Think of this example (not exactly my case but definitely something
that may be helpful).
I have a route that says:
from("jms:queue:processKey"
On Wed, Nov 17, 2010 at 9:59 PM, Tim wrote:
> BTW, this is an error in logic in MessageSupport when interoperating
> with JMSMessage it seems. I'm not quite sure what the intention was
> when having it copy the old body over on null.
>
> Can a committer please either confirm this as a bug (and I c
BTW, this is an error in logic in MessageSupport when interoperating
with JMSMessage it seems. I'm not quite sure what the intention was
when having it copy the old body over on null.
Can a committer please either confirm this as a bug (and I can try to
patch that would fix this without breaking o
This is essentially a different incantation of CAMEL-2436
(https://issues.apache.org/activemq/browse/CAMEL-2436)
A test case that reproduces the issue is below.
If you have a bean that returns null when processing the body of a
JMSMessage you will not get the null in the next endpoint but rather
th
