4

私は omniFaces の AjaxExceptionHandler を試し (これは非常に役に立ちます)、java.lang.Throwableすべての種類の要求 (ajax 要求だけでなく) から発生する例外をキャッチして例外を設定するように構成しました。

javax.el.PropertyNotFoundExceptionうまく機能しますが、開発者が EL 式のスペルを間違えた場合はキャッチしません。

質問は次のとおりです。JSF2のメカニズムでどのように処理javax.el.PropertyNotFoundExceptionするのですか?ExceptionHandlerFactory

4

1 に答える 1

2

はFullAjaxExceptionHandlerそれを処理できるはずです。具体的な問題は、Facelets のデフォルトのバッファ サイズである 2KB をオーバーフローした比較的大きなページがあり、例外がスローされた時点で応答が既にコミットされているために発生する可能性があります。レスポンスがコミットされると、レスポンスの一部はすでにクライアント側に送信されています。すでに送信されたバイトを取り戻して、エラー ページで新しい応答を提示する方法はありません。ajax を使用しない場合も、まったく同じ問題が発生します。代わりに例外がログに記録され、クライアントは中途半端なページでスタックします。

デフォルトの応答バッファ サイズを、最大の HTML 応答のサイズに合わせて増やすことができます。このようにして、最初のバイトがクライアント側に送信される前に、応答が生成され、サーバーのメモリに完全にバッファリングされます。値としてバイト単位のバッファーサイズを使用して、javax.faces.FACELETS_BUFFER_SIZEコンテキストパラメーターで設定できます。web.xml次の例では、64KB に設定しています。

<context-param>
    <param-name>javax.faces.FACELETS_BUFFER_SIZE</param-name>
    <param-value>65535</param-value>    
</context-param>

これを開発/テスト環境でのみ設定して、ビュー側の間違いを見つけ、ライブ環境でデフォルトのバッファ サイズを使用し続けてサーバー メモリを節約できるようにすることをお勧めします。

于 2012-05-08T20:44:58.000 に答える