we are haunted by occasional occurences of exceptions such as:
com.google.gwt.user.client.rpc.SerializationException: Type 'xxx' 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 = xxx
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:610)
at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamWriter.writeObject(AbstractSerializationStreamWriter.java:129)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter$ValueWriter$8.write(ServerSerializationStreamWriter.java:152)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serializeValue(ServerSerializationStreamWriter.java:534)
at com.google.gwt.user.server.rpc.RPC.encodeResponse(RPC.java:609)
at com.google.gwt.user.server.rpc.RPC.encodeResponseForSuccess(RPC.java:467)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:564)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:188)
at de.softconex.travicemanager.server.TraviceManagerServiceImpl.processCall(TraviceManagerServiceImpl.java:615)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:224)
at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:419)
at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:378)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1508)
at java.lang.Thread.run(Thread.java:619)
The application is normally running fine. The indicated class implements Serializable (the whole object graph).
So far the only patterns / observations are:
we seem to have the issue only when the application is used inside an iframe
the problem seems to happen when a new version of the application has been deployed
running firefox in privacy mode (disabling all caches etc.) doesn't fix the problem
Any ideas?
Holger
did you check http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html#serialize
the article says:
It has a default (zero argument) constructor with any access modifier (e.g. private Foo(){} will work)
I'm allways forgetting zeroargument const. when I am making a serializable object :D
Very possible reason - older version of client is still cached in browser. It sends rpc requests, but server is already restarted and have newer versions of rpc files (*.symbolMap)
I encountered the problem when I used Tomcat6 + Devmode in Ubuntu Lucid amd64. Using com.google.gwt.user.client.rpc.IsSerializable instead of java.io.Serializable seemed solved the problem.
I assume you're running the application on localhost and in hosted mode? If so, you might want to keep an eye on the work directory (or the equivalent directory if you're not running the application in a tomcat server). Check the webapp's folder for serialization policiy files (*.gwt.rpc).
It's possible they're not loaded correctly, the only workaround we have found so far, is to restart your server after each serialization fault.
The problem is due to the fact GWT will generate its serialization policy files at run time, assuming you're running in hosted mode. In compiled mode, GWT will generate all necessary files at compile time. AFAIK, tomcat's unable to load in the resource files at run time and hence will not include the serialization files each time they are needed for the first time.
When restarting the server, tomcat's able to pick up the previously generated file and hence you shouldn't receive the same error after restarting.
Can you verify this?
If you are running on JBoss, this might be due to the fact that the previously deployed application is not deleted when undeployed. To fix this, you must modify the following file in JBoss:
${JBOSS_HOME}/server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml
and set the following attribute to true: deleteWorkDirOnContextDestroy
When the previously deployed application is not cleaned up, GWT can be confused about which RPC file it needs to load and you end up with those SerializationException
I had the same problem and I found a solution from another person:
"There is a possibility that you have a class which implements Serializable and you have an attribute field within that class which is not Serializable hence you might be getting this exception."
Many thanks to that person :)
My advice is to make all fields (which are not primitive types) in your class to implement Serializable also! This solved my problem.
This problem occurs when a GWT 2.5 application is compiled using JDK 1.7. GWT 2.5 supports JDK 1.6 and using this version of JDK will fix this issue.
So the RPC files are unique because they are loaded by servlets as well as being used in GWT. See http://code.google.com/webtoolkit/release-notes.html#Release_Notes_1_4_59 where it says "This file must be deployed to your web server as a public resource, accessible from a RemoteServiceServlet via ServletContext.getResource()"
Is it possible the new application is being reloaded dynamically and getResource is failing in some way? Does restarting the application fix things?
I've had the same error and fix this by clean the browse cache and navigation history.
I was getting a SerializationException also but I was also seeing this error showing up right before the serialization exception:
[uptimereports/2.340102563369350884].:
Example : error : cannot find template
registration-confirmation.vm
It turned out to be a problem finding my velocity template. Once I fixed that problem the SerializationException stopped showing up, so if you follow Kerem's advice and still have problems, look for other exceptions in your log.
The best way to know the exact issue is to compile your code using -logLevel DEBUG or TRACE and check inside Validating Units. I am sure you would be able to find out the exact issue with line numbers as well.
First make sure you have a 'clean' serializable class ie empty constructor, no inner classes implementing serializable and use GWT Serializable class instead of Java Serializable class.
Then simply open your site in an Incognito tab (Chrome) solves the problem. Local browser cache causes loading old rpc files.
I had this problem when running SuperDevelopmentMode with a setup where codeserver was not on the same host as tomcat server. I had codeserver on my host, while tomcat running in the docker container. It turns out in such setup app server cannot get the right serialization policy files, so quite similar as described by thomaux in one of answers above, just different setup.
I had to add -Dgwt.codeserver.port=9876 to start parameters of tomcat as described here. This causes GWT SuperDevMode to switch to mode of getting serialization policy files through network. Still the url is hardcoded in com.google.gwt.user.server.rpc.RemoteServiceServlet#getCodeServerPolicyUrl as
"http://localhost:" + codeServerPort
so you have to make sure that your tomcat can reach codeserver on that port, by tunneling or routing the traffic if necessary. Alternative is to hack GWT code to allow changing that localhost to something else too, but this doesn't look clean and secure.
Related
I'm using the "org.springframework.boot:spring-boot-devtools" dependency in my Grails application for the live reload of the application on code change. The problem is, it seems that this dependency is causing some conflict with drools.
On kieSession.setGlobal(name, value) in my code, I get the following error:
java.lang.RuntimeException: Illegal class for global. Expected [com.user.PersonAccount], found [com.user.PersonAccount]
Removing the "spring-boot-devtools" dependency fixes the issue but I need this dependency for the live reload, it's important in development.
Anyone knows why this dependency is causing this conflict? and what I can do to fix it or as a workaround?
Thanks in advance!
To whoever might have the same issue in future, the issue is already reported and described before: https://issues.redhat.com/browse/DROOLS-1540 and a fix has been included in drools starting from version 7.26.0.Final (https://github.com/kiegroup/drools/commit/85c5308031a84a0ac4086c1df363bb1b4b3c6af9)
If you don't want to upgrade to the latest version of drools, there's still a workaround to fix the issue which is already mentioned on the devtools page of spring-boot (https://docs.spring.io/spring-boot/docs/current/reference/html/using.html#using.devtools.restart.customizing-the-classload).
I added META-INF/spring-devtools.properties with the jars that I want to include in the restart classloader (mainly the drools + kie jars) & the issue is fixed.
When the devtools recompile the class, the byte code no longer matches the byte code from your rules. It's not doing a very good job of warning you, but what it's trying to say is "you are trying to give me a com.user.PersonAccount instance, but it doesn't look like what I know a com.user.PersonAccount instance should look like."
Therefore if you insist on using this tool which will recompile things on the fly, you'll need to also recompile and reload the rules on the fly. Or not use spring-boot-devtools.
This question might have been asked earlier on SO, and please be assured I did check all the available solutions. Was still unable to get it to run
My problem is exactly as described in this post Shared native library in Tomcat UnsatisfiedLinkError
Standalone Java application is running perfectly well. However with Tomcat(9) it fails to run and throws
java.lang.UnsatisfiedLinkError: third_party.org.chokkan.crfsuite.crfsuiteJNI.swig_module_init()V
at third_party.org.chokkan.crfsuite.crfsuiteJNI.swig_module_init(Native Method)
at third_party.org.chokkan.crfsuite.crfsuiteJNI.<clinit>(crfsuiteJNI.java:87)
at third_party.org.chokkan.crfsuite.Tagger.<init>(Tagger.java:39)
I know that my DLL is being loaded, also I checked that the folder my dll is in, is in the PATH variable. I have also checked the classes being loaded and the DLL is infact being loaded.
I have noticed 3 types of UnsatisfiedLinkError at SO
1) java.lang.UnsatisfiedLinkError: third_party.org.chokkan.crfsuite.crfsuiteJNI.swig_module_init()V
2) java.lang.UnsatisfiedLinkError: third_party.org.chokkan.crfsuite.crfsuiteJNI.swig_module_init()B
3) Where the class loader is loading twice.
I believe the V , at the end does signifies something. But I am not able to figure out exactly what?
One of the accepted answers in the SO post I shared above claims it has something to do with version. I do not understand how is that an acceptable solution since it works perfectly well when run as a standalone java application.
Wasted a lot of time already, any help is appreciable.
Thanks
Chahat
I faced with the same issue. I finally find the solution. It works for me.
First, I instaled libLBFGS and crfsuite. You can find the instruction here (http://www.chokkan.org/software/crfsuite/manual.html). The libcrfsuite.so will be install in /usr/local/lib
Second, I edit tomcat config in order to load native library. I create setenv.sh in tomcat bin folder, set CATALINA_OPTS variable with content :
export CATALINA_OPTS="-Djava.library.path=/usr/local/bin:/usr/local/lib"
Finally, I used custom ServletContextListener and explicitly load libcrfsuite.so by System.load(). I go this link to download lib (https://github.com/vinhkhuc/jcrfsuite/tree/master/src/main/resources/crfsuite-0.12)
I had a similar problem but not with Tomcat.
I ended up copying the logic from one of their classes and simply invoking:
static {
try {
CrfSuiteLoader.load();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
I'm using WAS Liberty 8.5.5.5 under Java 7 (tried under Oracle java 7-8 and IBM java 7 as well).
When I create one NamedQuery, the code compiles, deployes, and runs fine.
However, If I try to use the NamedQueries annotation I get the following excpetion:
java.lang.ArrayStoreException: com.sun.proxy.$Proxy29
at sun.reflect.annotation.AnnotationParser.parseAnnotationArray(AnnotationParser.java:765)
at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:537)
at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:355)
at sun.reflect.annotation.AnnotationParser.parseAnnotation2(AnnotationParser.java:286)
at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:120)
at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:72)
at java.lang.Class.createAnnotationData(Class.java:3521)
at java.lang.Class.annotationData(Class.java:3510)
at java.lang.Class.getAnnotation(Class.java:3415)
After some investigation, I found the following two bugs:
ArrayStoreException in Jboss: https://issues.jboss.org/browse/JBAS-9392
ArrayStoreException when annotation declaring class missing: http://bugs.java.com/view_bug.do?bug_id=7183985
It seems that the javax.persistence.NamedQueries inteface is missing in the enviroment (stangely the javax.persinstence.NameQuery is present ...)
I use Eclipse Kepler for development, the deployment is also handled by the IDE.
On more thing; other developers using the same code base can successfully deploy and run the application with the afformentioned settings - so I suspect the deployment might be responsible for this issue.
Is there a way to "tell" the WAS to include the missing class runtime?
It took some time, but I found the solution.
We are using Ecliselink as a JPA provider, and load it accordingly:
<classloader commonLibraryRef="EclipseLinkLib" delegation="parentLast"/>
It seems that Eclipselink (version 2.5.2) contains the javax.persistence.NamedQuery interface, but not the javax.persistence.NamedQueries interface - this way WAS does not load the missing interface.
By changing delegation="parentFirst" the app works fine.
thanks in advance for attention.
It's the first time i am writing on this site (quite newbie :) )
I previously read question of a user asking for my same problem. Although i read a lot i could not find a solution.
Problem:
I am trying to use MatlabControl jar (http://code.google.com/p/matlabcontrol/) to "call" matlab within my java code.
When i try this api within a normal java application to try it (including matlabcontrol.jar in the buildpath) everything works perfectly.
My issue is to make it work on an ejb module with jboss 5 AS:
i can deploy the ejb module and i can see classes of the matlabcontrol.jar (which i put in server/default/lib folder), but it is not working and is returning me the following exception:
Caused by: java.lang.NullPointerException
at java.io.File.<init>(File.java:251)
at matlabcontrol.Configuration.getSupportCodeLocation(Configuration.java:227)
at matlabcontrol.RemoteMatlabProxyFactory.createProcess(RemoteMatlabProxyFactory.java:278)
at matlabcontrol.RemoteMatlabProxyFactory.requestProxy(RemoteMatlabProxyFactory.java:116)
at matlabcontrol.RemoteMatlabProxyFactory.getProxy(RemoteMatlabProxyFactory.java:134)
at matlabcontrol.MatlabProxyFactory.getProxy(MatlabProxyFactory.java:81)
that lead me to the following lines:
URL url = Configuration.class.getProtectionDomain().getCodeSource().getLocation();
File file = new File(url.toURI().getPath()).getCanonicalFile();
The very strange thing is that very very rarely, after restarting jboss and re-deploying the ejb module, the system works!.
I really don't know if i have to modify the source code of these last 2 lines (as if it is a problem of not properly getting the location of the jar code) or to set some configuration files of jBoss to set the classpath differently.
Thanks again in advance.
Any help would be very appreciate.
The mistake was in the code to find the location of the jar at runtime.
I printed the path, which ended with "!" and double slash, so I removed these chars and I was finally able to make this API work.
I've got a Android AppEngine Connected Project I'm trying to build using GWT2.4 RequestFactory and Objectify on my Eclipse IDE.
Apparently I need to run the RequestFactory Validation Tool because I'm using ServiceName and ProxyForName annotations (these are required especially when working on the Android client side). My problem is the Eclipse can't validate it and the solution provided at http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation#IDE_configuration is enough to make me rip my eyes out.
Since I'm working on a Windows machine, the shell script provided is not very useful. Trying to run Validation Tool from a cmd propt returns the error message:"This tool must be run with a JDK, not a JRE"
Can someone explain how this Tool is supposed to be run? Is there a way to use it as an External Tool in eclipse?
Normally if you follow carefully the instructions in the link you show, and run the GWT Development Mode from Eclipse, the Validation should be done automatically at the time you access the development URL with your browser.
For the record, I've actually had some problems with it, but launching the application several times maked it work.
Well, I ran into the same problem as well. When I tried annotation processing (under Java Compiler-> Annotation processing )was being disabled. So RequestFactoryDeobfuscatorBuilder was not being generated. Try enabling that and rebuilding your project.
I've just recovered from two days of hunting this bug down in a project that used to run validation properly but stopped.
In my case I had a new-ish generic BaseRequestContext and a specific sub-interface that extended it. My parent interface declared a method that didn't match the Locator's exactly (e.g. getThing(T) vs get(T)) and this wasn't reported as an error but did stop the validation tool from completing.
Apt is also removed in Java 8 : http://openjdk.java.net/jeps/117 . So beware.
Switching back to Java 7 will fix the issue if you are using Java 8.
I understood why the error happens sometimes in a project: the compiler was complaining it cannot find the directory .apt . But when I tried to create it manually it was not possible (under windows). I think the validation tool mutes the exception of not being able to create the directory: try renaming .apt in your validation tool calls (do a text search in your project)