[CAMEL-5234] Spring-WS does neither set message body nor message headers if exchange is not outCapable

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.7.5, 2.8.4, 2.9.2
• Fix Version/s: 2.9.3, 2.10.0
• Component/s: camel-spring-ws
• Labels: in out out-capable response spring-ws
• Estimated Complexity: Unknown
• Assignee: Babak Vahdat
• Reporter: Benjamin Gniza
• Created: 30/Apr/12 17:15
• Updated: 11/Jun/12 21:10
• Resolved: 08/Jun/12 16:22

Description

Spring-WS component does not behave as expected from pipes and filters pattern if exchange is not outCapable.
If ExchangeHelper.isOutCapable returns false for the given exchange the IN-message is returned instead of the WS-Response.
Example:

ExampleRoute

        from("timer://foo?fixedRate=true&period=1000")//
                .setBody().simple("<ex:getExampleResponse xmlns:ex=\"http://example.com/\">" //
                        + "       <id>1</id>" //
                        + "     </ex:getExampleResponse>")//
                .to("spring-ws:http://localhost:9000/Example")//
                .to("file://responses");

In the example above I would expect the WS-response written to the files in the responses directory. Currently (since 2.7.3) the IN message is written to the files.
This is caused by SpringWebserviceProducer#process because it only sets headers and body for the OUT-message if isOutCapable is true.

Workaround (maybe this has side effects!):

ExampleRoute

                from("timer://foo?fixedRate=true&period=1000")//
                .setExchangePattern(ExchangePattern.InOut) // <-- Override with InOut Pattern
                .setBody().simple("<ex:getExampleResponse xmlns:ex=\"http://example.com/\">" //
                        + "       <id>1</id>" //
                        + "     </ex:getExampleResponse>")//
                .to("spring-ws:http://localhost:9000/Example")//
                .to("file://responses");

This behavior has been implemented to fix CAMEL-3974. From my point of view its counter intuitive since other processing-steps don't check the exchange's outCapability.
It took me several hours to find out why I always got the IN message back, although the webservice was called correctly and returned correct results.
Maybe an option should be provided to control this behavior. At least a log-message should be written to explain, that the webservice-reponse is thrown away.