You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-auto@ws.apache.org by "Trejkaz (JIRA)" <xm...@ws.apache.org> on 2007/07/13 04:29:04 UTC
[jira] Created: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Rethrow the same exception thrown on the server side
----------------------------------------------------
Key: XMLRPC-143
URL: https://issues.apache.org/jira/browse/XMLRPC-143
Project: XML-RPC
Issue Type: New Feature
Components: Source
Reporter: Trejkaz
If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
Notably, this causes two problems for the caller.
1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Jochen Wiedmann (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512870 ]
Jochen Wiedmann commented on XMLRPC-143:
----------------------------------------
Yes, but you want the feature, so isn't it up to you to provide a patch? :-)))
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Chris Schmidt (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513746 ]
Chris Schmidt commented on XMLRPC-143:
--------------------------------------
Perhaps I am not fully understanding the request then? I didn't submit the request by the way, was just looking through Jira and saw it. Is the request to handle this on the client side then, since Exceptions are already being serialized on the server end?
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Trejkaz (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513786 ]
Trejkaz commented on XMLRPC-143:
--------------------------------
OK. So I'll just wait until this makes it into a release then.
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Trejkaz (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514021 ]
Trejkaz commented on XMLRPC-143:
--------------------------------
Interesting utility class. I have one exactly like it from back when this project didn't (it looks almost exactly like mine, but I bet the type convertor is better.). I should move over to it so that I can delete my own one.
Though it doesn't help for 3.0 because a 3.0 server won't pass the exception along anyway. XmlRpcStreamRequestConfig in that version only had the gzipCompressing property.
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Jochen Wiedmann (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513818 ]
Jochen Wiedmann commented on XMLRPC-143:
----------------------------------------
For the sake of clarification: The exception *is* rethrown, if you are using the ClientFactory:
https://svn.apache.org/viewvc/webservices/xmlrpc/trunk/client/src/main/java/org/apache/xmlrpc/client/util/ClientFactory.java?revision=478678&view=markup
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Chris Schmidt (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512868 ]
Chris Schmidt commented on XMLRPC-143:
--------------------------------------
Isn't that essentially what this block of code is doing (unless this has already been patched, in which case I am sorry) -- from XmlRpcWriter.write()
if (pThrowable != null && extensions && (pConfig instanceof XmlRpcStreamRequestConfig) &&
((XmlRpcStreamRequestConfig) pConfig).isEnabledForExceptions()) {
try {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(pThrowable);
oos.close();
baos.close();
map.put("faultCause", baos.toByteArray());
} catch (Throwable t) {
// Ignore me
}
}
You should be able to deserialize the XmlRpcException from the response and get the linked exception to get at the root of the problem in the situation where the rpc request fails.
or am I just misunderstanding the request?
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Chris Schmidt (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513785 ]
Chris Schmidt commented on XMLRPC-143:
--------------------------------------
>From http://ws.apache.org/xmlrpc/extensions.html
"If the server property "enabledForExceptions" is turned on, then the server will convert exceptions into a byte array and send them to the client within a "faultCause" message."
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Trejkaz (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513781 ]
Trejkaz commented on XMLRPC-143:
--------------------------------
Actually the request was put in because I had no idea that was in the API. But even looking at the API now, it isn't there, so I'm guessing someone implemented this in trunk and it just hasn't made it into a stable release yet.
If that's the case and it already works all the way back to the client, then I will just wait until the next stable release.
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Jochen Wiedmann (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512367 ]
Jochen Wiedmann commented on XMLRPC-143:
----------------------------------------
Patches welcome.
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (XMLRPC-143) Rethrow the same exception thrown on
the server side
Posted by "Jochen Wiedmann (JIRA)" <xm...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Wiedmann resolved XMLRPC-143.
------------------------------------
Resolution: Fixed
You're welcome to use one of the 3.1 snapshots.
> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
> Key: XMLRPC-143
> URL: https://issues.apache.org/jira/browse/XMLRPC-143
> Project: XML-RPC
> Issue Type: New Feature
> Components: Source
> Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to distinguish an error contacting the server, with an error thrown by the application code. In the former case, I would like to retry a couple more times. In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated. Ideally, the stack trace would be serialised along with the rest of the exception and reconstructed on the client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles Serializable objects elsewhere, this should not be a major headache. I don't mind if it requires extensions to be enabled as I'm already forced to enable those to get support for returning null. :-)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.