Thanks. I'll have to think about that. The jbos-fuse-6.2.0.redhat-133 uses Camel 2.15.1. I'm not sure the 6.2.1 uses the latest camel or not. I could override it in the POM but will have to run that by the clients.
On Fri, Jan 22, 2016 at 10:42 AM, Claus Ibsen-2 [via Camel] < ml-node+s465427n5776560...@n5.nabble.com> wrote: > Hi > > Use Camel 2.16 onwards > http://camel.apache.org/using-camelproxy.html > > On Fri, Jan 22, 2016 at 4:51 PM, Ranx <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5776560&i=0>> wrote: > > > 2.15.1.redhat-620133 > > > > On Fri, Jan 22, 2016 at 1:18 AM, Claus Ibsen-2 [via Camel] < > > [hidden email] <http:///user/SendEmail.jtp?type=node&node=5776560&i=1>> > wrote: > > > >> What version of Camel do you use? > >> > >> On Thu, Jan 21, 2016 at 9:18 PM, Ranx <[hidden email] > >> <http:///user/SendEmail.jtp?type=node&node=5776509&i=0>> 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 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. > >> > >> > >> > >> -- > >> Claus Ibsen > >> ----------------- > >> http://davsclaus.com @davsclaus > >> Camel in Action 2: https://www.manning.com/ibsen2 > >> > >> > >> ------------------------------ > >> If you reply to this email, your message will be added to the > discussion > >> below: > >> http://camel.465427.n5.nabble.com/Produce-Bug-tp5776503p5776509.html > >> To unsubscribe from @Produce Bug, click here > >> < > >> . > >> NAML > >> < > http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > > >> > > > > > > > > > > -- > > View this message in context: > http://camel.465427.n5.nabble.com/Produce-Bug-tp5776503p5776550.html > > Sent from the Camel Development mailing list archive at Nabble.com. > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://camel.465427.n5.nabble.com/Produce-Bug-tp5776503p5776560.html > To unsubscribe from @Produce Bug, click here > <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5776503&code=YnJhZC5qb2huc29uQG1lZGlhZHJpdmVyLmNvbXw1Nzc2NTAzfDI4MjkxODI4OQ==> > . > NAML > <http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://camel.465427.n5.nabble.com/Produce-Bug-tp5776503p5776561.html Sent from the Camel Development mailing list archive at Nabble.com.
