DO NOT REPLY [Bug 16519] New: - RPCElement doesn't always find correct overloaded method

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16519>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16519

RPCElement doesn't always find correct overloaded method

           Summary: RPCElement doesn't always find correct overloaded method
           Product: Axis
           Version: 1.1beta
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Blocker
          Priority: Other
         Component: Serialization/Deserialization
        AssignedTo: axis-dev@xml.apache.org
        ReportedBy: timdnp@yahoo.com


My web service contains overloaded methods.  For example, here are two methods:

1) MyObject test1(String s1, String s2, MyObject obj);

2) MyObject[] test1(String s1, String s2, MyObject[] obj);

When my client calls method (1), Axis executes method (2) on the server instead 
of (1).  While debugging, including the Axis source code, I found that the Axis 
class "RPCElement" selects the first matching operation that is a good fit 
rather than the one that is the exact fit.  This is because the method 
isConvertable() in "JavaUtils" says it is OK to map a single instance of a 
class to an array of the class.  And "RPCElement" happened to find method (2) 
before method (1).  So it thought it found a good match but it had chosen the 
wrong one.

If I shuffle methods (1) and (2) around in my web service's source code so that 
method (1) is found before (2) (when using introspection), everything works 
OK.  Or if I edit JavaUtils so that it doesn't approve "promotion" of a single 
instance of MyObject to an array of MyObject, RPCElement finds the correct 
method (this was just a quick test I ran to help isolate the problem).

In my real application, I have five versions of the overloaded method plus many 
other methods, so this example has been simplified.  I found that the Axis 
error occurred whenever the order of the methods in my web service source file 
caused the result of this call in my web service implementation class,

 Method[] methods = this.getClass().getMethods();

to contain method (2) earlier in the "methods" array than method (1).  That 
little test let me know when I had shuffled the order of my methods enough in 
order to know when the SOAP call would work.  The order of the methods found 
through introspection isn't necessarily the same as the order they appear in 
the source code.

Tim Dierks
EDS PLM Solutions
San Diego, California
------------------------
Following are comments from from Glen Daniels from his response to my original 
posting on the axis-dev mailing list:

Hi Tim!

Yup, I think this is a bug.

If the schema for the message indicates the "arrayness" of the "obj" 
parameter comes from a minOccurs/maxOccurs constraint rather than from 
SOAP encoding, then an array of one value might look like this:

   [example 1]
   <obj>insert myobject1 here</obj>

and a larger one like this:

   [example 2]
   <obj>insert myobject1 here</obj>
   <obj>insert myobject2 here</obj>

On the other hand, if it's SOAP encoded, it'll look like this:

   [example 3]
   <obj>
     <item>insert myobject1 here</item>
   </obj>

It's pretty easy to tell the difference between example 3 and example 
1, and we should be doing at least that correctly.  In other words, if 
we're expecting a SOAP array and get a plain old value, we should NOT 
match on the array version even though isConvertible() says we can.  This 
part is relatively easy.

However, it's not so easy to tell the difference between a plain old 
value and an array containing a single plain old value when using 
maxOccurs="unbounded".  So if you're expecting something like example 2 above 
and get example 1, the only way we can fix it to prefer the 
single-value version over the array version is to change the scan in RPCElement 
to 
continue even after a "probable match" to find a better one.  This is 
doable as well, though.

Could you file this as a bugzilla bug?  Thanks!

--Glen