ユーザ情報とかの保持方法

Webアプリだとログインした後、そのユーザ情報をセッションとかに保持しておきますよね。
で、JSFを使ってちょっとサンプルをつくってるときにそれをどうやって実現しようかなー考えてたわけです。

  • A) 直接HttpSessionに登録して、自力でハンドリング。
  • B) faces-config.xmlでsessionスコープのmanaged beanとして登録して、JSFまかせ。
  • C) diconファイルでsessionスコープのコンポーネントとして登録して、S2まかせ。

のどれか?

一瞬、特定のフレームワークに依存するってのもどうよ、とか思ったりしたけど、(A)だと後でそのオブジェクトにアクセスするために、自力でThreadLocal系の仕組みを実装したりしなきゃいけなさそうで、ちょっと面倒。というかJSFとかS2でカバーしているのにわざわざ自分で実装っていまどきどうよ?と。

全体をシンプルに保つためだったら別にある時点で特定のフレームワークに依存してしまってもいいじゃないの?と開き直ってみたり。いや、やっぱりと迷ってみたり。

そんなとき、例のsession-nullエラーの解析してるときに見つけたMLの記事で、

S2.1 以降では,例えばログイン情報をセッションで保持したい場合にはアプリケーションで HttpSession#setAttribute() するのではなく,かわりにログイン情報のクラスを instance="session" で diocn ファイルに記述します.
それだけで,コンテナがログイン情報をセッションに設定してくれます.
エラー - Seasar - SourceForge.JP

というのがあった。
あぁ、もうやっぱそういう方法でふつーにやるんですよね?そうですよね?


ってことで、その方向で。


目下の残る悩みは↓。

  • この場合のユーザ情報って、エンティティ?DTO
  • 業務ロジックでこのユーザ情報をDIしてもろうのはアリ?DAOではアリ?


追記:
素のJSFなら(B)、S2JSFなら(C)かと思ったけど、前者でちょっと問題が。
試してみるとservlet-filter中ではFacesContext.getCurrentContext()がnullになるようだ。
このため、ユーザ情報をJSFに管理してもらっていると、filterでの認証状態チェックができなくなってしまう。
素のJSFの場合でもfilterでチェックしたいなら、(A)(C)のどちらかでやらないといけないみたい。
なんか方法を見落としているだけかも。