DDevelopment & Design

GWT – RPC serialization problem

Type ‘some.type.you.are.sure.is.serializable’ was not included in the set of types that can be serialized by this SerializationPolicy. For security purposes, this type will not be serialized.

One of the most irritating problems that you will probably (sooner or later) have to deal with is GWT serialization policy (or serialization white list). Luckily there are at least 2 ways to work around this issue. Please read GWT documentation and this FAQ first!

If GWT still fails to auto-detect your DTOs or other “go through the wire” objects serialization:

1. Mark your “controversial” objects with com.google.gwt.user.client.rpc.IsSerializable interface This can be a little “ugly” if you want to keep your DTOs clean, without GWT related dependencies… but you can still hack it with
2. Define a new Dummy class with member fields of all types you want to include in serialization. Then add a method to your RPC interface:
Dummy dummy(Dummy d); Add simple implementation:
Dummy dummy(Dummy d) { return d; } And deal with async interface:
void dummy(Dummy d, AsyncCallback callback); From now on the GWT compiler will have no problems with what is or what is not compatible with SerializationPolicy (credits for second solution to Andrej)

— Previous article

Już w najbliższą sobotę Confitura 2012

Next article —

Pije SML do TouKa, a TouK do SMLa

You May Also Like
DDevelopment & Design

Grails with Spock unit test + IntelliJ IDEA = No thread-bound request found

During my work with Grails project using Spock test in IntelliJ IDEA I've encountered this error:

java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.
 at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:131)
 at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.currentRequestAttributes(CommonWebApi.java:205)
 at org.codehaus.groovy.grails.plugins.web.api.CommonWebApi.getParams(CommonWebApi.java:65)
... // and few more lines of stacktrace ;)

It occurred when I tried to debug one of test from IDEA level. What is interesting, this error does not happen when I'm running all test using grails test-app for instance.

So what was the issue? With little of reading and tip from Tomek Kalkosiński (http://refaktor.blogspot.com/) it turned out that our test was missing @TestFor annotation and adding it solved all problems.

This annotation, according to Grails docs (link), indicates Spock what class is being tested and implicitly creates field with given type in test class. It is somehow strange as problematic test had explicitly and "manually" created field with proper controller type. Maybe there is a problem with mocking servlet requests?
DDevelopment & Design

Using Eclipse snippets for faster JUnit test creation (with Mockito!)

I'm using this snippet to create a template of new unit test method supporting BDD mockito tests. This is a good example for adding static imports to a class from snippets.@${testType:newType(org.junit.Test)}public void should${testname}() { ${staticIm...I'm using this snippet to create a template of new unit test method supporting BDD mockito tests. This is a good example for adding static imports to a class from snippets.@${testType:newType(org.junit.Test)}public void should${testname}() { ${staticIm...