I took the plunge and started moving our codebase over to deRPC. It's pretty
simple to get bootstrapped, though there's some deployment work we needed to do
to ensure that our .gwt.rpc files are made available to the backends.
I'm storing our history of .gwt.rpc files in S3, since we're already pushing
files like this into S3 during our deployment. It was trivial to hook up the
findClientOracleData to work with the existing process (though we're currently
gzipping the already-gzipped policy files):
@Override
protected InputStream findClientOracleData(String requestModuleBasePath, String
permutationStrongName) throws SerializationException {
try {
return new GZIPInputStream(
new URL("http://s3-bucket-name.amazonaws.com/";
+ permutationStrongName + ".gwt.rpc.gz").openStream());
} catch (MalformedURLException e) {
throw new SerializationException(e);
} catch (IOException e) {
throw new SerializationException(e);
}
}
I ran into a few small issues while developing this:
- NPE in the WebModeClientOracle.readStreamAsObject finally block if
objectInputStream can't be created (ie: if the format is invalid)
- If the GWT module base path URL isn't absolute, getRequestModuleBasePath
fails. We use relative base paths to simplify our hosted mode development.
- WebModePayloadSink seems to throw an NPE when push a null constructorIdent.
I'm still digging into this, but it might be related to the fact that we're
sending enums with enum value methods across the wire:
String constructorIdent = clientOracle.getMethodId(x.getTargetClass(),
constructorMethodName, x.getTargetClass());
assert constructorIdent != null : "constructorIdent "
+ constructorMethodName;
// constructor(new Seed),
push(constructorIdent);
RpcServlet is much nicer to work with that RemoveServiceServlet, kudos. It
would be nice if the service object (passed into decodeRequest and
invokeAndStreamResponse) were retrieved via a protected method, rather than
assumed to be 'this'. We wire the service object into the servlet at
configuration time via Spring, so I had to duplicate the contents of
processCall.
Overall we saw a small decrease in the initial code fragment (~5%). I didn't
notice any particular slowness while testing.
Matt.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
