2

まず、最近追加され、OmniFaces 1.6 でリリースされた OmniFaces CDI @ViewScoped を使用しています。アプリで OmniFaces CDI @ViewScoped を使用できることを非常に嬉しく思いますが、質問があります。

(TomEE 1.6 スナップショット) サーバー ログにいくつかの NullPointerException があることに気付きました。また、OmniFaces CDI @ViewScoped でマークされた Bean を使用/参照するページをテストしているときに、NullPointerException も経験しました。NullPointerException は、通常、次のようなことをすると発生します。

(1) CDI @ViewScoped Bean を参照/使用するページを「レンダリング」します。

(2) 「view」に存在する (PrimeFaces) commandButton/Link (以下) をクリックすると、commandButton/Link action="..." が @ViewScoped Bean の破棄を担当します。

<p:commandButton value="Exit Messenger"
                 action="#{messengerBean.exitMessenger()}"
                 ajax="false"/>

と

public String exitMessenger() {
    pageNavigationController.setToBlankPage();
    // to destroy this CDI @ViewScoped bean
    return "index.xhtml";
}

(3) 上記の手順 2 の直後に、自分またはエンドユーザーが「ブラウザーの更新」 (Google Chrome の F5 キー) を実行すると、何らかの理由で、CDI @ViewScoped Bean (上記の手順 1 で参照) が再構築されます。 actionListener=#{viewScopedBean.methodToPrepareStep1View()} または action="#{viewScopedBean.methodToPrepareStep1View()}" は「ブラウザの更新」ボタン/リクエストによって「呼び出されない」ため、Bean は再構築されます...正しく。

(4) したがって、@ViewScoped Bean メンバーは「null」であり、ユーザーが「予期せず」F5 を押すか、「ブラウザーの更新」を行うと、NullPointerException が発生します。

注: 状態保存 = サーバーおよび (HTTP) フィルターは、次の方法でブラウザーに jsf/xhtml ページをキャッシュしないように指示しています (これはずっと前に、ここで stackoverflow.com で BalusC から学びました)。

res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
res.setHeader("Pragma", "no-cache"); // HTTP 1.0.
res.setDateHeader("Expires", 0); // Proxies.

また、次の他の/関連する投稿を読みました。

JSF 2.0 View Scopeの戻るボタンは安全ですか?

ウィザード パターンの JSF 2.0 で使用するスコープは?

ViewScoped は RequestScoped のように機能します - なぜですか?

フォームをクリアするjsf

これは、(2 歳の JSF 開発者として) 私の設計ミスによるものですか?

CDI @ViewScoped Bean を参照するすべての xhtml ページをテストし、上記の手順を繰り返してから、コード内のすべての場所で NullPointerException を処理する必要がありますか?これは「ブラウザーの更新」が原因ですか? これがこれを解決する唯一の方法ですか、それとも CDI @ViewScoped Bean が破棄された後のブラウザの更新によって引き起こされる NullPointerException を処理 (または回避) するためのより推奨される方法はありますか?

アドバイス/確認してください。ありがとう。

編集: (2) 上記の「正しい」説明と、この問題を再現するのに役立つコード。

4

0 に答える 0