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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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
