Camel
  1. Camel
  2. CAMEL-5234

Spring-WS does neither set message body nor message headers if exchange is not outCapable

    Details

    • Estimated Complexity:
      Unknown

      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.

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            Babak Vahdat
            Reporter:
            Benjamin Gniza
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development