missing xsi:type in responses

[Jeff Greif]

This refers to WSIF 1.2 (I cannot upgrade to 2.0 for another week or two).   In an Axis client, in order to deal with missing xsi:type information on the return value of the response, you set the return type and class on the org.apache.axis.client.Call object.   In a WSIF client like the DynamicInvoker (mine handles complex types as well), there does not seem to be an obvious way to handle the lack of xsi:type information except by provider-specific techniques such as the one above for axis (but I have not been able to make this specific thing work).  If the xsi:type is missing, both the ApacheSOAP and ApacheAxis providers get an exception trying to deserialize the response, even if a type mapping has been registered appropriately for the part -- presumably there is no way to look up that mapping without the type.    Yet, the element contained in the returned part may have a namespace attached, and if so, in a correctly sent response, the schema corresponding to that namespace will have already been made available to the client through the wsdl and its imports, and presumably the xml type can often be determined for that element.  (All bets are off when the server returns something incorrect, or a fault message that has not been specified in the wsdl.)    If there is some way for a provider to handle the missing xsi:type contingency, perhaps the WSIF API could provide a method for specifying the expected return type and class, and providers could do implement it appropriately.   Jeff