java.lang.LinkageError: javax/xml/soap/SOAPFault when processing an earlier error

[ahgittin]

On some errors from SOAP (in our case the timeout was set too low), winrm4j can hit another error when trying to process it:

...
Caused by: java.lang.LinkageError: javax/xml/soap/SOAPFault
        at javax.xml.ws.soap.SOAPFaultException.<init>(SOAPFaultException.java:63) ~[?:1.8.0_242]
        at org.apache.cxf.jaxws.JaxWsClientProxy.mapException(JaxWsClientProxy.java:195) ~[!/:3.3.5]

The issue in our case, using OSGi, seems to be that the cxf.jaxws code is using SOAPFault from org.apache.servicemix.specs.saaj-api-1.3-2.9.0 (as expected because it specifically requests package javax.xml.soap;version="[1.3,2)" in its META-INF/MANIFEST.MF). But the SOAPFaultException it is accessing is the one coming from the JDK (1.8.0_242 above) which presumably is expecting the JDK’s SOAPFault. cxf.jaxws seems to be overly lax in its requirements on imported package javax.xml.ws.soap;version="[0,3)", permitting that incompatible SOAPFaultException.

Note with more recent JDKs the javax...soap classes are no longer bundled. But we have other issues running with those versions so simply upgrading the JDK while might help here isn’t so easy.

[ahgittin]

It might be a workaround to edit the etc/jre.properties in our karaf OSGi setup, removing the lines exporting the JDK's SOAP classes, hopefully forcing it to take SOAPFaultException from org.apache.servicemix.specs.jaxws-api-2.2-2.9.0.jar which will hopefully work. That would allow us to see the original error which otherwise is only possible in a debugger.

FWIW I note that the etc/jre.properties states that the JDK exports 1.3 of javax.xml.soap and 2.2 of javax.xml.ws.soap, i.e. the same versions we want. So it might be an option of instead of excluding the JDK's classes, we exclude those packages from the servicemix bundles.