ClassCastException when receiving encrypted SOAP message with whitespace before payload

[jpwilhelms]

Bug Report

When the server receives an encrypted SOAP message that contains whitespace immediately before the payload, it throws a ClassCastException.

Steps to Reproduce

1. Send an encrypted SOAP message to the server with whitespace characters (such as spaces or newlines) just before the payload element.
2. Observe the server behavior.

Expected Behavior

The server should correctly process the encrypted SOAP message, ignoring any whitespace before the payload.

Actual Behavior

The server throws a java.lang.ClassCastException: class com.sun.org.apache.xerces.internal.dom.TextImpl cannot be cast to class jakarta.xml.soap.Node (com.sun.org.apache.xerces.internal.dom.TextImpl is in module java.xml of loader 'bootstrap'; jakarta.xml.soap.Node is in unnamed module of loader 'app') when whitespace precedes the payload in an encrypted message.

Additional Context

• I have prepared a minimal sample application for reproducing the issue: demo

Environment

• Spring WS version: 4.0.13
• JDK version: 21.0.5

Thank you.

[snicoll]

Thanks again for the report and the sample. I had a look to WhitespaceInjectorInterceptor and this looks a bit artificial to me. Even more so than the classcast comes from saaj, not Spring-WS. I am not entirely sure what you expect Spring-WS to do.

We could look at the child element and then decide to go to the next sibling but I am wary of what the side-effects would be. There's also the encrypted side of things that I haven't investigated yet.

[jpwilhelms]

The issue is actually occurring in a production project of mine. Locally, everything works perfectly, but once the system is deployed and starts receiving real requests from actual clients, it fails with the ClassCastException.

Because the requests are encrypted, I wasn’t able to identify the root cause until yesterday — I’ve been analyzing the problem for two weeks and initially suspected incompatible XML libraries in the operator’s Tomcat environment.

Now that I’ve successfully decrypted one of the problematic requests, I found newline characters at the beginning of the payload block. The WhitespaceInjectorInterceptor simulates the behavior of such a client.

If I disable encryption and send the same request with only "Timestamp" as the securementActions, it is processed without any issues. This indicates that the error is indeed related to the decryption step.

[snicoll]

There's #1228 as well.