GWT - com.google.gwt.user.client.rpc.SerializationException occasionnel
nous sommes hantés par des occurrences occasionnelles d'exceptions telles que:
com.google.gwt.user.client.rpc.SerializationException: le type 'xxx' n'était pas assignable à 'com.google.gwt.user.client.rpc.IsSerializable' et n'avait pas de sérialiseur de champ personnalisé. Pour des raisons de sécurité, ce type ne sera pas sérialisé .: instance = xxx à l'adresse com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize (ServerSerializationStreamWriter.Java:610) à l'adresse com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamWriter.writeObject (AbstractSerializationStreamWriter.Java:129) à l'adresse com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter $ ValueWriter $ 8.write (ServerSerializationStreamWriter.Java:152) à l'adresse com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serializeValue (ServerSerializationStreamWriter.Java:534) à l'adresse com.google.gwt.user.server.rpc.RPC.encodeResponse (RPC.Java:609) à l'adresse com.google.gwt.user.server.rpc.RPC.encodeResponseForSuccess (RPC.Java:467) à l'adresse com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse (RPC.Java:564) à l'adresse com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall (RemoteServiceServlet.Java:188) at de.softconex.travicemanager.server.TraviceManagerServiceImpl.processCall (TraviceManagerServiceImpl.Java:615) à l'adresse com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost (RemoteServiceServlet.Java:224) à l'adresse com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost (AbstractRemoteServiceServlet.Java:62) à l'adresse javax.servlet.http.HttpServlet.service (HttpServlet.Java:710) à l'adresse javax.servlet.http.HttpServlet.service (HttpServlet.Java:803) à org.Apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.Java:290) à org.Apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.Java:206) à org.jboss.web.Tomcat.filters.ReplyHeaderFilter.doFilter (ReplyHeaderFilter.Java:96) à org.Apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.Java:235) à org.Apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.Java:206) à org.Apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.Java:230) à org.Apache.catalina.core.StandardContextValve.invoke (StandardContextValve.Java:175) à org.jboss.web.Tomcat.security.SecurityAssociationValve.invoke (SecurityAssociationValve.Java:179) à org.jboss.web.Tomcat.security.JaccContextValve.invoke (JaccContextValve.Java:84) à org.Apache.catalina.core.StandardHostValve.invoke (StandardHostValve.Java:127) à org.Apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.Java:102) à org.jboss.web.Tomcat.service.jca.CachedConnectionValve.invoke (CachedConnectionValve.Java:157) à org.Apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.Java:109) à org.Apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.Java:262) à org.Apache.coyote.ajp.AjpAprProcessor.process (AjpAprProcessor.Java:419) at org.Apache.coyote.ajp.AjpAprProtocol $ AjpConnectionHandler.process (AjpAprProtocol.Java:378) à org.Apache.Tomcat.util.net.AprEndpoint $ Worker.run (AprEndpoint.Java:1508) sur Java.lang.Thread.run (Thread.Java:619)
L'application fonctionne normalement bien. La classe indiquée implémente Serializable (le graphe d'objet entier).
Jusqu'à présent, les seuls modèles/observations sont:
il semble que le problème ne se pose que lorsque l'application est utilisée à l'intérieur d'un iframe
le problème semble se produire lorsqu'une nouvelle version de l'application a été déployée
exécuter Firefox en mode privé (désactiver tous les caches, etc.) ne résout pas le problème
Des idées?
Holger
avez-vous vérifié http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html#serialize l'article dit: Il a un constructeur par défaut (zéro argument) avec n'importe quel modificateur d'accès (par exemple, private Foo(){} fonctionnera)
J'oublie toujours zeroargument const. quand je fabrique un objet sérialisable: D
J'ai rencontré le problème lorsque j'ai utilisé Tomcat6 + Devmode dans Ubuntu Lucid AMD64. En utilisant com.google.gwt.user.client.rpc.IsSerializable au lieu de Java.io.Serializable semblait résolu le problème.
Raison très possible: l'ancienne version du client est toujours mise en cache dans le navigateur. Il envoie des requêtes RPC, mais le serveur est déjà redémarré et dispose de nouvelles versions des fichiers RPC (* .symbolMap).
Je suppose que vous exécutez l'application sur localhost et en mode hébergé ? Si tel est le cas, gardez un œil sur le répertoire work (ou sur le répertoire équivalent si vous n'exécutez pas l'application sur un serveur Tomcat). Recherchez dans le dossier de l'application Web les fichiers de règles de sérialisation (* .gwt.rpc).
Il est possible qu'ils ne soient pas chargés correctement. La seule solution trouvée à ce jour consiste à redémarrer votre serveur après chaque erreur de sérialisation.
Le problème tient au fait que GWT générera ses fichiers de règles de sérialisation au moment de l’exécution, à condition que vous exécutiez le mode hébergé. En mode compilé, GWT générera tous les fichiers nécessaires au moment de la compilation. Autant que je sache, Tomcat est incapable de charger les fichiers de ressources au moment de l'exécution et n'inclut donc pas les fichiers de sérialisation à chaque fois qu'ils sont nécessaires.
Lors du redémarrage du serveur, Tomcat est en mesure de récupérer le fichier généré précédemment. Par conséquent, vous ne devriez plus recevoir la même erreur après le redémarrage.
Pouvez-vous vérifier cela?
Si vous utilisez JBoss, cela peut être dû au fait que l'application précédemment déployée n'est pas supprimée lorsqu'elle n'est pas déployée. Pour résoudre ce problème, vous devez modifier le fichier suivant dans JBoss: attribut suivant à true: deleteWorkDirOnContextDestroy
Lorsque l'application précédemment déployée n'est pas nettoyée, GWT peut ne pas savoir quel fichier RPC doit être chargé et vous vous retrouvez avec ces exceptions SerializationException.
J'ai eu le même problème et j'ai trouvé une solution d'une autre personne:
"Il est possible que vous ayez une classe qui implémente Serializable et que vous ayez un champ d'attribut dans cette classe qui ne soit pas Serializable et que vous obteniez peut-être cette exception."
Merci beaucoup à cette personne :)
Mon conseil est de faire en sorte que tous les champs (qui ne sont pas des types primitifs) de votre classe implémentent également Serializable! Cela a résolu mon problème.
Ce problème se produit lorsqu'une application GWT 2.5 est compilée à l'aide de JDK 1.7. GWT 2.5 prend en charge JDK 1.6 et l’utilisation de cette version corrigera ce problème.
Ainsi, les fichiers RPC sont uniques car ils sont chargés par des servlets et utilisés dans GWT. Voir http://code.google.com/webtoolkit/release-notes.html#Release_Notes_1_4_59 où il est indiqué "Ce fichier doit être déployé sur votre serveur Web en tant que ressource publique, accessible à partir d'un RemoteServiceServlet via ServletContext.getResource () "
Est-il possible que la nouvelle application soit rechargée dynamiquement et que getResource échoue d'une manière ou d'une autre? Est-ce que le redémarrage de l'application corrige les problèmes?
J'ai eu la même erreur et corrige cela en nettoyant le cache de navigation et l'historique de navigation.
Le meilleur moyen de connaître le problème exact est de compiler votre code à l'aide de -logLevel DEBUG ou TRACE et de vérifier à l'intérieur de l'unité de validation. Je suis sûr que vous pourrez trouver le problème exact avec les numéros de ligne.
J'obtenais aussi une exception SerializationException mais je voyais également cette erreur se présenter juste avant l'exception de sérialisation:
[uptimereports/2.340102563369350884].: Exemple: erreur: impossible de trouver le modèle inscription-confirmation.vm
Il s'est avéré être un problème pour trouver mon modèle de vélocité. Une fois que j'ai résolu ce problème, l'exception SerializationException a cessé de s'afficher. Si vous suivez les conseils de Kerem et avez toujours des problèmes, recherchez d'autres exceptions dans votre journal.