camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: @Produce Bug
Date Fri, 22 Jan 2016 07:18:05 GMT
What version of Camel do you use?

On Thu, Jan 21, 2016 at 9:18 PM, Ranx <> wrote:
> 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 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
> 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:
> Sent from the Camel Development mailing list archive at

Claus Ibsen
----------------- @davsclaus
Camel in Action 2:

View raw message