So, I think I figured out what happens. Only the initial invocation on the
proxy is a Method Invocation. So, that un-ambiguously up-calls the
implemented method. However, after the initial invocation, the result is
put into the Exchange, and the exchange continues to carry NOT the
MethodInvocation, but just the result of previous invocation.
>From here on, method matching starts to see who can handle the result.
Since, there are two functions syncHandle and asyncHandle they both can
handle the conversion from a Future<T>, to a T, which I assume is handled by
invoking future.get().
The error message contains exactly the SAME method twice. However, it
should have contained different matching signatures. That would have helped
much in troubleshooting this issue.
I helped Camel up-call the proper function by implementing a:
Future<EventData> asyncHandle(Future<EventData> data) throws
HandlerException;
Where I simply turn around and execute:
@Override
public Future<EventData> asyncHandle(final Future<EventData> data)
throws HandlerException {
return
asyncHandle(
get(
data
)
);
}
So, now, one of the method "exactly" matches the content of the Exchange's
body and invocation occurs without an error.
Just takes a good night of sleep.
-AP_
--
View this message in context:
http://camel.465427.n5.nabble.com/AmbiguousMethodCallException-but-both-methods-are-the-same-tp5766545p5766552.html
Sent from the Camel - Users mailing list archive at Nabble.com.
