You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Ephemeris Lappis (JIRA)" <ax...@ws.apache.org> on 2005/06/15 15:22:53 UTC
[jira] Created: (AXIS-2056) AXIS 1.2 (final) / Style Wrapped / array operation arguments
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
[jira] Commented: (AXIS-2056) AXIS 1.2 (final) / Style Wrapped / array operation arguments
Posted by "Ephemeris Lappis (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-2056?page=comments#action_12313791 ]
Ephemeris Lappis commented on AXIS-2056:
----------------------------------------
If Dave is right, thus my diagnosis was wrong, and the problem is not on the server deserializer part, but on the client call serializer...
> 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
[jira] Commented: (AXIS-2056) AXIS 1.2 (final) / Style Wrapped / array operation arguments
Posted by "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