[
https://issues.apache.org/jira/browse/AXIS2-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752732#action_12752732
]
Kevin L Stewart commented on AXIS2-3106:
----------------------------------------
I still get the above issue with Axis2 VERSION 1.5. Is there any work around?
> REST: inconsistent error handling
> ---------------------------------
>
> Key: AXIS2-3106
> URL: https://issues.apache.org/jira/browse/AXIS2-3106
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Affects Versions: 1.3
> Environment: Axis2-1.3-RC2
> Tomcat 5.5
> Linux
> Reporter: simishag
> Assignee: Deepal Jayasinghe
>
> When using REST and making a simple HTTP GET request to Axis, the error
> handling is inconsistent. It appears that fields in the query string are
> simply processed in order, without regard to the actual name of the field.
> Example:
> I have a method "capturePriorAuth" which takes 3 parameters: creditCardId
> (int), amount (BigDecimal), transactionId (String). My test calls the method
> as:
> .../capturePriorAuth?creditCardId=24&transactionId=1518355879&amount=1.00
> I was doing some testing earlier and I was accidentally using "requestId" as
> the name of the first field instead of "creditCardId." Fixing that
> particular error resolved my immediate issue, but I had noticed some
> weirdness in the errors from when I was using the wrong field name.
> Normally, Axis would throw an AxisFault (usually from
> IllegalArgumentException) indicating that a required parameter was missing.
> However, this behavior is inconsistent, and appears to depend on the order of
> the fields as defined in the method. I wrote some test methods such as
> "capturePriorAuth[1-3]" to test the behaviors.
> For example:
> capturePriorAuth1?requestId=24&transactionId=1518355879&amount=1.00
> is actually accepted by Axis. However, logging from within my service method
> shows that Axis is skipping the first field (requestId) entirely, and
> assigning the value of "transactionId" to the method's expected
> "creditCardId." It then assigns "1.00" to "transactionId" (which works
> because 1.00 is a valid String) and sets "amount" to null.
> I ran this test through the SOAP Monitor as well, to see how Axis rewrote the
> request:
> <?xml version='1.0' encoding='utf-8'?>
> <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope";>
> <soapenv:Body>
> <axis2ns15:capturePriorAuth1 xmlns:axis2ns15="http://manager";>
> <transactionId>1518355879</transactionId>
> <amount>1.00</amount>
> </axis2ns15:capturePriorAuth1>
> </soapenv:Body>
> </soapenv:Envelope>
> The values are correct for this SOAP request, in that the 2 values are
> correct and the 3rd is missing. However, Axis still accepts this request,
> even though the 3rd required field is obviously missing. Logger output again
> shows the inconsistency described above.
> However, this example will throw an AxisFault: (notice the fields are
> reordered)
> capturePriorAuth2?requestId=24&amount=1.00&transactionId=1518355879
> Partial stack trace:
> org.apache.axis2.AxisFault: For input string: "1.00" at
> org.apache.axis2.AxisFault.makeFault(AxisFault.java:417)
> ...
> Caused by: java.lang.NumberFormatException: For input string: "1.00"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:456)
> at java.lang.Integer.<init>(Integer.java:620)
> at
> org.apache.axis2.databinding.typemapping.SimpleTypeMapper.getSimpleTypeObject(SimpleTypeMapper.java:83)
> That error presumably occurs because Axis skips the first parameter (which is
> unknown) and attempts to set "creditCardId" to "1.00", an invalid value for
> int.
> Here's another example: (fields reordered again)
> capturePriorAuth3?amount=1.00&transactionId=1518355879&requestId=24
> It also throws AxisFault, but not for the same reason:
> org.apache.axis2.AxisFault at
> org.apache.axis2.AxisFault.makeFault(AxisFault.java:417)
> ...
> Caused by: java.lang.IllegalArgumentException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:194)
> at
> org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:98)
> ... 23 more
> This is probably the correct error handling mode, since creditCardId is
> unavailable.
> From this testing, it appears that Axis is not handling parameter names as
> provided in the HTTP GET query string, and instead simply sets the method
> parameters in the order they are parsed. Because Axis also skips a parameter
> if its name is unknown, but it continues assigning values, creating an
> off-by-1 error as additional values are parsed.
> This leads to inconsistent error handling for methods which have identical
> implementations but different method signatures. It also allows certain
> incorrect parameter combinations to be accepted by Axis and passed to the
> service method, which may not be prepared to handle them correctly. Service
> code should be able to assume safely that Axis has done the hard work of
> parsing parameters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
