The cause of the issue is the inclusion of an XML API jar containing javax/xml/namespace/QName in your application, and that application being configured to use parent-last class loading. When that happens, you get the following linkage pattern:
- Application class references javax/xml/soap/SOAPElement - this class is loaded from the JDK
- SOAPElement references javax/xml/namespace/QName - it loads that using its own class loader, so it's also found in the JDK
- Application class references org/springframework/ws/soap/saaj/SaajSoapElement - this class is loaded from the application
- SaajSoapElement references both SOAPElement and QName - SOAPElement is loaded from the JDK (as before), but QName is loaded from the application, because parent-last class loader delegation requires that the class loader search locally before delegating to parents
- SaajSoapElement now can "see" both copies of QName, and Java throws a LinkageError, because that violates loading constraints
You can solve this by removing the XML jar containing the QName class from your application (the API is included in the server's JDK), by adding the SOAP API to the application (so the application "sees" both classes from the same location), or by switching your class loading to parent-first. Parent-last class loading is generally vulnerable to issues like this, because it allows for more duplicate loading between class loaders than is typically possible under default settings. If you don't have a very explicit need for your own XML API version (XML APIs have been included in Java SE for a very long time), I'd strongly recommend either removing the jar or switching to parent-first.
