JSFの@SessionScopedの生存期間について

Question

JSFで@ManagedBeanを使用しています。
認証情報を@SessionScopedの定義のクラスに保持させようと思っています。
ログイン画面のIDとパスワードをその@SessionScopedの定義のクラスの項目として、
ログインボタンは@ViewScopedの定義のクラスにしています。

ログイン処理の後にメニュー画面に遷移するようにしていますが、
その時に@SessionScopedの定義クラスの@PreDestroyが動いているようで、
メニュー画面で@SessionScopedの定義クラスに保持している値がnullになってしまっています。

私の認識では@SessionScopedで定義されたクラスはそのセッション内であれば生存しているものだと思っていたのですが、
そうではないのでしょうか？

尚、ログインからメニューに遷移する際は、「"/menu.xhtml?faces-redirect=true"」としています。

Answer 1

CDIを使用した経験しか有りませんので、思い当たる点について回答いたします。
@SessionScopedで宣言したBeanはSessionと同期して保持されるというご理解は正しいと思います。
ログインページをSessionScoped以外のscopeで持つというのも問題ないです。
@SessionScopedのページに遷移した契機で@PreDestroyが呼ばれてしまうというのは明らかにおかしいです。invalidateメソッドなどで動的に破棄しないかぎりあり得ないと思われます。また、URLの記述ミスでもあり得ないと思われます。ついては以下の観点で調査されては如何でしょうか。

• PreDestroyが確かに呼ばれているかトレース出力を仕込んで確認する
• APPサーバログに関連するエラーが出ていないか確認する。ページアクセス、APPサーバ起動、デプロイのタイミング周りでエラーが出ていないか

BackingBeanはProxyクラスでインスタンス化されるので、コンパイルでエラーが無くてもインスタンス化の契機でエラーが発生する場合が有ります。その場合、原因はAPPサーバログで判る場合が有ります。

[2/23追記]
SessionScopedのBeanは、同Beanを使用しているJSFページがアクセスされた契機でインスタンス化（Proxy経由なので活性化という表現が正確かもしれません）されます。
LoginページではSessionScopedのBeanメソッドを呼ばず、遷移さきのMenuページでSessionScopedのBeanメソッドを使用しているとすればinvalidateSessionの契機でPreDestoryが呼ばれるのは正しい動作です。

Comments

[yoshi7]

ログイン処理ということで、一旦セッションを破棄した方がよいと思い、
invalidateSession()を実行しています。それがいけないのでしょうか？

[BlueMoon]

PreDestoryが呼ばれる理由になるかと思います。回答に追記しました。
SessionScopedにPostConstructのメソッドを追記してみてトレース出力してみれば、SessionScopedのBeanの生成タイミングが把握できると思うので、確かめられてみてはどうでしょうか。

[BlueMoon]

想像で失礼ですが、もしloginの契機で以前のセッションが残した情報を初期化したいというのであれば、ViewScopedのBeanでlogin成功後にSessionScopedの情報を初期化するロジックを入れてはどうでしょうか。SessionScopedのBeanをInjectすれば可能かと思います。