going back to the beta solves the problem.
It looks like the patch mentioned
http://issues.apache.org/jira/browse/XMLRPC-61
locates the problem in the right place:
try
{
byte[] request = requestProcessor.encodeRequestBytes
(xmlRpcRequest, responseProcessor.getEncoding());
InputStream is = transport.sendXmlRpc(request);
response = responseProcessor.decodeResponse(is);
return response;
}
catch (IOException ioe)
{
throw ioe;
}
catch (XmlRpcClientException xrce)
{
throw xrce;
}
catch (RuntimeException x)
{
if (XmlRpc.debug)
{
x.printStackTrace();
}
throw new XmlRpcClientException
("Unexpected exception in client processing", x);
}
finally
{
if (XmlRpc.debug)
{
System.out.println("Spent " +
(System.currentTimeMillis() - now)
+ " millis in request/process/
response");
}
// End the transport's session, handling any problem while
// avoiding hiding of any earlier exception.
try
{
transport.endClientRequest();
}
catch (Throwable t)
{
// Don't clobber an earlier exception.
boolean haveFault = response instanceof
XmlRpcException;
if (haveFault || response == PROCESSING_ERROR_FLAG)
{
System.err.println("Avoiding obscuring previous
error " +
"by supressing error
encountered " +
"while ending request: " + t);
if (haveFault)
{
throw (XmlRpcException) response;
}
// else we've already thrown an exception
}
else
{
if (t instanceof XmlRpcException)
{
throw (XmlRpcException) t;
}
else
{
throw new XmlRpcClientException
("Unable to end request", t);
}
}
}
}
}
Henry
On 10 Jun 2005, at 17:39, Michael Landon - IBN wrote:
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?
