[ http://issues.apache.org/jira/browse/AXIS-2211?page=all ]

Predrag Knezevic updated AXIS-2211:
-----------------------------------

    Attachment: axis-array-patch.diff

Here is the patch that solves the problem. I have seen that this behavior has 
been designed on purpose, but I do not understand why. Maybe somebody with 
deeper Axis knowledge could explain the reasons.

Anyway, the problem appears when a class has two methods with the same name, 
the same number of parameters, and the same types, except that in one case a 
parameter is array of a type, and in other is just this type. For example:

public void foo(String a, String b);

public void foo(String a,String[] b);

in the current code, Axis compares parameter types from the requested method, 
and the type that came with a SOAP request. If array component type matches the 
request parameter type, then the request parameter will be converted into 
array, and at the end the method that has array as parameter will be invoked.

In order to solve the problem and enable polymorphisms, I have disabled such 
behavior.



> Wrong method signature called depending on the name of the operation with JWS
> -----------------------------------------------------------------------------
>
>          Key: AXIS-2211
>          URL: http://issues.apache.org/jira/browse/AXIS-2211
>      Project: Apache Axis
>         Type: Bug
>     Versions: 1.2.1
>  Environment: Windows Xp, Java 1.5.0_04, Tomcat 5.5.9, Axis 1.2.1
>     Reporter: Andrea Matsunaga
>  Attachments: axis-array-patch.diff
>
> I have a JWS service with two methods with the same name but different 
> signatures (one has String and the other an array of string). This service 
> was working properly on Axis 1.1 (on Linux). Now, I'm trying to port it to 
> Axis 1.2.1 (on Windows) and though the client is trying to access the 
> operation with a String, the operation with an array of string signature is 
> being called by Axis. Using the SOAPMonitor, it is possible to see that the 
> client is sending a proper SOAP message indicating a string (and not an array 
> of string), but the message returned is with an array of string. Adding some 
> logs to my service, it was verified that the wrong operation was invoked. The 
> odd aspect of this is that just by changing the name of the operation the 
> expected behavior can be "recovered". The only difference that I could notice 
> is that the generated WSDL shows the response/request messages in a different 
> order, but this should not be influencing wich operation is invoked. When the 
> operation is named "translate", the service misbehaves, while when the exact 
> same service has its operations renamed to "echoString", everything works 
> fine.
> Here is the service that misbehaves (i.e., when the client tries to access 
> the first method with String, Axis actually invokes the second with an array 
> of strings):
> public class Echo {
>     public String translate(String lang, String text) {
>         return "Echo> " + text;
>     }
>     public String[] translate(String lang, String[] words) {
>         if (null != words) {
>             for (int i = 0; i < words.length; i++) {
>                 words[i] = "Echo[" + i + "]> " + words[i];
>             }
>         }
>         return words;
>     }
> }
> Here is the service that works as expected (i.e., when the client tries to 
> access the first method with String, Axis invokes the first with a string; 
> note that only the operation name changed):
> public class Echo {
>     public String echoString(String lang, String text) {
>         return "Echo> " + text;
>     }
>     public String[] echoString(String lang, String[] words) {
>         if (null != words) {
>             for (int i = 0; i < words.length; i++) {
>                 words[i] = "Echo[" + i + "]> " + words[i];
>             }
>         }
>         return words;
>     }
> }

-- 
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

Reply via email to