@Produce vs @ProducerTemplate

[Brad Johnson <br...@mediadriver.com>]

I use producer template quite a bit and it works well but it obviously is a
bit more coupled to the Camel API than using the @Produce with an interface.

The problem is I can't tell exactly when @Produce is going to work as I
expect it to.  Currently I have two routes, for example, one that makes a
call to a direct route to do a look up and return a field during
processing.  It works fine.

A second route that I have is similar but it sends a String fileName to a
an error route to send and email via a velocity template.  If I use the
ProducerTemplate that works fine.  If I use the @Produce what I end up with
is the body rendered showing the BeanInvocation proxy itself with the
actual body to be rendered contained with in it.

I ran into this before in an different situation and ended up removing the
@Produce although I was actually able to cause it to work correctly by an
indirect bean call on it which seems to have cause the proxy to divulge its
contents.

In this particular case I'm invoking the interface which sends it to a
second route that sets other information like to/from/subject and then uses
a recipientList to invoke the velocity template I've specified for that
particular error message.

Brad

Re: @Produce vs @ProducerTemplate

[Brad Johnson <br...@mediadriver.com>]

Ugh, early Monday...That should be @EndpointInject of ProducerTemplate and
not @ProducerTemplate.

On Mon, Aug 8, 2016 at 9:02 AM, Brad Johnson <br...@mediadriver.com>
wrote:

> I use producer template quite a bit and it works well but it obviously is
> a bit more coupled to the Camel API than using the @Produce with an
> interface.
>
> The problem is I can't tell exactly when @Produce is going to work as I
> expect it to.  Currently I have two routes, for example, one that makes a
> call to a direct route to do a look up and return a field during
> processing.  It works fine.
>
> A second route that I have is similar but it sends a String fileName to a
> an error route to send and email via a velocity template.  If I use the
> ProducerTemplate that works fine.  If I use the @Produce what I end up with
> is the body rendered showing the BeanInvocation proxy itself with the
> actual body to be rendered contained with in it.
>
> I ran into this before in an different situation and ended up removing the
> @Produce although I was actually able to cause it to work correctly by an
> indirect bean call on it which seems to have cause the proxy to divulge its
> contents.
>
> In this particular case I'm invoking the interface which sends it to a
> second route that sets other information like to/from/subject and then uses
> a recipientList to invoke the velocity template I've specified for that
> particular error message.
>
> Brad
>
>
>

Re: @Produce vs @ProducerTemplate

[Brad Johnson <br...@mediadriver.com>]

Reading through the proxy description I suspect the reason it was working
in one instance and not in the other is the one that worked with public
String foo(String bar) and that was automatically getting bound correctly.
The other method had a bean class and a void return and it was not getting
bound.  Instead the invocation proxy was getting sent over and then when it
was getting put through the recipientList to the velocity macro to render
an error email the toString was not being called on the body inside the
inocation handler but on the invocation handler itself.

It sounds like much of that is going to be a non-issue after 2.16.

It's also going to be less of an issue because I'll likely use more simple
wrapper classes and I'm OK with those using ProducerTemplate.  Previously
the issue with those was having to create multiple levels of XML injection
to get that together and then testing it. The CDI makes that a non-issue
really since it simply looks for what needs to be injected.

So here's a wrapper class for the email notification.  I inject this object
into other handlers, validators, etc. to fire off detected problems.


@Inject
@Uri(SEND_EMAIL_ERROR_NOTICE)
private ProducerTemplate emailErrorRoute;

public void notifyMalformedFileName(String fileName){
emailErrorRoute.sendBodyAndHeaders(fileName,
createMalformedFileEmailHeaders());
}


The createMalformedFileEmailHeaders is a static method that returns a map
with to/from/subject and so on.


Theoretically I could have an interface that's the same as my wrapper class
and use that instead of the ProducerTemplate with the @Produce. I'll have
to think about the implications of it as I'm not sure if it buys me much.

On Thu, Aug 11, 2016 at 10:14 AM, Brad Johnson <brad.johnson@mediadriver.com
> wrote:

