Re: [gwt-contrib] deRPC experiences
Thank you for the feedback.
It was trivial to hook up the findClientOracleData to work with the existing
process
Excellent.
- NPE in the WebModeClientOracle.readStreamAsObject finally block if
objectInputStream can't be created (ie: if the format is invalid)
Will fix.
- If the GWT module base path URL isn't absolute, getRequestModuleBasePath
fails. We use relative base paths to simplify our hosted mode development.
Can you describe this setup in more detail? What is the canonical URL
that the request's url should be evaluated against?
- 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:
The code that you posted is about creating a payload for a object that
has custom serialization. What does looking at the fields of the
InvokeCustomFieldSerializerCommand object show?
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.
How about a
protected Object getRequestTargetObject() {
return this;
}
?
--
Bob Vawter
Google Web Toolkit Team
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] deRPC experiences
On 2010-03-18, at 12:15 PM, BobV wrote:
- If the GWT module base path URL isn't absolute, getRequestModuleBasePath
fails. We use relative base paths to simplify our hosted mode development.
Can you describe this setup in more detail? What is the canonical URL
that the request's url should be evaluated against?
Our setup is pretty complex - we've got our own version of XSLinker that
supports development mode, fragments and being embedded inline in the host
page. Because we're inlining the selection script, we ripped out the existing
code to compute the module base. It was replaced with a single meta tag read by
the inlined selection script.
At development time, we have a custom servlet filter that generates the host
pages dynamically from a set of templates and content files (based on the same
code that generates these files statically for deployment to our website). The
filter writes out the script to load the selection script dynamically, as
well as a header that gets picked up by our custom cross-domain linker. This
filter currently writes the base URL relatively, ie:
meta name=ds:base content=/com.dotspots.ModuleName/ /
I can work around it by picking up the hostname and port from the request in
the servlet filter and prefixing the base URL we write with those. I've never
had an issue with the relative base URL before and haven't run across code
anywhere in the user library that assumes the base URL is absolute. It's pretty
simple to fix on our end, however.
- 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:
The code that you posted is about creating a payload for a object that
has custom serialization. What does looking at the fields of the
InvokeCustomFieldSerializerCommand object show?
I don't have an easy way to debug our server against a compiled web mode (we
have a launch target for that, but it was so infrequently used that it
bitrotted). It might be easier for me to try to reproduce this in a standalone
project. I'll give that a shot and report back.
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.
How about a
protected Object getRequestTargetObject() {
return this;
}
That would be perfect, thanks!
Matt.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
To unsubscribe from this group, send email to
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this
email with the words REMOVE ME as the subject.
Re: [gwt-contrib] deRPC experiences
On 2010-03-18, at 12:15 PM, BobV wrote:
The code that you posted is about creating a payload for a object that
has custom serialization. What does looking at the fields of the
InvokeCustomFieldSerializerCommand object show?
I can reproduce this in a barebones project. It looks like it's this class
we're using to avoid RPC pulling in all the subclasses of HashMap. We have
similar classes for ArrayList and HashSet, but those all have custom
serializers. I don't know why I didn't create a custom serializer for this
class as well (though there aren't any ill effects with standard RPC).
public final class RpcMapT, V extends HashMapT, V implements IsSerializable
{
private static final long serialVersionUID = 0L;
public RpcMap() {
}
public RpcMap(final MapT, V map) {
super(map);
}
public static X, Y RpcMapX, Y wrap(final MapX, Y map) {
return map == null ? null : new RpcMapX, Y(map);
}
}
Here are the fields of InvokeCustomFieldSerializerCommand:
x InvokeCustomFieldSerializerCommand (id=59)
instantiatedTypeClassT (com.dotspots.rpctest.client.RpcMap)
(id=102)
manuallySerializedType ClassT (java.util.HashMap) (id=107)
serializer ClassT
(com.google.gwt.user.client.rpc.core.java.util.HashMap_CustomFieldSerializer)
(id=108)
setters ArrayListE (id=109)
values ArrayListE (id=116)
Matt.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
To unsubscribe from this group, send email to
google-web-toolkit-contributors+unsubscribegooglegroups.com or reply to this
email with the words REMOVE ME as the subject.
