41

次のような例外が時折発生することに悩まされています。

com.google.gwt.user.client.rpc.SerializationException：タイプ「xxx」は「com.google.gwt.user.client.rpc.IsSerializable」に割り当てることができず、カスタムフィールドシリアライザーがありませんでした。セキュリティ上の理由から、このタイプはシリアル化されません。：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）atcom.google.gwt.user.server。 com.google.gwt.user.server.rpc.RPCのrpc.impl.ServerSerializationStreamWriter.serializeValue（ServerSerializationStreamWriter.java:534）。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）atorg.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）atorg.jboss。 org.apache.catalinaのweb.tomcat.security.JaccContextValve.invoke（JaccContextValve.java:84）。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）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） 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）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） 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）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）org.apache.tomcat.util.net.AprEndpoint $ Worker.run（AprEndpoint.java:1508）at java.lang.Thread.run（Thread.java:619）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）org.apache.tomcat.util.net.AprEndpoint $ Worker.run（AprEndpoint.java:1508）at java.lang.Thread.run（Thread.java:619）

アプリケーションは通常正常に実行されています。示されたクラスは、Serializable（オブジェクトグラフ全体）を実装します。

これまでのところ、唯一のパターン/観察は次のとおりです。

  • アプリケーションがiframe内で使用されている場合にのみ問題が発生するようです

  • 新しいバージョンのアプリケーションがデプロイされたときに問題が発生するようです

  • Firefoxをプライバシーモードで実行（すべてのキャッシュを無効にするなど）しても問題は解決しません

何か案は？

ホルガー

4

12 に答える 12

32

http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html#serialize記事には次のように記載されてい ます:アクセス修飾子を備えたデフォルトの(引数なし)コンストラクターがあります(たとえば、private Foo(){}動作します)

私はいつも zeroargument const を忘れています。シリアライズ可能なオブジェクトを作成しているとき:D

于 2010-01-23T18:19:38.777 に答える
24

非常に考えられる理由 - 古いバージョンのクライアントがまだブラウザにキャッシュされています。rpc 要求を送信しますが、サーバーは既に再起動されており、新しいバージョンの rpc ファイル (*.symbolMap) があります。

于 2013-03-31T16:52:48.817 に答える
18

Ubuntu Lucid amd64 で Tomcat6 + Devmode を使用したときに問題が発生しました。java.io.Serializableの代わりにcom.google.gwt.user.client.rpc.IsSerializableを使用 すると、問題が解決したようです。

于 2011-10-29T05:13:14.080 に答える
14

アプリケーションを localhostとホスト モードで実行していると思いますか? その場合は、作業ディレクトリ (Tomcat サーバーでアプリケーションを実行していない場合は同等のディレクトリ)を監視することをお勧めします。シリアル化ポリシー ファイル (*.gwt.rpc) の webapp のフォルダーを確認します。

それらが正しくロードされていない可能性があります。これまでに見つかった唯一の回避策は、シリアライゼーション エラーが発生するたびにサーバーを再起動することです。

この問題は、ホスト モードで実行していると仮定して、GWT が実行時にシリアライゼーション ポリシー ファイルを生成するという事実によるものです。コンパイル済みモードでは、GWT はコンパイル時に必要なすべてのファイルを生成します。私の知る限り、Tomcatは実行時にリソースファイルをロードできないため、初めて必要になるたびにシリアライゼーションファイルが含まれません。

サーバーを再起動すると、Tomcat は以前に生成されたファイルを取得できるため、再起動後に同じエラーが発生することはありません。

これを確認できますか？

于 2011-09-19T07:42:41.320 に答える
5

JBossで実行している場合、これは、以前にデプロイされたアプリケーションがアンデプロイされたときに削除されないという事実が原因である可能性があります。これを修正するには、JBossの次のファイルを変更する必要があります：$ {JBOSS_HOME} /server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xmlそして次の属性をtrueに設定します：deleteWorkDirOnContextDestroy

以前にデプロイされたアプリケーションがクリーンアップされていない場合、GWTはロードする必要のあるRPCファイルについて混乱する可能性があり、SerializationExceptionが発生します。

于 2010-09-07T16:00:03.780 に答える
4

私は同じ問題を抱えていて、別の人から解決策を見つけました：

「Serializable を実装するクラスがあり、そのクラス内に Serializable ではない属性フィールドがある可能性があるため、この例外が発生する可能性があります。」

その人に感謝します:)

私のアドバイスは、クラス内のすべてのフィールド (プリミティブ型ではない) を作成して、Serializable も実装することです! これで私の問題は解決しました。

于 2013-02-23T16:39:35.037 に答える
3

この問題は、GWT 2.5 アプリケーションが JDK 1.7 を使用してコンパイルされている場合に発生します。GWT 2.5 は JDK 1.6 をサポートしており、このバージョンの JDK を使用すると、この問題が修正されます。

于 2013-02-19T16:52:06.500 に答える
2

したがって、RPC ファイルはサーブレットによってロードされ、GWT で使用されるため、一意です。http://code.google.com/webtoolkit/release-notes.html#Release_Notes_1_4_59を参照してください。「このファイルは、ServletContext.getResource() 経由で RemoteServiceServlet からアクセス可能なパブリック リソースとして Web サーバーにデプロイする必要があります」

新しいアプリケーションが動的にリロードされ、getResource が何らかの形で失敗している可能性はありますか? アプリケーションを再起動すると問題は解決しますか?

于 2011-03-06T18:11:44.393 に答える
1

同じエラーが発生したため、閲覧キャッシュとナビゲーション履歴を消去してこれを修正しました。

于 2011-05-17T04:46:43.390 に答える
0

SerializationException も取得していましたが、シリアル化例外の直前にこのエラーが表示されていました。

[uptimereports/2.340102563369350884].: 例: エラー: テンプレート登録確認.vm が見つかりません

私の速度テンプレートを見つけるのは問題であることが判明しました。その問題を修正すると、SerializationException が表示されなくなったので、Kerem のアドバイスに従っても問題が解決しない場合は、ログで他の例外を探してください。

于 2010-02-24T22:54:30.500 に答える