[jira] Commented: (AXIS2-2706) ADB client doesn't receive 0-length array of beans

["John G. Norman (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AXIS2-2706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498670 ] 

John G. Norman commented on AXIS2-2706:
---------------------------------------

Wow, this is even worse than I thought.

So I figured, OK, if I can't return a 0-length array, I'll return null and fix it up on the client.

But guess what?

Returning null results in an array on the client with 1 element.

I am attaching a new hack of samples/pojo

Now, additionally, the service has:

  public Entry[] getEntries3() {
    return null;
  }


And the client has:

            GetEntries3Response e3Response = stub.getEntries3();
            Entry[] entries3 = e3Response.get_return();
            System.out.println("(should return null)... Number of items returned by getEntries3(): " + entries3.length);

I do not have time to check this with 1.1.1, but if it was working on 1.1.1, then someone forgot to write tests. If it was broken on 1.1.1, then I have to wonder if anyone is bothering to use the POJO apparatus with the ADB client.

Now I've run out of workarounds. I think the array of element 1 has null for the first element, so I guess I can test client-side against that. YUCK.


> ADB client doesn't receive 0-length array of beans
> --------------------------------------------------
>
>                 Key: AXIS2-2706
>                 URL: https://issues.apache.org/jira/browse/AXIS2-2706
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: adb
>    Affects Versions: 1.2
>         Environment: XP, Java 1.4.2_13, Tomcat 5.0.28
>            Reporter: John G. Norman
>         Attachments: pojo.jar
>
>
> A service returns an array of JavaBeans that is of length 0.
> The client gets an exception "Unexpected subelement"
> This may be related to bugs 2464 and 1702
> To provide some clarity, I will attach a version of sample/addressbook. I've made the following changes:
> (1) In the service, I've added methods to return arrays of Entry:
>   public Entry[] getEntries1() {
>     return new Entry[] { createEntry(), createEntry() };
>   }
>   public Entry[] getEntries2() {
>     return new Entry[0];
>   }
> (2) Then I exercise both methods in the client as follows (the call to getEntries2 fails):
>             GetEntries1Response e1Response = stub.getEntries1();
>             Entry[] entries1 = e1Response.get_return();
>             System.out.println("Number of items returned by getEntries1(): " + entries1.length);
>             GetEntries2Response e2Response = stub.getEntries2();
>             Entry[] entries2 = e2Response.get_return();
>             System.out.println("Number of items returned by getEntries2(): " + entries2.length);
> I did it this way so that the fact that an array of length > 0 is obvious.
> If I had time, I'd check with simple types, but in my case, a bean is the most important object type I need to return in an array.
> Idea:
> There seems to be a whole cluster of small issues around the POJO service + ADB client. E.g., methods that return void, exception handling, etc. A somewhat more robust version of sample/addressbook might bring these out. I'd be glad to beef up the example . . .
> I think the POJO service + ADB client is key for the Axis2 "product" because if the simplest entry point is awkward, people will just bag it and use other impls of the various  APIs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org