GWT 2.6.0, SuperDevMode, and GWT-RPC serialization error

[Thad Humphries]

I have switched over a new project to GWT 2.6.0. I running with Maven and the GWT Maven Plugin 2.6.0-rc3.

Everything was working swimmingly with GWT 2.5.1. Now I'm getting GWT-RPC serialization errors when running SuperDevMode.

If I start DevMode from Maven (gwt:run) or through Eclipse, the classes that I have marked as implementing java.io.Serializable pass through the RPC layer without a hitch. However, serialization fails with SuperDevMode:

 

- start SuperDevMode from a console with Maven and gwt:run-codeserver)

- start the server though Eclipse in Development Mode

- on the Development Mode messsage http://192.168.1.101:8888/Mobile.html?gwt.codesvr=192.168.1.101:9997, 

  open the URL http://192.168.1.101:8888/Mobile.html

- turn Dev Mode On and Compile

Now executing the GWT-RPC method shows this in my console file:

Starting Jetty on port 8888

   [WARN] Exception while dispatching incoming RPC call

com.google.gwt.user.client.rpc.SerializationException: Type 'com.optix.mobile.shared.AboutBoxData' was not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and did not have a custom field serializer.For security purposes, this type will not be serialized.: instance = com.optix.mobile.shared.AboutBoxData@adc7bb6

at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:667)

at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamWriter.writeObject(AbstractSerializationStreamWriter.java:130)

at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter$ValueWriter$8.write(ServerSerializationStreamWriter.java:153)

at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serializeValue(ServerSerializationStreamWriter.java:587)

at com.google.gwt.user.server.rpc.RPC.encodeResponse(RPC.java:605)

at com.google.gwt.user.server.rpc.RPC.encodeResponseForSuccess(RPC.java:471)

at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:563)

at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:265)

at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:305)

at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)

at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686)

at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)

at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)

at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)

at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)

at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)

at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)

at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)

at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)

at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)

at org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:68)

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)

at org.eclipse.jetty.server.Server.handle(Server.java:370)

at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)

at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:960)

at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1021)

at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)

at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)

at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)

at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)

at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)

at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)

at java.lang.Thread.run(Thread.java:744)

[ERROR] 500 - POST /optixm/mobile (192.168.1.101) 57 bytes

   Request headers

      Host: 192.168.1.101:8888

      Connection: keep-alive

      Content-Length: 137

      X-GWT-Module-Base: http://192.168.1.101:8888/optixm/

      X-GWT-Permutation: FAC089581D0988AAD23493D0B52C84AF

      Origin: http://192.168.1.101:8888

      User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.102 Safari/537.36

      Content-Type: text/x-gwt-rpc; charset=UTF-8

      Accept: */*

      DNT: 1

      Referer: http://192.168.1.101:8888/Mobile.html

      Accept-Encoding: gzip,deflate,sdch

      Accept-Language: en-US,en;q=0.8

      Cookie: JSESSIONID=11w6l0ygma6brge4d71mphf48

   Response headers

      Content-Type: text/plain

If I implement AboutBoxData with com.google.gwt.user.client.rpc.IsSerializable vs java.io.Serializable, the class will eventually fail because of a member that uses java.io.Serializable.

What could be causing this? I've cleaned my Maven tree down to pom.xml and src, but each time I get this error. 

Is there some new setting to gwt-maven-plugin?

Is there some Eclipse plugin I should|should not be running? My Eclipse has installed m2e from http://download.eclipse.org/technology/m2e/releases/ and m2e-apt and m2e-wtp from http://download.jboss.org/jbosstools/updates/...   I have removed the Jetty plugins I was using elsewhere.

Thanks for y'all's help. I want to run 2.6.0 because I want to work with the latest MGWT SNAPSHOTS as they are available, and I don't want to give up SuperDevMode.

[Juan Pablo Gardella]

Seems a cache error. Did you clean all temp data?

2014-01-31 Thad Humphries <thad.hu...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

[Thad Humphries]

I thought of that since I recall something similar going from 2.4 to 2.5 (or some such upgrade). I cleared my browser cache completely and (as I said) called `mvn clean` to remove target. I also removed the www-test and gwt-unitCache directories. I even did a clean on supporting libraries. Is there something else I should zap?

2014-01-31 Thad Humphries <thad.hu...@gmail.com>:

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.

[Jens]

When using SuperDevMode your server side code must access the GWT-RPC serialization policy files from your SDM code server (because thats the one compiling your app and generating the up-to-date policy file). 

This was kind of annoying with previous GWT versions but now GWT is able to download these files from the code server automatically if you set the system property gwt.codeserver.port for your server. As you seem to use classic DevMode as jetty server you must launch classic DevMode with -Dgwt.codeserver.port=<your SDM code server port>

If for whatever reasons your SDM code server is not listening on localhost you have to override RemoteServiceServlet.getCodeServerPolicyUrl(). Also take a look at the JavaDoc of that method.

-- J.

[Thad Humphries]

Thank, Jens. That's working: I added "-Dgwt.codeserver.port=9876" to the 'VM Arguments' in my run configuration and my RPC call works.

I'm guessing there might be similar magic when running -noserver, right? I want to tackle that next, since Jetty configuration is gone with 2.6.0 and I dearly miss being able to configure my log4j.properties beyond my product's default.

[Thad Humphries]

Yes, it works with -noserver, just add "-Dgwt.codeserver.port=9876" to the 'VM Arguments'.

For debugging with Tomcat, I added "-Dgwt.codeserver.port=9876" to JAVA_OPTS ins setenv.sh.

Thanks again.