Sorry but I misunderstood that behavior.
SJMS is designed to be agressive, meaning that the intent of the message
flow is expected at initialization so the endpoint can be optimized with
all necessary resources cached. In this case the producer has already been
created and cached as an InOnly handler. Because of my misunderstanding
there isn't a path for changing the MEP at runtime.
I will take a look at a redesign to accomodate both initialization and
runtime management of the endpoint. I am not sure that would be ready
though for 2.11 given that it appears to be immanent.
Any concerns?
On Tue, Feb 12, 2013 at 12:14 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> On Mon, Feb 11, 2013 at 5:56 PM, Scott England-Sullivan
> <sully6...@gmail.com> wrote:
> > After looking at it they don't appear to behave the same. The parameter
> sets the exchange pattern at initialization while the inOut() method sets
> the exchange at runtime.
> >
> > Is that what you would expect Claus?
> >
>
> Yes, there is a difference.
> InOut will set the MEP to InOut and after the call, restore it back to
> what it was before.
>
> But the SJMS producer should likely detect the MEP on the Exchange and
> react accordingly.
> This is what we do in camel-jms.
>
> There is ExchangeHelper.isOutCapable(exchange) we use to detect if we
> want to do request/reply or one way.
>
>
> > Scott England-Sullivan
> > blog:sully6768.blogspot.com twitter:@sully6768
> >
> > On Feb 9, 2013, at 9:51 PM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> >
> >> On Sat, Feb 9, 2013 at 4:05 PM, Harald Wellmann <hwellmann...@gmail.com>
> wrote:
> >>> I'm rather confused by the different flavours of InOut.
> >>>
> >>> What's the difference between
> >>>
> >>> 1) from("direct:calculatorProxy")
> >>> .inOut("sjms:calculator-queue");
> >>>
> >>> and
> >>>
> >>> 2) from("direct:calculatorProxy")
> >>> .to("sjms:calculator-queue?exchangePattern=InOut");
> >>>
> >>> inOut() in 1) does not seem to make any difference from to() at all.
> >>
> >> Its the same.
> >>
> >> There is a couple of ways of doing this. See the request-reply eip
> pattern.
> >> http://camel.apache.org/request-reply.html
> >>
> >> And when using Java code, you can also read the javadoc of the methods
> >> as well as they may also contains some information.
> >>
> >>
> >>
> >>
> >>> Best regards,
> >>> Harald
> >>
> >>
> >>
> >> --
> >> Claus Ibsen
> >> -----------------
> >> Red Hat, Inc.
> >> FuseSource is now part of Red Hat
> >> Email: cib...@redhat.com
> >> Web: http://fusesource.com
> >> Twitter: davsclaus
> >> Blog: http://davsclaus.com
> >> Author of Camel in Action: http://www.manning.com/ibsen
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cib...@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
--
--
Scott England-Sullivan
Apache Camel Committer
Principal Consultant / Sr. Architect | Red Hat, Inc.
FuseSource is now part of Red Hat
Web: fusesource.com <http://www.fusesource.com> |
redhat.com<http://www.redhat.com>
Blog: sully6768.blogspot.com
Twitter: sully6768
