GWT 1.5 - OSGi - Invalid type signature

[Bradley Beddoes]

Hi All,
I have been doing some development work with GWT 1.5m2 over the past few
days, specifically porting some of the RPC server side stuff to work in
an OSGi bundle scenario.

At this point in time I pretty much have all RPC calls working correctly
except for those involving a List. When sending data involving a list of
string values back to the server I get:

Caused by: com.google.gwt.user.client.rpc.SerializationException:
Invalid type signature for java.util.ArrayList
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.validateTypeVersions(ServerSerializationStreamReader.java:654)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.deserialize(ServerSerializationStreamReader.java:457)
at
com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamReader.readObject(AbstractSerializationStreamReader.java:61)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader$ValueReader$8.readValue(ServerSerializationStreamReader.java:124)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.deserializeValue(ServerSerializationStreamReader.java:362)

The RPC method signature in question is:
public void saveContent(String content, String property, List<String>
value) / public void saveContent(String content, String property,
List<String> value, AsyncCallback callback);

I have also attempted making the above signatures specifically accept
ArrayList instead of List but this has not helped. The above signatures
seemingly operated fine in a non OSGi environment.

I believe this may be caused by one of the following and I was hoping to
get some help from someone more familiar with the internals.
1. The GWT source code I am working from at
http://www.google.com/codesearch?hl=en&q=+package:http://google-web-toolkit.googlecode.com/svn+RPC+show:1Inn03YDPh8:hVsyMz8Y-S8:1Inn03YDPh8&sa=N&cd=1&ct=rc&cs_p=http://google-web-toolkit.googlecode.com/svn&cs_f=trunk/user/src/com/google/gwt/user/server/rpc/RPC.java
is not the 1.5 code base, if so this is likely to be my major issue,
could someone kindly point me the correct direction

2. My creation of a ServerSerializationStreamReader in my re-implemented
RPC class (essentially a copy paste of the natively supplied code with
minor changes) is being passed an incorrect classloader object hence
calls like this:
SerializabilityUtil.getSerializationSignature(instanceClass); are
returning incorrect values

3. OSGi containers always supply java.* from a specific classloader
different to the current bundle which essentially ends up being the same
situation as 2 above

4. Something i am just not smart enough to figure out (likely :P).

Any assistance greatly appreciated.

regards,
Bradley

[Sumit Chandel]

Hi Bradley,

I can't say offhand what's going wrong here, but something you'll want to do is update to the GWT 1.5 RC and recompile your application. It's possible that what you're seeing is a bug that has already been fixed in the RC, so give it a try and see if that helps anything.

You can download GWT 1.5 RC here:
http://code.google.com/webtoolkit/download.html

I also have a couple of comments to some of the points you listed below. Check them out and let me know if there is any more information about the problem we could use to figure out what's going on.

2. My creation of a ServerSerializationStreamReader in my re-implemented
RPC class (essentially a copy paste of the natively supplied code with
minor changes) is being passed an incorrect classloader object hence
calls like this:
SerializabilityUtil.getSerializationSignature(instanceClass); are
returning incorrect values

When you say you re-implemented the RPC class, what exactly have you reimplemented? More details here might uncover something that could be causing the problems you're seeing.

3. OSGi containers always supply java.* from a specific classloader
different to the current bundle which essentially ends up being the same
situation as 2 above

Unfortunately I'm not very familiar with OSGi, so I'm not completely sure about what you mean when you say that OSGi containers supply *.java from a different classloader than the current bundle. Why do the containers have their own classloaders that supply different *.java files?

Hope that helps,
-Sumit Chandel
 

[beddoes]

Hi,
Thanks for the response.

I had actually updated to RC1 and the same issue prevailed. The
changes I made where basically around the classloader retrieval given
that GWT relies on getting the context classloader and Class.forName()
quite a bit. I updated some details on the thread I was using over
here:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/c589a7b472c4dcb/c304452892b098b9

Why does OSGi use a different classloader for java.* well I would not
profess to be an expert by any means of what is going on right down in
the core of an OSGi implementation but the specification is pretty
specific on how it resolves classes, anything in java.* space to my
understanding is resolved by the containers parent classloader, you
then move through the class loaders of various bundles, fragments etc
that are deployed in the system. So trying to do internal dynamic
class loading on top of this results in pain.

[Tom Davies]

I had a similar problem using 1.5RC1 and felix 1.0.4.

My problem was that the OSGi bundle which contained my concrete
RemoteServiceServlet was not able to see the custom serialiser for
ArrayList, as it didn't import that package.

This is not an error as far as the server is concerned -- it simply
serialises the ArrayList as it would any Java object. But because the
custom serialiser *is* available at compile time, the serialisation
ids for ArrayList differ between the client and the server.

I fixed this by adding DynamicImport-Package: com.google.gwt.* to my
OSGI bundle's manifest.

It would have been nice to have a better client side error message for
this eventuality (I first encountered the problem passing an ArrayList
from server to client, while the OPs occurred in the reverse direction)