I've been working with the @Produce annotation as it allows me to carve the
routes into nice stages and let's me do CamelBlueprintTestSupport and route
substitution for testing and mutliple camel contexts aren't a problem. It
works well except for one annoying bug.
If I define an interface of:
public String format(String foo);
And then invoke that against a route of direct:format.foo it will correctly
pass the String and then get the String back. When I do that with a user
defined bean it gives me a BeanInvocationProxy on the receiving end. That's
fundamentally broken for a number of reasons.
If I define an interface like:
public String format(Invoice i) where Invoice is a user defined Java bean
I'll receive the BeanInvocationProxy from the route. The error will contain
something along the lines of:
"No such method found on BeanInvocation public abstract void
com.my.processorinterface.format(Invoice)"
In order to circumvent that I have to do something like this with the route:
from("direct:format.invoice").bean(this,"realize").to("some other
routes...")
public Invoice realize(Invoice data){
return data;
}
This forces the BeanInvocationProxy to cough up its contents but this should
be under the covers and not required explicitly.
There are a couple of reasons this seems wrong.
1. The Java interface should be a solid and expected contract. If it expects
to receive a parameter and get something back then the underlying mechanics
should ensure that. It doesn't matter if it is decompiled into machinecode
and sent via Morse code over telegraph and recompiled the interface should
be the determining factor in its behavior.
2. It currently works inconsistently. In one case it is doing exactly what
one expects sending and getting a simple Java type. In the second case it
is injecting an unexpected data type.
The @Produce mechanism is extremely useful and it seems like this shouldn't
be a complex fix.
--
View this message in context:
http://camel.465427.n5.nabble.com/Produce-Bug-tp5776503.html
Sent from the Camel Development mailing list archive at Nabble.com.
