Proxying a GWT 2.0 app is difficult: is this a feature or a bug?
sbrudenell
I recently tried to proxy a GWT (2.0) app with Apache's mod_proxy,
such that
http://proxy.example.com/instance/ is proxied to
http://instance.example.com/app/ , where my GWT app is deployed.
I can load my app via http://proxy.example.com/instance/, but many RPC
calls start failing due to SerializationExceptions. I've verified the
proxy configuration is set up correctly (to the point of inspecting
HTTP headers). After some investigation, it seems that GWT chokes on
the fact that the path used to request the app is not the same as the
deployment path (that is, /instance/ is not the same as /app/).
There is a check in RemoteServiceServlet.loadSerializationPolicy that
the moduleBaseURL must be a subdirectory of wherever the app is
deployed (according to HttpServletRequest.getContextPath). The
moduleBaseURL used for comparison is actually passed from the client
in the payload of *every* RPC call. If this check fails, the behavior
is strange: the SerializationPolicy fails to load (which results in a
load of the "legacy, 1.3.3 compatible" SerializationPolicy), but the
request otherwise proceeds as normal.
This of course means that the RPC servlet will fail to serialize any
type that doesn't implement IsSerializable. For those of us who have
been developing in the GWT 1.5+ world, many types can have this
"problem".
My workaround has been to override
RemoteServiceServlet.doGetSerializationPolicy, passing a moduleBaseURL
constructed so that this check never fails.
My questions are:
1) Is this behavior intended? I haven't been able to imagine a
scenario where the behavior pattern of "unexpected request path yields
legacy SerializationPolicy" is necessary or even beneficial, but maybe
I'm not creative enough. It definitely makes my case more painful than
I've come to expect from GWT.
2) Why is the moduleBaseURL being transmitted in the RPC payload in
the first place? It seems like this is not only redundant information,
but defeats the HTTP request path as the canonical client-visible
location of a resource.
~Steve