MethodName in header is ignored by beanRef()

[Nick Outram <ap...@nickoutram.name>]

Settup:

from("seda:in").beanRef("myBean").to("seda:out);

with "myBean" defined in the spring application context as a pojo
implementing the meathod read(String) and sending a message:

template.send("seda:in", new Processor() {
  public void process(Exchange e) {
    Message in = exchange.getIn();
    in.setBody("Wibble");
    in.setHeader(BeanProcessor.METHOD_NAME, "read");
  }
});

doesn't result in a call to the read() method of the bean.
-- 
View this message in context: http://www.nabble.com/MethodName-in-header-is-ignored-by-beanRef%28%29-tf4285009s22882.html#a12197583
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: MethodName in header is ignored by beanRef()

[James Strachan <ja...@gmail.com>]

On 8/17/07, Nick Outram <ap...@nickoutram.name> wrote:
> Settup:
>
> from("seda:in").beanRef("myBean").to("seda:out);
>
> with "myBean" defined in the spring application context as a pojo
> implementing the meathod read(String) and sending a message:
>
> template.send("seda:in", new Processor() {
>   public void process(Exchange e) {
>     Message in = exchange.getIn();
>     in.setBody("Wibble");
>     in.setHeader(BeanProcessor.METHOD_NAME, "read");
>   }
> });
>
> doesn't result in a call to the read() method of the bean.

This one totally had me foxed for some time! I was stepping through
the debugger, seeing the method invoked correctly. Yet the test was
failing. I was really starting to doubt all kinds of things (e.g. the
registry, JNDI etc).

Turns out - its ye-old-async-tripping-us-up. You're using 'seda:in' as
the first send. So the test after calling template.send() it may - or
usually won't, have invoked the bean yet. If you wait a bit - it
probably will invoke the bean :). i.e. using "seda:in" means, don't
block the caller waiting to actually process the message - do that
sometime asynchronously in the background.

Here's a test case - I just switched it to use "direct:in" so it
synchronously processes the message on the template.send() and hey
presto, test case works.
https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/BeanRouteTest.java

If you really want a "seda:in" test case, then we must wait a certain
amount of time for the method to be invoked, say using a
CountDownLatch - which just reminds me of how very useful the mock
testing in camel is :)
http://activemq.apache.org/camel/mock.html

-- 
James
-------
http://macstrac.blogspot.com/

Re: MethodName in header is ignored by beanRef()

[James Strachan <ja...@gmail.com>]

On 8/17/07, DominicTulley <do...@telelogic.com> wrote:
>
> I could be wrong but it looks like this is related to an issue I raised last
> week where the JMSReplyTo header was not being preserved by Camel routing.
>
> A fix went in, but it only added support for a few specific headers.  So,
> custom headers such as yours and also (I found today) things like AMQ's
> JMSXGroupID are still not preserved by the routing.

Ah great catch! I raised a JIRA for this...
https://issues.apache.org/activemq/browse/CAMEL-112

After some debugging, this looks like its an ActiveMQ bug; enumerating
the property names on an ActiveMQ JMS message doesn't include the
groupID property. I think this bug has been in ActiveMQ for some time
:) . I've added a workaround for now to Camel.

I've updated the test case: ActiveMQReplyToHeaderUsingConverterTest to
also include testing of the JMSXGroupID header too - this is now
working fine in trunk. Thanks for spotting this one!


> I'm not sure if it's clear what the right answer is - should all headers get
> propagated through the routing, or are some intended to "fall off"?

They should get propogated unless a router or endpoint decides to
filter some. If in doubt, propogate I say :)

-- 
James
-------
http://macstrac.blogspot.com/

Re: MethodName in header is ignored by beanRef()

[DominicTulley <do...@telelogic.com>]

I could be wrong but it looks like this is related to an issue I raised last
week where the JMSReplyTo header was not being preserved by Camel routing.

A fix went in, but it only added support for a few specific headers.  So,
custom headers such as yours and also (I found today) things like AMQ's
JMSXGroupID are still not preserved by the routing.

I'm not sure if it's clear what the right answer is - should all headers get
propagated through the routing, or are some intended to "fall off"?

-Dominic



Nick Outram wrote:
> 
> Settup:
> 
> from("seda:in").beanRef("myBean").to("seda:out);
> 
> with "myBean" defined in the spring application context as a pojo
> implementing the meathod read(String) and sending a message:
> 
> template.send("seda:in", new Processor() {
>   public void process(Exchange e) {
>     Message in = exchange.getIn();
>     in.setBody("Wibble");
>     in.setHeader(BeanProcessor.METHOD_NAME, "read");
>   }
> });
> 
> doesn't result in a call to the read() method of the bean.
> 

-- 
View this message in context: http://www.nabble.com/MethodName-in-header-is-ignored-by-beanRef%28%29-tf4285009s22882.html#a12198390
Sent from the Camel - Users mailing list archive at Nabble.com.