BeanProcessor multiple method invocation on same bean

["aswin.nair" <ma...@gmail.com>]

I have a route defined like the following
from("direct:start").beanRef("tester",
"transform").to("bean:tester?methodName=doJob"); The "tester" bean is 
defined in spring context. 
When I run this, tester.transform() is invoked twice instead of
tester.transform() followed by tester.doJob(). A quick glance through the
BeanProcessor code showed that it is happening because of line 103 which is
                if (isNullOrBlank(in.getHeader(METHOD_NAME, String.class)))
{
                    in.setHeader(METHOD_NAME, methodName);
                }
The METHOD_NAME is already set by the first call and the second one does not
set the new name at all. I think a simple check to verify the method name
with what is present in the header could fix this. 

I am evaluating camel for our project in combination with CFX and looks very
interesting. 

-- 
View this message in context: http://www.nabble.com/BeanProcessor-multiple-method-invocation-on-same-bean-tp14506245s22882p14506245.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: BeanProcessor multiple method invocation on same bean

[Roman Kalukiewicz <ro...@gmail.com>]

2007/12/26, aswin.nair <ma...@gmail.com>:
>
> I have a route defined like the following
> from("direct:start").beanRef("tester",
> "transform").to("bean:tester?methodName=doJob"); The "tester" bean is
> defined in spring context.
> When I run this, tester.transform() is invoked twice instead of
> tester.transform() followed by tester.doJob(). A quick glance through the
> BeanProcessor code showed that it is happening because of line 103 which is
>                 if (isNullOrBlank(in.getHeader(METHOD_NAME, String.class)))
> {
>                     in.setHeader(METHOD_NAME, methodName);
>                 }
> The METHOD_NAME is already set by the first call and the second one does not
> set the new name at all. I think a simple check to verify the method name
> with what is present in the header could fix this.

I created an JIRA issue for this problem at:

https://issues.apache.org/activemq/browse/CAMEL-279

and there is a patch associated. We have to wait for some commiter to
apply this patch to the sources, but you could do it yourself
temporarily.

Roman