> I'm using 2.15.x in Fuse 6.2 and experimenting with Camel 2.17 and CDI in
> Fuse 6.3 which I downloaded.  But I don't really need the Fuse container
> for the testing with the CDI test runner.
>
> I really like the way this is all going.
>
> Brad
>
> On Thu, Aug 11, 2016 at 8:32 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
>
>> What version of Camel are you using?
>>
>> From Camel 2.16 onwards @Produce / proxy should use bean parameter
>> binding by default
>> http://camel.apache.org/using-camelproxy.html
>>
>> On Mon, Aug 8, 2016 at 4:02 PM, Brad Johnson
>> <br...@mediadriver.com> wrote:
>> > I use producer template quite a bit and it works well but it obviously
>> is a
>> > bit more coupled to the Camel API than using the @Produce with an
>> interface.
>> >
>> > The problem is I can't tell exactly when @Produce is going to work as I
>> > expect it to.  Currently I have two routes, for example, one that makes
>> a
>> > call to a direct route to do a look up and return a field during
>> > processing.  It works fine.
>> >
>> > A second route that I have is similar but it sends a String fileName to
>> a
>> > an error route to send and email via a velocity template.  If I use the
>> > ProducerTemplate that works fine.  If I use the @Produce what I end up
>> with
>> > is the body rendered showing the BeanInvocation proxy itself with the
>> > actual body to be rendered contained with in it.
>> >
>> > I ran into this before in an different situation and ended up removing
>> the
>> > @Produce although I was actually able to cause it to work correctly by
>> an
>> > indirect bean call on it which seems to have cause the proxy to divulge
>> its
>> > contents.
>> >
>> > In this particular case I'm invoking the interface which sends it to a
>> > second route that sets other information like to/from/subject and then
>> uses
>> > a recipientList to invoke the velocity template I've specified for that
>> > particular error message.
>> >
>> > Brad
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>
>

Re: @Produce vs @ProducerTemplate

[Brad Johnson <br...@mediadriver.com>]

I'm using 2.15.x in Fuse 6.2 and experimenting with Camel 2.17 and CDI in
Fuse 6.3 which I downloaded.  But I don't really need the Fuse container
for the testing with the CDI test runner.

I really like the way this is all going.

Brad

On Thu, Aug 11, 2016 at 8:32 AM, Claus Ibsen <cl...@gmail.com> wrote:

> What version of Camel are you using?
>
> From Camel 2.16 onwards @Produce / proxy should use bean parameter
> binding by default
> http://camel.apache.org/using-camelproxy.html
>
> On Mon, Aug 8, 2016 at 4:02 PM, Brad Johnson
> <br...@mediadriver.com> wrote:
> > I use producer template quite a bit and it works well but it obviously
> is a
> > bit more coupled to the Camel API than using the @Produce with an
> interface.
> >
> > The problem is I can't tell exactly when @Produce is going to work as I
> > expect it to.  Currently I have two routes, for example, one that makes a
> > call to a direct route to do a look up and return a field during
> > processing.  It works fine.
> >
> > A second route that I have is similar but it sends a String fileName to a
> > an error route to send and email via a velocity template.  If I use the
> > ProducerTemplate that works fine.  If I use the @Produce what I end up
> with
> > is the body rendered showing the BeanInvocation proxy itself with the
> > actual body to be rendered contained with in it.
> >
> > I ran into this before in an different situation and ended up removing
> the
> > @Produce although I was actually able to cause it to work correctly by an
> > indirect bean call on it which seems to have cause the proxy to divulge
> its
> > contents.
> >
> > In this particular case I'm invoking the interface which sends it to a
> > second route that sets other information like to/from/subject and then
> uses
> > a recipientList to invoke the velocity template I've specified for that
> > particular error message.
> >
> > Brad
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: @Produce vs @ProducerTemplate

[Claus Ibsen <cl...@gmail.com>]

What version of Camel are you using?

From Camel 2.16 onwards @Produce / proxy should use bean parameter
binding by default
http://camel.apache.org/using-camelproxy.html

On Mon, Aug 8, 2016 at 4:02 PM, Brad Johnson
<br...@mediadriver.com> wrote:
> I use producer template quite a bit and it works well but it obviously is a
> bit more coupled to the Camel API than using the @Produce with an interface.
>
> The problem is I can't tell exactly when @Produce is going to work as I
> expect it to.  Currently I have two routes, for example, one that makes a
> call to a direct route to do a look up and return a field during
> processing.  It works fine.
>
> A second route that I have is similar but it sends a String fileName to a
> an error route to send and email via a velocity template.  If I use the
> ProducerTemplate that works fine.  If I use the @Produce what I end up with
> is the body rendered showing the BeanInvocation proxy itself with the
> actual body to be rendered contained with in it.
>
> I ran into this before in an different situation and ended up removing the
> @Produce although I was actually able to cause it to work correctly by an
> indirect bean call on it which seems to have cause the proxy to divulge its
> contents.
>
> In this particular case I'm invoking the interface which sends it to a
> second route that sets other information like to/from/subject and then uses
> a recipientList to invoke the velocity template I've specified for that
> particular error message.
>
> Brad



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2