Serialization issue

[Niklas Derouche]

I spent hours and hours scratching my head over this one yesterday and since this is the first time I have

run into a significant issue with GWT I was somewhat surprised.

 

I have created a number of classes that have a common superclass which implements IsSerializable. They

all conform themselves as well. Nothing freaky.

 

What is freaky however is that while one class works, another one doesn't althought there are NO differences

between them apart from the name. None. Niente. Nada.

 

Now - this is puzzling. Anyone else run into anything similar and have a solution? I'd like to share the source and

classnames and so on but I can't unfortunately. Which sucks - I know - but I was hoping that there might be some

help somewhere anyway.

 

Oh and I should also note that the error isn't an exception. It's a JavaScript error which kills the hosted browser

completely.

 

BR

 

Niklas Derouche

--
opus indubitanter , deficio fidens

[Dan Morrill]

Hi, Niklas.  There is an open bug in the RPC code that essentially comes down to the fact that IsSerializable doesn't inherit.  That is, even if a parent class implements IsSerializable, the serializer doesn't "see" it for derived classes.

Try adding IsSerializable directly to all your classes, and see if that helps.

- Dan

[Niklas Derouche]

Dan,

 

thanks for that. The weirdest part is however that it seems to work if you are the grandchild (if you understand what I mean).

 

n.

 

[Dan Morrill]

Yeah, it's a weird one all right, no doubt about it.  Fortunately, there's a whole lot of working going on in RPC currently, and there should be some improvements over the next version or two of GWT.

Did my suggestion fix your problem, though?  I wasn't sure from your response if you got it working...

- Dan Morrill

[Niklas Derouche]

Oh sorry, however the unfortunate response is that no -  it didn't. The hosted mode crashes and locks up. Still haven't tested it in the compiled mode however, there might be some difference there if there are some namespace issues or something of that nature. Who knows.

[Niklas Derouche]

Ok, I have tried it compiled. It doesn't crash/hang the browser but it certainly shows that there is one of two types that are exactly the same that can't be deserialized. Weirdness.

 

n.

 

[Dan Morrill]

Hmm.  Another thing to keep in mind is that the RPC serialization code unfortunately tends to swallow exceptions.  That is, it catches them and ends up re-throwing a ClassNotFoundException, which can mask a lot of problems.  A common one is that your RPC Servlet fails to correctly implement your service interface (such as by forgetting the 'implements' clause or by implementing an old version.)

Also, when you say a "JavaScript error", do you mean that the hosted mode log is reporting "exception thrown into JavaScript", or some other kind of error?  If you mean the former, then you should be able to click on the log message and see what the root cause is.  You might also try aggressively setting a bunch of breakpoints in hosted mode, and stepping through liberally.  That will be a pain, but sometimes it is the only wait to find errors that originate from weird places.

[Niklas Derouche]

Ummm no. I mean a proper Internet Explorer Script Error.

 

Line:9

Char:3

Error: Unspecified error

[frank]

I have recently ported to version 1.3.3 and I have started to observe
some strange behavior with sending bytes to the RPC service.
Specifically, I can send a variable of type String to the server and
everything works fine. However, as soon as I change that variable to a
byte array (byte[]) of any size, the RPC call fails giving me the
following error:

2007-02-16 02:29:50 StandardContext[]Exception while dispatching
incoming RPC call
com.google.gwt.user.client.rpc.SerializationException:
java.lang.reflect.InvocationTargetException
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.deserialize(ServerSerializationStreamReader.java:
168)
at
com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamReader.readObject(AbstractSerializationStreamReader.java:
61)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.deserializeValue(ServerSerializationStreamReader.java:
70)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:
270)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:
167)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:
104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:
198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:
104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:
104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
118)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:
102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:
104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:
520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:
160)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374)
at
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:
675)
at
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866)
at org.apache.tomcat.util.threads.ThreadPool
$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown
Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.deserializeWithCustomFieldDeserializer(ServerSerializationStreamReader.java:
216)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.deserializeImpl(ServerSerializationStreamReader.java:
190)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.deserialize(ServerSerializationStreamReader.java:
151)
... 32 more
Caused by: java.lang.NumberFormatException: Value out of range.
Value:"255" Radix:10
at java.lang.Byte.parseByte(Byte.java:153)
at java.lang.Byte.parseByte(Byte.java:108)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.readByte(ServerSerializationStreamReader.java:
97)
at
com.google.gwt.user.client.rpc.core.java.lang.byte_Array_CustomFieldSerializer.deserialize(byte_Array_CustomFieldSerializer.java:
30)
... 38 more

What causes me some headache is the fact that the last exception
reads: "Value out of range. Value:"255" Radix: 10." This seems strange
to me as the bytes I'm sending are in base16 (hex, radix: 16). The
funny thing is, now, I don't have a problem with this in hosted mode,
however, as soon as I deploy the site on our Tomcat5 server, I receive
this very disgruntling error.

Anybody have any idea as to what is going on?

[Niklas Derouche]

Dan,

 

waking up at 5 AM has it's benefits. Even if it takes your eyes a good five minutes to stop tearing up when staring at the laptop screen it's still worthwhile when you find the problem. And it was indeed a serialization issue (rather than a deserialization issue)

 

Class A implements IsSerializable. It has subclasses B and C. C also has a subclass D.

 

Now, our remote service implements a method which retrieves an array of B, C or D. If this is initialized like so

 

A[] arr = new B[]

or

A[]arr = new C[]

or

A[]arr = new D[]

 

Then (for some odd reason and I don't feel like digging deeper into this right now because once I have written this email I will go back to sleep) only the last one will work over the wire.

 

However.

 

A[] arr = new A[]

A[0] = new B();

 

Works fine.

 

I hope this was clear (er than mud). I will now sleep. ;) And thanks for your help, frustration is easier to bear when it's shared.

 

[Miguel Méndez]

Dan,

IsSerializable is inherited by subclasses.  Classes which are made serializable via a CustomFieldSerializer will not make its subclasses serializable.

Could you point me to the issue where this bug is described?  If we are talking about issue 242, then we are talking about covariant array types which is a different problem.

Niklas: do you have a stack trace that we can look at?  You can obfuscate the type names if necessary.

On 2/16/07, Dan Morrill < morr...@google.com> wrote:

--
Miguel

[Miguel Méndez]

Hello Niklas,

It sounds like the problem relates to covariant array types, issue 242.  If A is serializable, and you have a method that has A[] as a parameter, then it should also accept arrays of subclasses of A.  So. B[], C[], D[] should be allowed.  The problem is that the RPC system only considers A[] and not B[], C[], and D[]. 

The fact that D[] is accepted makes me think that it is explicitly listed in your one of the classes reachable through your service interface.

That said, the element types can be any serializable subclass of A.  That is why the A[0] = new B() works.

This is definitely a confusing problem to encounter in the field.  I'll see if I can make a case for fixing this in the 1.4 release.

--
Miguel