Spring ws can fail on Java 10 due to error in wss4j usage of java api

[eivinhb]

ref.: https://issues.apache.org/jira/browse/WSS-627
(https://issues.apache.org/jira/browse/WSS-605)

This is solved on release 2.2.2 of wss4j.

Although wss4j:2.2.2 is a patch release, I suspect that, since for instance updates to woodstox-core-asl from org.codehaus to com.fasterxml, this can be a breaking change.

Example stacktrace of failing runtume:
org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it.
at java.xml/com.sun.org.apache.xerces.internal.dom.ParentNode.internalInsertBefore(ParentNode.java:356)
at java.xml/com.sun.org.apache.xerces.internal.dom.ParentNode.insertBefore(ParentNode.java:287)
at java.xml/com.sun.org.apache.xerces.internal.dom.NodeImpl.appendChild(NodeImpl.java:237)
at org.apache.wss4j.dom.util.WSSecurityUtil.prependChildElement(WSSecurityUtil.java:314)
at org.apache.wss4j.dom.util.WSSecurityUtil.findWsseSecurityHeaderBlock(WSSecurityUtil.java:435)
at org.apache.wss4j.dom.message.WSSecHeader.insertSecurityHeader(WSSecHeader.java:165)
at org.apache.wss4j.dom.handler.WSHandler.doSenderAction(WSHandler.java:117)
at org.springframework.ws.soap.security.wss4j2.Wss4jHandler.doSenderAction(Wss4jHandler.java:63)
at org.springframework.ws.soap.security.wss4j2.Wss4jSecurityInterceptor.secureMessage(Wss4jSecurityInterceptor.java:574)
at org.springframework.ws.soap.security.AbstractWsSecurityInterceptor.handleRequest(AbstractWsSecurityInterceptor.java:210)
at org.springframework.ws.client.core.WebServiceTemplate.doSendAndReceive(WebServiceTemplate.java:597)
at org.springframework.ws.client.core.WebServiceTemplate.sendAndReceive(WebServiceTemplate.java:555)
at org.springframework.ws.client.core.WebServiceTemplate.marshalSendAndReceive(WebServiceTemplate.java:390)

[eivinhb]

I have found another way to show this problem:

If you change saaj-impl.version to 1.4.0 or 1.5.0, which is often on classpath in my experience, and run the profile java11 with java 11 all the SaajWss4j*-tests will fail with org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it.

But with this PR merged, that will not happen, regardless of saaj-versjon or java-version.

[eivinhb]

Anyone? @gregturn
We need this addressed to be able to deploy production on java 11.

[gregturn]

@eivinhb I'm looking into your issue. My curiosity is why this isn't failing on the CI server with the master branch given Spring WS now builds against Java 8 and 11.

Is there a missing test case we need to expose this?

My concern with your pull request is that it requires bumping up a dependency to a new major version. That would be a breaking change, and something to save for Spring WS 3.1.

[eivinhb]

So nice to hear from you! Yes, the bumping here is a problem.

The tests will fail if you upgrade to saaj-impl 1.4 and run the java11 profile on java 11. I have not looked into what has change between saaj 1.3.38 and 1.4.

Anyway, I guess that many are infact running a newer version of saaj-impl and it is that combination that is troublesome on java >= 9.

[gregturn]

The first problem you reported isn't Java 11. It appears to be wss4j creating a breaking change in 2.2.2. 2.2.1 works fine but breaks in 2.2.2 with:

java.lang.NoSuchMethodError: org.apache.xml.security.utils.XMLUtils.decode(Ljava/lang/String;)[B

No deprecation hint in sight.

I will look at your SAAJ issue as well. But for now, you basically can't proceed with wss4j 2.2.2. If you are picking that yourself, then downgrade to 2.2.1. If something else is pulling that in, I would like to know where.

[gregturn]

Okay, that may been me not bumping up xmlsec.

[eivinhb]

Yes. I had a kind lf cascade-update-session myself. :)

[gregturn]

When I do this, it works on Java 11...

diff --git a/pom.xml b/pom.xml
index 33d445d6..42fb3585 100644
--- a/pom.xml
+++ b/pom.xml
@@ -93,7 +93,7 @@
                <commons-io.version>2.5</commons-io.version>
                <dom4j.version>1.6.1</dom4j.version>
                <easymock.version>3.6</easymock.version>
-               <ehcache.version>2.10.4</ehcache.version>
+               <ehcache.version>2.10.5</ehcache.version>
                <httpclient.version>4.5.3</httpclient.version>
                <javax-mail.version>1.6.0</javax-mail.version>
                <javax-servlet.version>3.1.0</javax-servlet.version>
@@ -106,7 +106,7 @@
                <log4j2.version>2.11.0</log4j2.version>
                <mail.version>1.4.7</mail.version>
                <mock-javamail.version>1.9</mock-javamail.version>
-               <saaj-impl.version>1.3.28</saaj-impl.version>
+               <saaj-impl.version>1.4.0</saaj-impl.version>
                <slf4j.version>1.7.25</slf4j.version>
                <smack.version>4.2.1</smack.version>
                <soap-api.version>1.4.0</soap-api.version>
@@ -116,8 +116,8 @@
                <sun-mail.version>1.6.0</sun-mail.version>
                <woodstox.version>4.2.0</woodstox.version>
                <wsdl4j.version>1.6.3</wsdl4j.version>
-               <wss4j.version>2.2.0</wss4j.version>
-               <xmlsec.version>2.1.0</xmlsec.version>
+               <wss4j.version>2.2.2</wss4j.version>
+               <xmlsec.version>2.1.2</xmlsec.version>
                <xml-schema-core.version>2.2.2</xml-schema-core.version>
                <xmlunit.version>1.5</xmlunit.version>
                <xws-security.version>3.0</xws-security.version>

That would still be a breaking change to move up from SAAJ 1.3 to 1.4.

[gregturn]

Essentially you should be able to deploy to Java 11 with those precise versions as overrides in your app. It’s an unsupported combination for Spring WS 3.0.

I don’t know when we will create 3.1. Probably driven by Spring Boot’s schedule.

[eivinhb]

Yes. And that is what we have done for now. But it hurts with lots of excludes on dependencies.

[gregturn]

This has now been updated per #1167 and bc633b7.