[SWS-483] Wss4j 1.5.5 stripping custom SOAP headers after 1.5.6 upgrade Created: 10/Feb/09  Updated: 04/May/12  Resolved: 19/May/09

Status: Closed
Project: Spring Web Services
Component/s: None
Affects Version/s: 1.5.6
Fix Version/s: 1.5.7

Type: Bug Priority: Major
Reporter: Paul Dotsenko Assignee: Arjen Poutsma
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

Attachments: Text File 483-test.patch     File spring-ws-echo.zip    
Reference URL: http://forum.springframework.org/showthread.php?p=225931#post225931


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.

Comment by Paul Dotsenko [ 10/Feb/09 ]

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.

Comment by Tareq Abedrabbo [ 23/Mar/09 ]

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

Comment by Tareq Abedrabbo [ 12/May/09 ]

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

Comment by Arjen Poutsma [ 19/May/09 ]

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


while the following do not:


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.

Comment by Arjen Poutsma [ 19/May/09 ]

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.

Comment by Arjen Poutsma [ 19/May/09 ]


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.

Comment by Paul Dotsenko [ 19/May/09 ]

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

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Tue Nov 20 22:14:48 UTC 2018 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.