BPEL fault: no deserializer found…
I got the following error while running a bpel process:
BPEL Fault: {http://nl/iteye/service/Service.wsdl}
org.apache.wsif.soap.fault{org.apache.wsif.soap.fault.object=No Deserializer found to deserialize a 'http://nl/iteye/service/Service.wsdl:msg' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'. [java.lang.IllegalArgumentException]}
You may run into this problem when calling a web service running in a default oc4j version 10.0.3 or 9.0.4 from the bpel process manager.
Edwin Khodabakchian offered some quick help: Adding xsi type to SOAP messages.
21 Sep 2004 |
January 28th, 2005 at 1:01 pm
I noticed that the link to Edwin’s OTN forum post quite often doesn’t work, so here’s a copy of Edwin’s post:
Here is a quick 2.0.10 note.
Some older Soap stack require xsi type information embedded in the SOAP message to unmarshall the XML message into the appropriate object representation.
Most customers do no want the overhead of xsi type definition into the SOAP message given that most modern SOAP stack perform the unmarshalling based on the WSDL/XML Schema.
To address both requirements, we now by default do not add the xsi:type information to the SOAP traffic that the BPEL PM server generates.
But we have added a new configuration property to the partnerLinkBinding element of the bpel.xml deployment descriptor so that you can ask the BPEL PM server to selectively decorate the SOAP messages targeted at a specific partnerLink. Here is how this looks like:
<partnerlinkbinding name=”XXXXX”>
....
<property name=”sendXSIType”>true</property>
</partnerlinkbinding>
Note: the challenge here is that if you invoke a service that requires XSI type information and you forget to set that flag in the deployment descriptor you will get a BindingFault with no detail
We are very aware of this limitation and are working very diligently towards addressing this problem with a much nicer error message in the 2.1 (aka end of September release).