You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Lars Ivar Igesund <la...@igesund.net> on 2009/01/19 20:21:54 UTC
Responses to CXF messages in Camel route
Hi!
I have had a working CXF endpoint (server) connected to my route for a
short while now, but the service only had an in message and the route
looked like this:
from (cxfEndpoint).process(new FooProcessor()).to ( "bean:FooHandler");
However, the caller of the service wants a response which is fairly
simple. OK if the processor (which I guess really should be transform
instead) succeeds, an error message describing the issue if it fails.
So I defined an out message for the operation, and in the first test
(for OK), I expected to be able to do
from (cxfEndpoint).process(new FooProcessor()).to (
"bean:FooHandler").transform(constant(OK));
This does however fail in the handler step because the out message of
the exchange processed in the FooProcessor is no longer a FooMessage
(even if I do exchange.getOut().setBody(new FooMessage()); but rather
a CxfMessage.
I always assume that I use the API wrong, but in this case the router
acts inconsistently depending on whether the exchange expects an out
message or not. I thought that the out message part where it is
returned to the originating endpoint only should happen at the end of
the route.
As for the fault, I think I want to use the exchange.getFault()
message, but I had some trouble finding a WSDL example where such a
message is defined.
Please help me suggest how the route should look, how to propagate the
messages correctly and properly and how to define the fault message
(in the WSDL). Actually, can I possibly just put an Exception instance into
the fault message?
Best,
Lars Ivar
Re: Responses to CXF messages in Camel route
Posted by Willem Jiang <wi...@gmail.com>.
Just one more note, please take a look at CXF example[1][2], when you
run mvn install in the camel-example-cxf, you will see the generated
PingMeFault in the targe/generated/src/main/java directory.
[1] http://svn.apache.org/viewvc/camel/trunk/examples/camel-example-cxf
[2] http://camel.apache.org/cxf-example.html
Willem Jiang wrote:
> Hi Lars,
>
> Can you show me the detail code of FooProcessor() ?
>
> If you take a look at the PipeLine(which chains these endpoints and
> processor together), you will find the codes about copying exchanges
> between these endpoints and processors.
>
> // now lets set the input of the next exchange to the output of the
> // previous message if it is not null
> Message previousOut = previousExchange.getOut(false);
> Message in = answer.getIn();
> if (previousOut != null) {
> in.copyFrom(previousOut);
> } else {
> in.copyFrom(previousExchange.getIn());
> }
> return answer;
> lets take the exchange which will be passed to bean:FooHandler as an
> example.
> If you set the out message for the FooProcessor exchange,
> bean:FooHandler's exchange's in message will be the previous exchange's
> out message.
> If you don't set the out message for the FooProcessor exchange,
> bean:FooHandler's exchange's in message will be the previous exchange's
> in message.
>
> For the fault message part, camel-cxf component supports to through the
> soap fault here [1]. If I remember right, when you set the exchange's
> fault message, cxf will marshal it into soap fault message. Please feel
> free to try it.
>
> [1]http://camel.apache.org/cxf.html#CXF-HowtothrowtheSOAPFaultfromCamel
>
> Willem
>
> Lars Ivar Igesund wrote:
>> Hi!
>>
>> I have had a working CXF endpoint (server) connected to my route for a
>> short while now, but the service only had an in message and the route
>> looked like this:
>>
>> from (cxfEndpoint).process(new FooProcessor()).to ( "bean:FooHandler");
>>
>> However, the caller of the service wants a response which is fairly
>> simple. OK if the processor (which I guess really should be transform
>> instead) succeeds, an error message describing the issue if it fails.
>>
>> So I defined an out message for the operation, and in the first test
>> (for OK), I expected to be able to do
>>
>> from (cxfEndpoint).process(new FooProcessor()).to (
>> "bean:FooHandler").transform(constant(OK));
>>
>> This does however fail in the handler step because the out message of
>> the exchange processed in the FooProcessor is no longer a FooMessage
>> (even if I do exchange.getOut().setBody(new FooMessage()); but rather
>> a CxfMessage.
>>
>> I always assume that I use the API wrong, but in this case the router
>> acts inconsistently depending on whether the exchange expects an out
>> message or not. I thought that the out message part where it is
>> returned to the originating endpoint only should happen at the end of
>> the route.
>>
>> As for the fault, I think I want to use the exchange.getFault()
>> message, but I had some trouble finding a WSDL example where such a
>> message is defined.
>>
>> Please help me suggest how the route should look, how to propagate the
>> messages correctly and properly and how to define the fault message
>> (in the WSDL). Actually, can I possibly just put an Exception instance into
>> the fault message?
>>
>> Best,
>> Lars Ivar
>>
>>
>
>
Re: Responses to CXF messages in Camel route
Posted by Lars Ivar Igesund <la...@igesund.net>.
Hi,
I was able to get an acceptable solution working, so I won't try anymore until
we eventually have to upgrade. Since we are using Camel 1.4.0, I suspect there
are multiple issues at hand. Just to recapitulate:
FooProcessor sets the body of the out message of the incoming exchange. In the
initial setup with no response message in the web service, this works
perfectly. By modifying the wsdl to include a response ( "out" ) in the
operation, it no longer works, because the message passed on from the
FooProcessor is of type CxfMessage.
As for fault messages, these works as expected as soon as I figured out I had
to create a Throwable.
Claus; I used chapter 5 of that tutorial as inspiration, and it is my
impression that it does not work as advertised with Camel 1.4.0.
Thank you very much for your patience, I'm now probably off the Camel train
for at least 6 months.
Lars Ivar
Tysdag 20. januar 2009 14:10:00 skreiv Willem Jiang:
> Hi Lars,
>
> Can you show me the detail code of FooProcessor() ?
>
> If you take a look at the PipeLine(which chains these endpoints and
> processor together), you will find the codes about copying exchanges
> between these endpoints and processors.
>
> // now lets set the input of the next exchange to the output of the
> // previous message if it is not null
> Message previousOut = previousExchange.getOut(false);
> Message in = answer.getIn();
> if (previousOut != null) {
> in.copyFrom(previousOut);
> } else {
> in.copyFrom(previousExchange.getIn());
> }
> return answer;
> lets take the exchange which will be passed to bean:FooHandler as an
> example.
> If you set the out message for the FooProcessor exchange,
> bean:FooHandler's exchange's in message will be the previous exchange's
> out message.
> If you don't set the out message for the FooProcessor exchange,
> bean:FooHandler's exchange's in message will be the previous exchange's
> in message.
>
> For the fault message part, camel-cxf component supports to through the
> soap fault here [1]. If I remember right, when you set the exchange's
> fault message, cxf will marshal it into soap fault message. Please feel
> free to try it.
>
> [1]http://camel.apache.org/cxf.html#CXF-HowtothrowtheSOAPFaultfromCamel
>
> Willem
>
> Lars Ivar Igesund wrote:
> > Hi!
> >
> > I have had a working CXF endpoint (server) connected to my route for a
> > short while now, but the service only had an in message and the route
> > looked like this:
> >
> > from (cxfEndpoint).process(new FooProcessor()).to ( "bean:FooHandler");
> >
> > However, the caller of the service wants a response which is fairly
> > simple. OK if the processor (which I guess really should be transform
> > instead) succeeds, an error message describing the issue if it fails.
> >
> > So I defined an out message for the operation, and in the first test
> > (for OK), I expected to be able to do
> >
> > from (cxfEndpoint).process(new FooProcessor()).to (
> > "bean:FooHandler").transform(constant(OK));
> >
> > This does however fail in the handler step because the out message of
> > the exchange processed in the FooProcessor is no longer a FooMessage
> > (even if I do exchange.getOut().setBody(new FooMessage()); but rather
> > a CxfMessage.
> >
> > I always assume that I use the API wrong, but in this case the router
> > acts inconsistently depending on whether the exchange expects an out
> > message or not. I thought that the out message part where it is
> > returned to the originating endpoint only should happen at the end of
> > the route.
> >
> > As for the fault, I think I want to use the exchange.getFault()
> > message, but I had some trouble finding a WSDL example where such a
> > message is defined.
> >
> > Please help me suggest how the route should look, how to propagate the
> > messages correctly and properly and how to define the fault message
> > (in the WSDL). Actually, can I possibly just put an Exception instance
> > into the fault message?
> >
> > Best,
> > Lars Ivar
Re: Responses to CXF messages in Camel route
Posted by Willem Jiang <wi...@gmail.com>.
Hi Lars,
Can you show me the detail code of FooProcessor() ?
If you take a look at the PipeLine(which chains these endpoints and
processor together), you will find the codes about copying exchanges
between these endpoints and processors.
// now lets set the input of the next exchange to the output of the
// previous message if it is not null
Message previousOut = previousExchange.getOut(false);
Message in = answer.getIn();
if (previousOut != null) {
in.copyFrom(previousOut);
} else {
in.copyFrom(previousExchange.getIn());
}
return answer;
lets take the exchange which will be passed to bean:FooHandler as an
example.
If you set the out message for the FooProcessor exchange,
bean:FooHandler's exchange's in message will be the previous exchange's
out message.
If you don't set the out message for the FooProcessor exchange,
bean:FooHandler's exchange's in message will be the previous exchange's
in message.
For the fault message part, camel-cxf component supports to through the
soap fault here [1]. If I remember right, when you set the exchange's
fault message, cxf will marshal it into soap fault message. Please feel
free to try it.
[1]http://camel.apache.org/cxf.html#CXF-HowtothrowtheSOAPFaultfromCamel
Willem
Lars Ivar Igesund wrote:
> Hi!
>
> I have had a working CXF endpoint (server) connected to my route for a
> short while now, but the service only had an in message and the route
> looked like this:
>
> from (cxfEndpoint).process(new FooProcessor()).to ( "bean:FooHandler");
>
> However, the caller of the service wants a response which is fairly
> simple. OK if the processor (which I guess really should be transform
> instead) succeeds, an error message describing the issue if it fails.
>
> So I defined an out message for the operation, and in the first test
> (for OK), I expected to be able to do
>
> from (cxfEndpoint).process(new FooProcessor()).to (
> "bean:FooHandler").transform(constant(OK));
>
> This does however fail in the handler step because the out message of
> the exchange processed in the FooProcessor is no longer a FooMessage
> (even if I do exchange.getOut().setBody(new FooMessage()); but rather
> a CxfMessage.
>
> I always assume that I use the API wrong, but in this case the router
> acts inconsistently depending on whether the exchange expects an out
> message or not. I thought that the out message part where it is
> returned to the originating endpoint only should happen at the end of
> the route.
>
> As for the fault, I think I want to use the exchange.getFault()
> message, but I had some trouble finding a WSDL example where such a
> message is defined.
>
> Please help me suggest how the route should look, how to propagate the
> messages correctly and properly and how to define the fault message
> (in the WSDL). Actually, can I possibly just put an Exception instance into
> the fault message?
>
> Best,
> Lars Ivar
>
>
Re: Responses to CXF messages in Camel route
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
At part 5 of this tutorial I can send a OK response.
http://camel.apache.org/tutorial-example-reportincident-part5.html
On Mon, Jan 19, 2009 at 8:21 PM, Lars Ivar Igesund <la...@igesund.net> wrote:
> Hi!
>
> I have had a working CXF endpoint (server) connected to my route for a
> short while now, but the service only had an in message and the route
> looked like this:
>
> from (cxfEndpoint).process(new FooProcessor()).to ( "bean:FooHandler");
>
> However, the caller of the service wants a response which is fairly
> simple. OK if the processor (which I guess really should be transform
> instead) succeeds, an error message describing the issue if it fails.
>
> So I defined an out message for the operation, and in the first test
> (for OK), I expected to be able to do
>
> from (cxfEndpoint).process(new FooProcessor()).to (
> "bean:FooHandler").transform(constant(OK));
>
> This does however fail in the handler step because the out message of
> the exchange processed in the FooProcessor is no longer a FooMessage
> (even if I do exchange.getOut().setBody(new FooMessage()); but rather
> a CxfMessage.
>
> I always assume that I use the API wrong, but in this case the router
> acts inconsistently depending on whether the exchange expects an out
> message or not. I thought that the out message part where it is
> returned to the originating endpoint only should happen at the end of
> the route.
>
> As for the fault, I think I want to use the exchange.getFault()
> message, but I had some trouble finding a WSDL example where such a
> message is defined.
>
> Please help me suggest how the route should look, how to propagate the
> messages correctly and properly and how to define the fault message
> (in the WSDL). Actually, can I possibly just put an Exception instance into
> the fault message?
>
> Best,
> Lars Ivar
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/