gwt /
gwt /
21a5a48ef6d4fa6eef604b201c48b20587bac9fa Fixes issue 1138. The root cause was that the RPC class and the ServerSerializationStreamReader used their respective this.class.getClassLoader() to get a classloader to resolve types during deserialization. This worked well as long as the GWT code was in the same classloader as the application code. In scenarios where the GWT code was moved into a shared classloader, like tomcat's shared classloader, we would fail to resolve classes.
This patch uses a solution based on context classloaders for the RPC class. The reasons for the decision are as follows:
1. Context classloaders are the mechanism used by JAXP, and JNDI.
2. Context classloaders will be set correctly in servlet containers, which is our primary target environment.
3. Having worked the patch using context classloaders and explicitly passing in the classloader, the majority of the time the classloader that you would pass in to the RPC class would be the servlet impl's classloader which would be the contextclassloader or at least be accessible from the context classloader. For most users,they will not need to worry about which classloader to use.
4. There are workarounds for OSGi and similar environments which can ensure that the context classloader gets set correctly.
This patch was tested using a Tomcat instance with gwt-servlet.jar in the shared classloader.
Review by: scottb
git-svn-id: https://google-web-toolkit.googlecode.com/svn/trunk@1232 8db76d5a-ed1c-0410-87a9-c151d255dfc7
2 files changed
