axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject Re: array test
Date Tue, 04 Dec 2001 14:20:37 GMT

> What "real" problem?  As I posted previously, the following works just
> fine:
>    <doitResponse>
>      <doitResult href="#id0"/>
>    </doitResponse>
>    <multiRef id="id0" SOAP-ENC:root="0" xsi:type="SOAP-ENC:Array"
>        SOAP-ENC:arrayType="ns1:foo[3]"
>        xmlns:SOAP-ENC=""
>        xmlns:ns1="">
> On the argument, is there an xsi:type?  Nope.  If you follow the href, is
> there an xsi:type of "SOAP:Array"?  Yep.  Does this require a change to the
> current logic to work?  Doesn't appear to.
> Now lets take a look at something that does NOT work currently, involving
> myNS:ArrayOfInt types of things.  This is from the Phalanx "typed"
> endpoint.
>    <return xsi:type="s1:ArrayOfstring" SOAP-ENC:arrayType="xsd:string[2]">
> Note: no hrefs are required to confuse us.  Just a xsi:type that we don't
> recognize.  In this case, we don't recognize "ArrayOfstring".  If we were
> to have ArrayOfstring defined as a "known" type, or were to treat it as a
> synonym for SOAP-ENC:Array, or simply see the SOAP-ENC:arrayType and
> proceed merrily along our way, all would be well.
> What am I missing here?

You're missing the fact that you can imagine a situation where the working
message above doesn't work because the type info for "doItResult" in the Call
object is something like "s1:ArrayOfString".  In that case we won't even get to
the point where we process the xsi:type on the actual multiRef element.

Doug's example didn't illustrate this particular case, but it would happen if
we had a WSDL that specified a "myNS:ArrayOfFoo" type and we got the first of
your two messages above.

There are definitely two issues, and we should deal with both of them, IMO.


View raw message