[jira] Commented: (AXIS-2056) AXIS 1.2 (final) / Style Wrapped / array operation arguments

["Dave Marquard (JIRA)" <ax...@ws.apache.org>]

    [ http://issues.apache.org/jira/browse/AXIS-2056?page=comments#action_12313767 ] 

Dave Marquard commented on AXIS-2056:
-------------------------------------

Just to throw my two cents in on this, I would actually expect a zero-length array to be represented as:

      <soapenv:Body>
         <testIntegerArrayToIntegerArray xmlns="urn:axis-test3">
            <in0 />
         </testIntegerArrayToIntegerArray>
      </soapenv:Body> 

whereas a null array would be represented as in0 with xsi:null="true" (your first case), or the absence of in0 all together (your second case).

> AXIS 1.2 (final) / Style Wrapped / array operation arguments
> ------------------------------------------------------------
>
>          Key: AXIS-2056
>          URL: http://issues.apache.org/jira/browse/AXIS-2056
>      Project: Apache Axis
>         Type: Bug
>     Versions: 1.2
>  Environment: J2SE 1.4
>     Reporter: Ephemeris Lappis

>
> Array arguments deserialization for wrapped/literal  style services does't make difference between null parameters and empty (zero length) arrays.
> For instance, for an operation with the java signature :
>         public void testArrayOfInteger(int[] values)
> the implementation server class is called with a null parameter for both invocations :
>         testArrayOfInteger(null)
>         testArrayOfInteger(new int[0])
> The request message for the first case looks like :
>       <soapenv:Body>
>          <testIntegerArrayToIntegerArray xmlns="urn:axis-test3">
>             <in0 xsi:nil="true"/>
>          </testIntegerArrayToIntegerArray>
>       </soapenv:Body>
> In the second case, like this :
>       <soapenv:Body>
>          <testIntegerArrayToIntegerArray xmlns="urn:axis-test3"/>
>       </soapenv:Body>
> which all seem quite right for me, and let see the null and empty arrays difference, and seems to incriminate the server side deserializer... 
> Beyond a defensive implementation that can avoid exception, this could break a specification that include a specific distinct processing for zero length arrays and null arrays.
> The case only occurs for wrapped style services. Both rpc and document styles produce the expected behaviour.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira