Quickstart (for vanilla configurations):
- Inherit com.google.gwt.rpc.Rpc in your gwt.xml file
- Change your remote service interfaces to extend
com.google.gwt.rpc.client.RpcService
- Change your servlet to extend com.google.gwt.rpc.server.RpcServlet
Right now, the new code base should be functionally equivalent to the
legacy RPC system. The plan is to get the new code base stabilized
with the existing feature set, before adding new features.
Slowstart (for people doing their own thing)
- The gwt.rpc file is now mandatory for operation of the RPC system.
It's no longer just a policy file, but contains metadata about any
given permutation. You can override RpcServlet.findClientOracleData()
to alter how this data is retrieved.
- If you have been using the static gwt.user.rpc.server.RPC utility
class, there is a new formulation of the same in gwt.rpc.server.RPC.
Instances of the ClientOracle type can be obtained from
WebModeClientOracle.load() or simply instantiating a
HostedModeClientOracle.
- If you want your servlet to be able to talk to both legacy and new
RPC clients, extend HybridServiceServlet.
I'm mainly looking for the following kinds of feedback:
- Knowing that it did work is helpful.
- 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.
- There are a lot of low-hanging optimizations that remain to be
done. If you have any particular metrics or features that you
particularly care about, let me know so I can prioritize accordingly.
Why switch?
- Faster IE6 performance
- Hosted Mode clients don't need a serialization policy file pushed
to the server, so you can more easily test changes to client code in a
-noserver configuration.
- A much more hackable code base to add oft-requested features to
the GWT RPC system.
--
Bob Vawter
Google Web Toolkit Team
Thanks for the data.
Just to clarify, these payloads were only going from the server to the client?
<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