Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-483

Wss4j 1.5.5 stripping custom SOAP headers after 1.5.6 upgrade

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.6
    • Fix Version/s: 1.5.7
    • Component/s: None
    • Labels:
      None
    • Environment:
      Spring-ws 1.5.6, spring-2.5.6, Axiom soap message factory, Wss4j 1.5.5 security interceptor, Java 5, Tomcat 6.0.16

      Description

      I upgraded an existing spring-ws app from 1.5.5 to 1.5.6, and also upgraded dependencies bundled in the with-dependencies release, specifically upgraded wss4j jar from 1.5.4 to 1.5.5 and xmlsec from 1.4.0 to 1.4.2. Now wss4j 1.5.5 somehow strips out my custom SOAP headers on the client side from the request message. Both client and server use spring-ws, I am using Axiom soap message factory (payloadCaching=true), Wss4j for ws-security, running the application in Tomcat 6 with Sun Java 5 jvm.

      Rolling back wss4j libs to wss4j-1.5.4.jar and xmlsec-1.4.0.jar fixes the problem (keeping the other spring-ws 1.5.6 release jars), therefore I suspect this is a Wss4j-1.5.5 bug, but other causes are possible (see other observations below). Proposed solution: roll back the bundled Wss4j jars to wss4j 1.5.4 and xmlsec 1.4.0.

      Other observations:
      1. Sending the SOAP request using soapUI instead of the spring-ws client fixes the problem, proving that the headers are stripped by the spring-ws client.
      2. Removing Wss4j security interceptor fixes the problem.
      3. Switching to SaajSoapMessageFactory fixes the problem.
      4. Spring-ws client trace logger logs the sent SOAP message WITH the custom soap headers intact, so the headers are stripped after the logging code is executed.

      Attached is a sample that reproduces the problem. The sample is a slightly modified echo spring-ws sample pre-configured as an Eclipse project folder. The echo sample was modified to use Wss4j security interceptor, Axiom Soap message factory and I added the code to add custom Soap headers. To reproduce, import the sample into an Eclipse 3.* workspace, deploy spring-ws-echo war to a servlet container, and run org.echo.client.sws.EchoClient as Java applicatio. The logged Soap request on the client contains the "customSoapHeader" header element, but on the server side the same request Soap message is missing this header.

      1. 483-test.patch
        4 kB
        Tareq Abedrabbo

        Activity

        pdotsenko Paul Dotsenko created issue -
        Hide
        pdotsenko Paul Dotsenko added a comment -

        In order to keep the zip file under 10mb I removed the spring-2.5.6 jar file from the project, add it to the WebContent/WEB-INF/lib folder before building.

        Show
        pdotsenko Paul Dotsenko added a comment - In order to keep the zip file under 10mb I removed the spring-2.5.6 jar file from the project, add it to the WebContent/WEB-INF/lib folder before building.
        pdotsenko Paul Dotsenko made changes -
        Field Original Value New Value
        Attachment spring-ws-echo.zip [ 15126 ]
        arjen.poutsma Arjen Poutsma made changes -
        Assignee Arjen Poutsma [ arjen.poutsma ] Tareq Abed Rabbo [ tareq ]
        tareq Tareq Abedrabbo made changes -
        Fix Version/s 1.5.7 [ 11173 ]
        tareq Tareq Abedrabbo made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        tareq Tareq Abedrabbo added a comment -

        Thanks for helpful the sample. I was able to reproduce the problem in a unit test as well. Investigating the cause now...

        Show
        tareq Tareq Abedrabbo added a comment - Thanks for helpful the sample. I was able to reproduce the problem in a unit test as well. Investigating the cause now...
        Hide
        tareq Tareq Abedrabbo added a comment -

        Here's a unit test that should reproduce that issue even though it seemed to pass or fail under different circumstances.

        Show
        tareq Tareq Abedrabbo added a comment - Here's a unit test that should reproduce that issue even though it seemed to pass or fail under different circumstances.
        tareq Tareq Abedrabbo made changes -
        Attachment 483-test.patch [ 15385 ]
        arjen.poutsma Arjen Poutsma made changes -
        Assignee Tareq Abed Rabbo [ tareq ] Arjen Poutsma [ arjen.poutsma ]
        Hide
        arjen.poutsma Arjen Poutsma added a comment - - edited

        I've found that, using WSS4J 1.5.7, the following log4 config does send the custom SOAP header:

        log4j.logger.org.springframework.ws.client.MessageTracing=INFO

        while the following do not:

        log4j.logger.org.springframework.ws.client.MessageTracing=DEBUG
        log4j.logger.org.springframework.ws.client.MessageTracing=TRACE

        Clearly, the error lies in the MessageTracing logging code. The funny thing is that the log4j output does show the header, it's just not sent over the wire.

        Show
        arjen.poutsma Arjen Poutsma added a comment - - edited I've found that, using WSS4J 1.5.7, the following log4 config does send the custom SOAP header: log4j.logger.org.springframework.ws.client.MessageTracing=INFO while the following do not: log4j.logger.org.springframework.ws.client.MessageTracing=DEBUG log4j.logger.org.springframework.ws.client.MessageTracing=TRACE Clearly, the error lies in the MessageTracing logging code. The funny thing is that the log4j output does show the header, it's just not sent over the wire.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        I've been able to create a unit tests that reproduces this behavior consistently. The first time message.writeTo() or message.toString() is called, the custom header is there, but the second time it's gone. Since the MessageTracing logging also invokes either of these methods.

        So, as a workaround until we fix this, you can disable message tracing logging.

        Show
        arjen.poutsma Arjen Poutsma added a comment - I've been able to create a unit tests that reproduces this behavior consistently. The first time message.writeTo() or message.toString() is called, the custom header is there, but the second time it's gone. Since the MessageTracing logging also invokes either of these methods. So, as a workaround until we fix this, you can disable message tracing logging.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Fixed!

        I now make sure the Axiom DOM tree is correctly build by calling envelope.serialize() when creating a new Axiom SOAPEnvelope from the WSS4J DOM Document.

        Show
        arjen.poutsma Arjen Poutsma added a comment - Fixed! I now make sure the Axiom DOM tree is correctly build by calling envelope.serialize() when creating a new Axiom SOAPEnvelope from the WSS4J DOM Document.
        arjen.poutsma Arjen Poutsma made changes -
        Resolution Fixed [ 1 ]
        Status In Progress [ 3 ] Resolved [ 5 ]
        Hide
        pdotsenko Paul Dotsenko added a comment -

        Arjen and Tareq - thanks for your work and fixing this! It was enlightening to follow your comments.

        Show
        pdotsenko Paul Dotsenko added a comment - Arjen and Tareq - thanks for your work and fixing this! It was enlightening to follow your comments.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Closing old issues

        Show
        arjen.poutsma Arjen Poutsma added a comment - Closing old issues
        arjen.poutsma Arjen Poutsma made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        41d 19h 15m 1 Tareq Abedrabbo 23/Mar/09 11:26 PM
        In Progress In Progress Resolved Resolved
        56d 23h 3m 1 Arjen Poutsma 19/May/09 10:29 PM
        Resolved Resolved Closed Closed
        1080d 8h 33m 1 Arjen Poutsma 04/May/12 7:03 AM

          People

          • Assignee:
            arjen.poutsma Arjen Poutsma
            Reporter:
            pdotsenko Paul Dotsenko
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: