camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: bug: BeanInfo.chooseMethodWithMatchingBody doesn't unify superclass method
Date Fri, 07 Mar 2008 17:52:37 GMT
On 06/03/2008, steven.marcus <steven.marcus@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

Mime
View raw message