If memory serves, I believe <string> ... </string> is the default type. So w/ no type provided, <string> ... </string> is assumed.
But it looks like it returns the exception...instead of throwing it. M ----- Original Message ----- From: "Donald Albertson" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, June 10, 2005 9:21 AM Subject: Re: rpcClient.execute returns a XMLRpcException Now that my curiosity has been piqued, I looked at the xmlrpc spec and the only thing I can see different between the fault example in the spec and the one you provided is that in the spec the fault string member looks like this: <member> <name>faultString</name> <value><string>Too many parameters.</string></value> </member> </struct> and the one you're getting back looks like this: <member> <name>faultString</name> <value>org.apache.xmlrpc.XmlRpcException: ERROR in BlooggerAPIHander.newMediaObject</value> </member> Would the lack of the <string> ...</string> qualifiers be enough to cause a problem? I wouldn't think so but ... dga >>> [EMAIL PROTECTED] 06/10/2005 11:09:31 AM >>> Ok. Thanks. I had just found the offending code myself (in XmlRpcClientResponseProcessor) protected XmlRpcException decodeException(Object result) throws XmlRpcClientException { Hashtable exceptionData; try { exceptionData = (Hashtable) result; return new XmlRpcException( Integer.parseInt(exceptionData.get ("faultCode").toString()), (String) exceptionData.get("faultString") ); } catch (Exception x) { throw new XmlRpcClientException("Error decoding XML-RPC exception response", x); } } I'll switch over to 1.2b1 myself too. Henry On 10 Jun 2005, at 17:05, Bedelet, Olivier ((GE Healthcare)) wrote: > Hi henry, > > I have seen the same thing. This is a bug. You can read the bug > report here http://issues.apache.org/jira/browse/XMLRPC-61 . The > report includes a patch. I didn't try it, so i can't tell you if it > solve the problem. I continue to use the version 1.2b1 until a the > new release > > > Regards > > I send a request with rpcClient.execute and this returns a > XMLRpcException. Should it not be > throwing one instead? As a result I get a class cast exception in my > code. I am using > version 2.0 final. Anyone else notice this? > > >
