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.
