[
https://issues.apache.org/jira/browse/AXIS2-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
simishag updated AXIS2-3106:
----------------------------
Description:
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.
was:
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.argon.searchsystems.net";>
<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.
edit to remove hostname
> 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
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
