Camel + Spring DSL + InMemorySagaService
Hi, I would like to understand how to add Camel's InMemorySagaService using Spring DSL as mentioned in JAVA DSL at https://github.com/apache/camel/blob/d5ba98ed43229afe1c1aa24e8e3d6492460d8bd4/camel-core/src/test/java/org/apache/camel/processor/SagaTest.java#L100-L101 Thanks & Regards, Sanjeev
strange error handling in Camel CXF (SOAP) for HTTP 500
By accident I came across a strange behavior when simulating error situations for a CXF producer endpoint. As route starting point I use also a CXF endpoint. There is actually no additional configuration like WSDL or steps between the endpoints. Now I configured the simulator endpoint (which is another camel route using http consumer) to return the response code http 500 and an XML payload which is not a SOAP Fault. The CXF consumer endpoint that started the route delivers this response payload and http 200 as return code. I checked Basic Profile Version 1.0 and they only write for a WS provider you have to set http 500 if a SOAP fault is returned. Currently CXF will not execute the fault interceptor chain but a user that directly calls CXF has at least a chance to check the http return code and react appropriately. The current behavior in the Camel route might finally lead to an unexpected behavior. Is this the desired behavior? Thanks in advance! Jörg
Re: Camel + Spring DSL + InMemorySagaService
Hi Can you try just to add a of this type, then it may auto-detect this bean automatic. If not we should probably add such a feature. On Fri, Dec 14, 2018 at 10:08 AM Sanjeev Kumar wrote: > > Hi, > > I would like to understand how to add Camel's InMemorySagaService using > Spring DSL as mentioned in JAVA DSL at > https://github.com/apache/camel/blob/d5ba98ed43229afe1c1aa24e8e3d6492460d8bd4/camel-core/src/test/java/org/apache/camel/processor/SagaTest.java#L100-L101 > > Thanks & Regards, > Sanjeev -- Claus Ibsen - http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
understanding InOut
I still don't quite grok how InOut works. When I set the exchange
pattern to InOut, what exactly will happen? Will the *next*
processor
reply to the previous one? If so, how? If so, how does the
previous
processor act on the reply? Or is the InOut just about 1
Processor? If
so, can e.g. a Processor block until a split is reaggregated?
I'm trying to find some documentation on this that would explain
these
details but I didn't find much. The request-reply page is brief
and uses
mocks.
As a real world bonus - I'm running a mongodb aggregation pipeline
splitting and streaming and would need to fire just 1 exchange
further
down the route when the whole aggregation is finished. I'm doing
.to("mongodb3://...")
.split(..).streaming()
...
.aggregate(..)
.hereINeed1exchange;
I recently found out that split can take an aggregator as
argument,
would that solve this case? How exactly does that work?
--
To reach a goal one has to enjoy the journey.
Re: understanding InOut
Hi
We have a page here with some details about IN vs OUT
http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html
On Fri, Dec 14, 2018 at 4:29 PM Peter Nagy (Jr) wrote:
>
> I still don't quite grok how InOut works. When I set the exchange
> pattern to InOut, what exactly will happen? Will the *next*
> processor
> reply to the previous one? If so, how? If so, how does the
> previous
> processor act on the reply? Or is the InOut just about 1
> Processor? If
> so, can e.g. a Processor block until a split is reaggregated?
>
> I'm trying to find some documentation on this that would explain
> these
> details but I didn't find much. The request-reply page is brief
> and uses
> mocks.
>
> As a real world bonus - I'm running a mongodb aggregation pipeline
> splitting and streaming and would need to fire just 1 exchange
> further
> down the route when the whole aggregation is finished. I'm doing
>
> .to("mongodb3://...")
> .split(..).streaming()
> ...
> .aggregate(..)
> .hereINeed1exchange;
>
> I recently found out that split can take an aggregator as
> argument,
> would that solve this case? How exactly does that work?
>
> --
> To reach a goal one has to enjoy the journey.
--
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
RE: understanding InOut
I have also found it a bit difficult to get a straight answer on this but my
understanding at this point is that if the exchange gets to the end of the
route and is an InOut, the Out from the last endpoint goes back to the 'from'
starting point.
http://camel.apache.org/request-reply.html
-Steve
> -Original Message-
> From: Peter Nagy (Jr)
> Sent: Friday, December 14, 2018 10:27 AM
> To: users@camel.apache.org
> Subject: understanding InOut
>
> I still don't quite grok how InOut works. When I set the exchange pattern to
> InOut, what exactly will happen? Will the *next* processor reply to the
> previous one? If so, how? If so, how does the previous processor act on the
> reply? Or is the InOut just about 1 Processor? If so, can e.g. a Processor
> block
> until a split is reaggregated?
>
> I'm trying to find some documentation on this that would explain these
> details but I didn't find much. The request-reply page is brief and uses
> mocks.
>
> As a real world bonus - I'm running a mongodb aggregation pipeline splitting
> and streaming and would need to fire just 1 exchange further down the
> route when the whole aggregation is finished. I'm doing
>
> .to("mongodb3://...")
> .split(..).streaming()
> ...
> .aggregate(..)
> .hereINeed1exchange;
>
> I recently found out that split can take an aggregator as argument, would that
> solve this case? How exactly does that work?
>
> --
> To reach a goal one has to enjoy the journey.
Re: understanding InOut
Hi Steve,
and how does the starting point react on the exchange it receives
from
the end? What if the end produces multiple exchanges?
Steve Huston writes:
I have also found it a bit difficult to get a straight answer on
this but my understanding at this point is that if the exchange
gets to the end of the route and is an InOut, the Out from the
last endpoint goes back to the 'from' starting point.
http://camel.apache.org/request-reply.html
-Steve
-Original Message-
From: Peter Nagy (Jr)
Sent: Friday, December 14, 2018 10:27 AM
To: users@camel.apache.org
Subject: understanding InOut
I still don't quite grok how InOut works. When I set the
exchange pattern to
InOut, what exactly will happen? Will the *next* processor
reply to the
previous one? If so, how? If so, how does the previous
processor act on the
reply? Or is the InOut just about 1 Processor? If so, can e.g.
a Processor block
until a split is reaggregated?
I'm trying to find some documentation on this that would
explain these
details but I didn't find much. The request-reply page is brief
and uses mocks.
As a real world bonus - I'm running a mongodb aggregation
pipeline splitting
and streaming and would need to fire just 1 exchange further
down the
route when the whole aggregation is finished. I'm doing
.to("mongodb3://...")
.split(..).streaming()
...
.aggregate(..)
.hereINeed1exchange;
I recently found out that split can take an aggregator as
argument, would that
solve this case? How exactly does that work?
--
To reach a goal one has to enjoy the journey.
--
To reach a goal one has to enjoy the journey.
RE: understanding InOut
> and how does the starting point react on the exchange it receives from the
> end?
Generically, it acts as thought it was the subject of a 'to' at the end. The
exact behavior is probably documented in the endpoint reference info. For
example, the page I referenced below discusses how JMS handles it.
> What if the end produces multiple exchanges?
You've exceeded my knowledge on this... sorry.
> Steve Huston writes:
>
> > I have also found it a bit difficult to get a straight answer on this
> > but my understanding at this point is that if the exchange gets to the
> > end of the route and is an InOut, the Out from the last endpoint goes
> > back to the 'from' starting point.
> >
> > http://camel.apache.org/request-reply.html
> >
> > -Steve
> >
> >> -Original Message-
> >> From: Peter Nagy (Jr)
> >> Sent: Friday, December 14, 2018 10:27 AM
> >> To: users@camel.apache.org
> >> Subject: understanding InOut
> >>
> >> I still don't quite grok how InOut works. When I set the exchange
> >> pattern to InOut, what exactly will happen? Will the *next* processor
> >> reply to the previous one? If so, how? If so, how does the previous
> >> processor act on the reply? Or is the InOut just about 1 Processor?
> >> If so, can e.g.
> >> a Processor block
> >> until a split is reaggregated?
> >>
> >> I'm trying to find some documentation on this that would explain
> >> these details but I didn't find much. The request-reply page is brief
> >> and uses mocks.
> >>
> >> As a real world bonus - I'm running a mongodb aggregation pipeline
> >> splitting and streaming and would need to fire just 1 exchange
> >> further down the route when the whole aggregation is finished. I'm
> >> doing
> >>
> >> .to("mongodb3://...")
> >> .split(..).streaming()
> >> ...
> >> .aggregate(..)
> >> .hereINeed1exchange;
> >>
> >> I recently found out that split can take an aggregator as argument,
> >> would that solve this case? How exactly does that work?
> >>
> >> --
> >> To reach a goal one has to enjoy the journey.
>
>
> --
> To reach a goal one has to enjoy the journey.
