You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "simishag (JIRA)" <ji...@apache.org> on 2007/08/09 02:42:59 UTC
[jira] Created: (AXIS2-3106) REST: inconsistent error handling
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.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.
--
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3106) REST: inconsistent error handling
Posted by "Kevin L Stewart (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (AXIS2-3106) REST: inconsistent error handling
Posted by "simishag (JIRA)" <ji...@apache.org>.
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3106) REST: inconsistent error handling
Posted by "simishag (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518608 ]
simishag commented on AXIS2-3106:
---------------------------------
Yes, all my services are POJO.
Also, I'd like to clarify what I wrote above. The parameter reordering is not taking place on the GET query string. Instead, I reordered the parameters in the method definition (as capturePriorAuth[1-3]) and tested separate query strings for each variation of the method. Each query string was constructed with the parameters ordered as they were in the method definition.
> 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: Keith Godwin Chapman
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3106) REST: inconsistent error handling
Posted by "Keith Godwin Chapman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518607 ]
Keith Godwin Chapman commented on AXIS2-3106:
---------------------------------------------
Did you create your service using POJO approach?
> 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: Keith Godwin Chapman
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3106) REST: inconsistent error handling
Posted by "simishag (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518803 ]
simishag commented on AXIS2-3106:
---------------------------------
Well, I guess that explains it, but I have to ask: why does the auto-generated WSDL for POJOs set every field to "minOccurs=0" and "nillable=true"? That seems non-obvious at best, and if I'm not mistaken, it means that every POJO method needs to explicitly check every single parameter for "null" before using it.
I really don't want to have to write my own WSDL for this, since all the POJO stuff is already done and the auto-generated WSDL works fine otherwise. Is there some way to instruct the POJO-to-WSDL module to make all these fields required? I don't need to set this on individual methods; I would be happy with a single on-off switch for the whole service.
Side note: Some of my methods pass JavaBeans around. Looking at the WSDL for one of the Beans (shown as a "xs:complexType") I see that most fields have "minOccurs=0" and "nillable=true", but integer (and short) fields only have "minOccurs=0". This is different from the complexType passed in to the capturePriorAuth methods, where all the fields (integer too) have "nillable=true".
> 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: Keith Godwin Chapman
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-3106) REST: inconsistent error handling
Posted by "Keith Godwin Chapman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Godwin Chapman reassigned AXIS2-3106:
-------------------------------------------
Assignee: Deepal Jayasinghe (was: Keith Godwin Chapman)
Deepal can you have a look at this please. The schema needs to be consistent also we need to fix the problem in the RPC MessageReceiver.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-3106) REST: inconsistent error handling
Posted by "Keith Godwin Chapman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Godwin Chapman reassigned AXIS2-3106:
-------------------------------------------
Assignee: Keith Godwin Chapman
> 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: Keith Godwin Chapman
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3106) REST: inconsistent error handling
Posted by "Keith Godwin Chapman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518646 ]
Keith Godwin Chapman commented on AXIS2-3106:
---------------------------------------------
I debugged your case using a POJO.
If you take a look at the WSDL you will see that minoccurs=0 in the parameters for your method as below.
<xs:element name="capturePriorAuth">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="creditCardId" type="xs:int"/>
<xs:element minOccurs="0" name="transactionId" nillable="true" type="xs:string"/>
<xs:element minOccurs="0" name="amount" nillable="true" type="xs:decimal"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Therefore the soap Message
<?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>
is indeed correct. When the Axis Engine cannot find a parameter expected by the operation it checks the minoccurs and nillable attributes of the parameter and act accordingly. If the schema didnt have the attribute minoccurs=0 then Axis2 would have thrown an error saying that a required element was not found.
Yes the Parameters and mapped incorrectly when they come into the operation. I guess the RPCMessageReceiver is in fault here. Will raise an issue on that against the RPCMessageReceiver. Thats the reason i didnt get the fault when using codegerated stuff as it uses a custom message receiver.
> 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: Keith Godwin Chapman
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3106) REST: inconsistent error handling
Posted by "Keith Godwin Chapman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518615 ]
Keith Godwin Chapman commented on AXIS2-3106:
---------------------------------------------
I just tested this scenario using a contract first approach (Building the service and client using WSDL 2.0, This method better utilizes the REST support in Axis2) and it worked like a charm. I'll try the POJO approach too. If you need any help on REST support using WSDL 2.0 i'll be glad to help.
> 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: Keith Godwin Chapman
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org