Background:
According to the article, "SOAP Interoperability with Microsoft and Apache Toolkits - A step by step guide" [], the following lines of code must be added to the Apache SOAP client:
1. SOAPMappingRegistry smr = new SOAPMappingRegistry ();
2. StringDeserializer sd = new StringDeserializer ();
3. smr.mapTypes (Constants.NS_URI_SOAP_ENC, new QName ("", "Result"
, null, null, sd);
Explanation:
[ "The Apache SOAP always puts the xsi:type elements for all the parameters in the request (NumberOne and NumberTwo). However, Microsoft SOAP Toolkit does not put the xsi:type of element in the Response (Result).
If we do not handle this difference, the Apache SOAP implementation would reject the response that the Microsoft SOAP Toolkit generated, because of the absence of the xsi:type attribute of the Result element." ]
Question:
Is there a similar way of handling the absence of the xsi:type attribute with the JAXM specification?
Any help would be appreciated.
Regards.
According to the article, "SOAP Interoperability with Microsoft and Apache Toolkits - A step by step guide" [], the following lines of code must be added to the Apache SOAP client:
1. SOAPMappingRegistry smr = new SOAPMappingRegistry ();
2. StringDeserializer sd = new StringDeserializer ();
3. smr.mapTypes (Constants.NS_URI_SOAP_ENC, new QName ("", "Result"
, null, null, sd);Explanation:
[ "The Apache SOAP always puts the xsi:type elements for all the parameters in the request (NumberOne and NumberTwo). However, Microsoft SOAP Toolkit does not put the xsi:type of element in the Response (Result).
If we do not handle this difference, the Apache SOAP implementation would reject the response that the Microsoft SOAP Toolkit generated, because of the absence of the xsi:type attribute of the Result element." ]
Question:
Is there a similar way of handling the absence of the xsi:type attribute with the JAXM specification?
Any help would be appreciated.
Regards.