WS-Addressing headers missing from synchronous SOAP responses [SWS-870]

[gregturn]

Ivan Brencsics opened SWS-870 and commented

WS-Addressing headers are missing from synchonous SOAP responses:
env:Header/

By debugging Spring-WS, we found that the AddressingEndpointInterceptor inserts the header values correctly in the SOAPMessage, and even the SOAPMessage parameter of the Saaj13Implementation.writeTo() contains the right WS headers. But when message.writeTo(outputStream) is called, the headers are not serialized.

If in the beginning of the method Saaj13Implementation.writeTo() we call message.saveChanges() without checking message.saveRequired(), the WS-A headers are serialized correctly. We assume that the flag that controls if save is needed might not be correctly set by a previous method.

---

Affects: 2.1.4

Issue Links:

• Security Headers missing with XwsSecurityInterceptor and Spring Integration [SWS-871] #945 Security Headers missing with XwsSecurityInterceptor and Spring Integration
  ("is duplicated by")

Referenced from: commits 06d7356

[gregturn]

Arjen Poutsma commented

Could you please indicate your runtime environment? (JDK, app server, etc. with version numbers).

[gregturn]

Ivan Brencsics commented

Please find the parameters here:

$ /usr/java/default/bin/java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode, sharing)

$ cat /etc/release
CentOS release 5.10 (Final)

Apache Tomcat Version 7.0.37

[gregturn]

Arjen Poutsma commented

Thanks!
The reason I asked is that we got two similar issues around the same time (this one and #945), while I don't recollect making any changes in the header code recently. I suspected it might have had something to do with JDK 8 coming out and changing SAAJ behavior, but that doesn't seem to be the case.

I will investigate further next week.

[gregturn]

Ivan Brencsics commented

Thanks a lot for investigating. I also noticed that the other ticket (871) has the same problem, and the same conclusion. Probably it is not an accident. Although I cant imagine what could happen to SAAJ, but the fact is that if I call the saveChanges() unconditionally, the WSA headers are serialized correclty.

[gregturn]

Arjen Poutsma commented

Indeed, it appears that changing it to an unconditional saveChanges() would do the trick.

But first I would like to understand what caused these two bugs to appear all of a sudden, when the underlying SAAJ code in Spring-WS has been pretty much the same since version 1.0 was released over five years ago. We've never had SOAP headers disappear in all that time, and now we get two reports on a single day. That much coincidence makes me suspicious and I want to investigate it more.

[gregturn]

Matthew Leese commented

I also found it quite the coincidence that both bug reports were written on the same day.

I was able to track down our issue to Spring Integration. The DefaultSoapHeaderMapper sets the SOAP action on the SOAPMessage (this functionality was added in Spring Integration 2.1). This causes the SOAPMessage to call saveChanges() which sets needsSave to false. After this, the security headers are added. When SOAPMessage.writeTo() is called, it doesn't call saveChanges() again because needsSave is false.

So I think the true culprit is the changes made in Spring Integration. They just excercise an underlying bug in Spring WS.

Incidentally, SOAPMessage.writeTo() sets needsSave to true so if you set on the trace level logging on the WebServiceTemplate, the message transmission will work with the security headers attached.

[gregturn]

Arjen Poutsma commented

Ivan Brencsics are you also using Spring Integration, by any chance?

[gregturn]

Ivan Brencsics commented

No, we dont use Spring Integration.

[gregturn]

Ivan Brencsics commented

I did some investigation, but still confused. The SAAJ MessageImpl.needsSave() method has this comment: "All write methods (i.e setters) should call this method in order to make sure that a save is necessary since the state has been modified".

The only thing I can imagine is that in some setter in SAAJ the needsMethod() is not called, and finally in the Saaj13Implementation the saveChanges() is not triggered. Maybe it would make sense calling the needsSave() manually as the last step of the interceptors that inject the WSS, WSA headers.

[gregturn]

Ivan Brencsics commented

I can confirm what Matthew wrote. If I set the logging level to TRACE for the org.springframework.ws package, the problem is fixed. In case of TRACE level:

1. in the log entry the WSA headers are missing (the first call to writeTo() is not correct), but the save flag is configured
2. but when the Saaj13Implementation calls the writeTo() the second time, the WSA headers are correct on the wire.

[gregturn]

Arjen Poutsma commented

Fixed by calling saveChanges unconditionally now. Thanks for the help, everybody.

[gregturn]

Ivan Brencsics commented

Let me just share here that there might be a side effect of this fix:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=444222
https://java.net/jira/browse/SAAJ-75