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
