You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "steven.marcus" <st...@gmail.com> on 2008/03/06 04:39:01 UTC
bug: BeanInfo.chooseMethodWithMatchingBody doesn't unify superclass
method
Hello all!
Just noticed that BeanInfo.chooseMethodWithMatchingBody doesn't unify the
following case:
class X {
void deliver(Foo arg) {
}
}
class Y extends X {
void deliver(Foo arg) {
}
}
It throws AmbiguousMethodCallException when trying to match Y.deliver.
Just found this because the methodName supplied on the bean invocation
definition in my routings had become invalid.
The default behaviour of camel was to search for a method to attempt
delivery, even though the supplied method name wasn't valid. Is this
desirable behavior? I would think if the supplied method were invalid
default method match should not occur.
Also, would it be possible/good to have method existence of supplied
methodNames done once at camel context start?
Sorry I can't offer a patch/fix... but supplying the correct method name in
the routing definition is the workaround...
Steven Marcus
--
View this message in context: http://www.nabble.com/bug%3A-BeanInfo.chooseMethodWithMatchingBody-doesn%27t-unify-superclass-method-tp15865897s22882p15865897.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: bug: BeanInfo.chooseMethodWithMatchingBody doesn't unify superclass method
Posted by James Strachan <ja...@gmail.com>.
On 06/03/2008, steven.marcus <st...@gmail.com> wrote:
>
> Hello all!
>
> Just noticed that BeanInfo.chooseMethodWithMatchingBody doesn't unify the
> following case:
>
> class X {
> void deliver(Foo arg) {
> }
> }
>
> class Y extends X {
> void deliver(Foo arg) {
> }
> }
>
> It throws AmbiguousMethodCallException when trying to match Y.deliver.
>
> Just found this because the methodName supplied on the bean invocation
> definition in my routings had become invalid.
>
> The default behaviour of camel was to search for a method to attempt
> delivery, even though the supplied method name wasn't valid. Is this
> desirable behavior? I would think if the supplied method were invalid
> default method match should not occur.
That sound about right to me
> Also, would it be possible/good to have method existence of supplied
> methodNames done once at camel context start?
We tend to cache the available method names on a bean type; so we've a
good place to do on-startup caching of stuff like method names
> Sorry I can't offer a patch/fix...
Damn :)
> but supplying the correct method name in
> the routing definition is the workaround...
Cool
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com