Axis SOAP request failed.; nested exception is: java.lang.ClassCastException: [B
the issue: i came across a client that was using an ESB to send over requests to a web service that responded fine when the request was sent using soapui (and poster on firefox) but got the following error from the requests sent by it’s ESB:
<exception xmlns="http://www.sonicsw.com/sonicesb/exception"> <message>Axis SOAP request failed.; nested exception is: java.lang.ClassCastException: [B</message> <class>com.sonicsw.xqimpl.invkimpl.wsif.providers.axissoap.SoapProviderInvocationException</class> <detail/> <stackTrace><![CDATA[java.lang.ClassCastException: [B at com.sonicsw.xqimpl.invkimpl.wsif.providers.axissoap.ESBJmsSender.invoke(Unknown Source) at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165) at org.apache.axis.client.Call.invokeEngine(Call.java:2765)
note: the exception above looks a little strange only because it is a “general exception format” used by the ESB when it cannot determine the fault format from the web service’s WSDL.
what we did was setup tcpmon to capture the request and response messages in their entirety.
the following is what we found in the response header:
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5 Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:e8c8957a-e9ae-4e67-a34d-fdae2d9058a0"; start=""; start-info="text/xml" Content-Length: 1440 Date: Fri, 08 Apr 2011 12:57:57 GMT --uuid:e8c8957a-e9ae-4e67-a34d-fdae2d9058a0 Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"; Content-Transfer-Encoding: binary
both of the above settings were not supported by the ESB.
all we were returning was a standard xml soap response (no attachments or binary data). so the content-type and transfer-encoding were changed to be simpler (removing the multipart/related and undesignating as binary) and the ESB could now communicate with the web service.
i haven’t encountered this in any context BUT i’m hoping this will help you if you encounter something similar. especially since it may simply be that your response is returning the content with inappropriate header info (or at least ones unsupported/disliked by the requesting client).