You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by "Jochen Wiedmann (JIRA)" <xm...@ws.apache.org> on 2005/10/16 18:40:45 UTC
[jira] Kommentiert: (XMLRPC-71) Trying to serialise an unserialisable class breaks XML format spec
[ http://issues.apache.org/jira/browse/XMLRPC-71?page=comments#action_12332173 ]
Jochen Wiedmann commented on XMLRPC-71:
---------------------------------------
First of all, the error message is absolutely right: The long type is unsupported. Even more: Supporting it would violate the XML-RPC spec. (See http://www.xmlrpc.com/spec)
To me, it is very questionable, whether we should attempt to fix this issue. The XML-RPC callee is responsible for returning a valid result object. (Which you did not.) I think it is reasonable, to trust that he did and not verifying the result.
On the other hand, without verifying the result, we could either decide to write the response into a temporary buffer (a clear performance problem for applications with large result objects) or take the risk to create a malformed response. The latter is exactly how it is now. I am +1 for leaving it that way.
If you absolutely need support for longs, you might try to use the streaming branch (http://svn.apache.org/viewcvs.cgi/webservices/xmlrpc/branches/b20050512_streaming/).
FInally, as you see from my response, this project isn't dead at all. The bug reports you are referring to are filed for version 1 of XML-RPC, which is (afaik) no longer supported.
> Trying to serialise an unserialisable class breaks XML format spec
> ------------------------------------------------------------------
>
> Key: XMLRPC-71
> URL: http://issues.apache.org/jira/browse/XMLRPC-71
> Project: XML-RPC
> Type: Bug
> Components: Source
> Versions: 2.0
> Environment: Linux (FC2 server, Suse 9.1 client), Java 1.4 on server, 1.5 on client, Tomcat 4.1 on server
> Reporter: Chris Wilson
>
> I tried to make a method return a vector containing a Hashtable containing a Long, and invoke that method via XML-RPC (Apache XML-RPC on both client and server). Here is the result (pasted from Ethereal, reformatted for readability):
> <?xml version="1.0" encoding="UTF-8"?>
> <methodResponse>
> <params>
> <param><value><array><data>
> <value><struct>
> <member>
> <name>version</name>
> <value><int>2</int></value>
> </member>
> <member>
> <name>name</name>
> <value>UsingTomcatAtAidWorld</value>
> </member>
> <member>
> <name>size</name>
> <value>
> <?xml version="1.0" encoding="UTF-8"?>
> <methodResponse>
> <fault><value><struct>
> <member>
> <name>faultString</name>
> <value>java.lang.RuntimeException: unsupported Java type: class java.lang.Long</value>
> </member>
> <member>
> <name>faultCode</name>
> <value><int>0</int></value>
> </member>
> </struct></value></fault>
> </methodResponse>
> This is malformed XML, and the client understandably takes a dim view of it:
> Fatal error parsing XML: org.xml.sax.SAXParseException: unexpected end of file found
> org.apache.xmlrpc.XmlRpcClientException: Error decoding XML-RPC response
> at org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeResponse(XmlRpcClientResponseProcessor.java:78)
> at org.apache.xmlrpc.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:72)
> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:193)
> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:173)
> at org.mahlen.hula.rpcclient.RPCClient.getRecentChanges(RPCClient.java:236)
> Caused by: org.apache.xmlrpc.XmlRpcClientException: Error decoding XML-RPC exception response
> at org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeException(XmlRpcClientResponseProcessor.java:109)
> at org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeResponse(XmlRpcClientResponseProcessor.java:69)
> ... 9 more
> Caused by: java.lang.NullPointerException
> at org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeException(XmlRpcClientResponseProcessor.java:102)
> ... 10 more
> By the way, is this project dead? There are outstanding issues over 3 years old.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira