Hi Jeff,
I'm not really clear about what you are asking for, or what you mean by the
xsi:type information being missing? Why isn't the WSDL output message
definition enough? Could you try explaining again what you mean?
...ant
Anthony Elder
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
"Jeff Greif" <[EMAIL PROTECTED]> on 22/02/2003 20:11:32
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: missing xsi:type in responses
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
