On Jul 24 2009, 10:22 pm, BobV <b...@google.com> wrote:
> The deRPC code went into trunk a week or so ago, and no initial fires
> have been reported. I'd like to get folks on GWTC to give it a
> shakedown.
<snip>
> I'm mainly looking for the following kinds of feedback:
> - If it doesn't work, please tell me how it breaks:
> - Run your JVM with -Dgwt.rpc.dumpPayload=true to have RpcServlet
> emit the incoming and outgoing payloads to System.out.
I realize it is roughly 8 months later, but I just got around to
checking out deRPC today with GWT 2.0.1.
It seems to work great until a remote service throws an Exception.
What I get back on the client-side is an instance of
com.google.gwt.user.client.rpc.StatusCodeException.
Our remote services set the HTTP response code to 500 when they catch
an Exception. We do this so "access.log" will indicate when a request
fails.
The legacy RPC mechanism didn't honor the response code in the face of
an Exception (very annoying). deRPC does (I see the 500's in
"access.log"), but RpcCallbackAdapter.java:83 does this:
if (statusCode != Response.SC_OK) {
caught = new StatusCodeException(statusCode, encodedResponse);
}
The actual exception is tucked away inside encodedResponse, never to
be decoded.
Could this somehow be rearranged such that the response is decoded,
checked for instanceof Throwable and then assigned to "caught",
otherwise construct a new StatusCodeException() that takes the decoded
response object as an argument rather than the encodedResponse string
(along with API additions for StatusCodeException.getResponseObject()
or whatever).
Or set the decoded object (if instanceof Throwable) as the cause of
the new StatusCodeException.
ISTM that the string form of encodedResponse is pretty darn useless to
anyone outside of RpcCallbackAdapter.
Otherwise, deRPC seems to work great (limited testing thus far), and
is significantly faster in at least Safari for OS X.
Thanks for your consideration.
eric
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
