Open ahgittin opened 3 years ago
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.
On some errors from SOAP (in our case the timeout was set too low), winrm4j can hit another error when trying to process it:
The issue in our case, using OSGi, seems to be that the
cxf.jaxws
code is usingSOAPFault
fromorg.apache.servicemix.specs.saaj-api-1.3-2.9.0
(as expected because it specifically requests packagejavax.xml.soap;version="[1.3,2)"
in itsMETA-INF/MANIFEST.MF
). But theSOAPFaultException
it is accessing is the one coming from the JDK (1.8.0_242
above) which presumably is expecting the JDK’sSOAPFault
.cxf.jaxws
seems to be overly lax in its requirements on imported packagejavax.xml.ws.soap;version="[0,3)"
, permitting that incompatibleSOAPFaultException
.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.