axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R J Scheuerle Jr" <>
Subject Re: array test
Date Tue, 04 Dec 2001 16:04:32 GMT
After re-reading JAX-RPC WSDL -> Java for arrays.  It appears that the code
that I put it is not exactly correct.
Currently the emitter is generating ArrayOfFoo classes for the complexTypes
representing arrays.  Instead it should be generating Foo[ ] types.

I will defer adding these changes until after Doug adds his array runtime
changes (plus Russell is working on some symbol table changes).
...Post Alpha 3..

Rich Scheuerle
XML & Web Services Development
512-838-5115  (IBM TL 678-5115)

                    "Glen Daniels"                                                       
                    <gdaniels@macro       To:     <>     
          >            cc:                                         
                                          Subject:     Re: array test                    
                    08:20 AM                                                             
                    Please respond                                                       
                    to axis-dev                                                          


> 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
> 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
> 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
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
we had a WSDL that specified a "myNS:ArrayOfFoo" type and we got the first
your two messages above.

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


View raw message