2

メソッドがServiceExceptionをスローする可能性のあるRemoteServiceへの通常のRPC呼び出しを行うGWTアプリがあります。

public class ServiceException extends Exception implements java.io.Serializable {
    private static final long serialVersionUID = 1L;
    public ServiceException() {}
    public ServiceException(final Throwable cause) {
        super(cause);
    }
    public ServiceException(final String errorMsg) {
        super(errorMsg);
    }
}

これは、onFailure非同期コールバックで予期される例外メッセージを受け取る開発モードでは完全に正常に機能しますが、アプリをコンパイルしてTomcatにデプロイすると、例外が次のように変換されます。

com.google.gwt.user.client.rpc.StatusCodeException: 500 The call failed on the server; see server log for details

開発モードの場合と同様に、サーバーログには、ServiceExceptionをスローする直前に自分でログに記録した予想される例外理由が表示されます。

私はこれをグーグルで調べましたが、関連するものは何も見つかりませんでした。

（私はGWT 2.4、java 1.6、Tomcat7.0.16を搭載したMacOS X Lionに取り組んでいます）

4

2 に答える 2

0

gwt-rpcサーブレットが例外を適切に処理していないようです。次に、Tomcatコンテナがhttp-500エラーページを送信して例外を処理します。通常、例外はhttp-200応答になり、gwtエンコードされた応答の最後に「EX」が表示されます。開発モードは、ある種の桟橋コンテナで実行されます。開発モードの突堤とTomcatの間には、異なる動作を引き起こすいくつかの違いがあるかもしれません。

理由を見つけるには、gwt-rpcサーブレットコードを調べてください。

ところで：エラーの原因を例外のフィールドに入れるのは悪い考えです。原因がシリアル化可能かどうかはわかりません。

于 2012-05-21T20:47:20.570 に答える
0

愚かな間違い。私はついに、問題が私が使用しているJava難読化ツールの構成の偶発的なタイプミスに起因することを理解しました。そのため、Tomcatで展開していた戦争を構築するときに、クラス名の名前が変更されました。

于 2012-09-18T09:52:28.593 に答える