I further investigated and found out that this is actually a regression issue caused by this change:
http://code.google.com/p/google-web-toolkit/source/diff?spec=svn7354&r=5678&format=side&path=/trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java&old_path=/trunk/user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java&old=5672 When the new deRPC was initially added, a change was checked in on the old RPC class... as a result, our custom field serializers no longer work. David On Jan 5, 3:01 pm, stuckagain <david.no...@gmail.com> wrote: > Hi, > > We are having some issues with classloaders and custom field > serializers in GWT 2.0 in combination with oc4j 10.1.3.5. I was > assuming that the issue was purely an Oracle thing, but I looked > through the RPC code and found some differences in the way > classloaders are used in the RPC package. > > The javadocs of RPC.decodeRequest state that the Thread.currentThread > ().getContextClassLoader() is used to load the service interfaces. > Unfortunately this approach is not used when searching for the custom > field serializers. > > Custom field serializers are looked up using: > com.google.gwt.user.server.rpc.impl.SerializabilityUtil.computeHasCustomFieldSerializer > > This method uses the SerializabilityUtil.class.getClassLoader() and in > our specific case this fails to locate our custom field serializer. Is > there a reason why this is different ? > > What is special in our EAR/WAR deployment ? All libs (including gwt- > servlet.jar and ourgwt.jar, which contains the custom field > serializer) are available in the EAR and are available in the WAR > classloader through the manifest of the WAR. > > David -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
