tree e56d321fe5b5ff7c363284c4d65a0fe0455c9ec6
parent 87db4d7569febc324634657cb624124bf3fa9218
author gwt.team.mmendez <gwt.team.mmendez@8db76d5a-ed1c-0410-87a9-c151d255dfc7> 1184165721 +0000
committer gwt.team.mmendez <gwt.team.mmendez@8db76d5a-ed1c-0410-87a9-c151d255dfc7> 1184165721 +0000

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