camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ranx <brad.john...@mediadriver.com>
Subject Re: @Produce Bug
Date Fri, 22 Jan 2016 17:22:11 GMT
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+s465427n5776560h85@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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message