問題タブ [session-scope]

JSFセッション管理がどのように機能するかについての疑問

次のようにマネージドBeanを取得しました：

Bean が sessionScoped になったので、JSF は私の「userBO」オブジェクトもセッションに保持しますか? セッターとゲッターの両方を持つ変数は、セッションに保存される可能性が高いと思います。私が間違っている場合は修正してください。または、「userBO」を一時的として宣言して無視する必要がありますか?

一部のユーザー データを保持するセッション スコープ Bean があり、それがセッション スコープのままであることを確認するために単体テストを作成したいと考えています。jUnit でセッションの開始と終了をモックし、セッション スコープ Bean の値を比較したいと考えています。

今のところ、単体テストの次の (ラフ ドラフト) があります。

カスタム コンテキスト ローダーを使用して、セッション スコープを登録します。

単体テスト:

DummyCachedMethods の関連する関数は次のとおりです。

WebUtils.getCurrentUser() は、SecurityContext から現在のプリンシパルを返すだけです。

しかし、これは機能しません。テストは次の行でパスしません。

メソッド呼び出しはキャッシュされるため、James ではなく Johnny を返します。

私のキャッシュ関連のBeanは次のとおりです。

accountSettingsCache はセッション スコープです。新しいセッションを開始して破棄したいと考えています。

DirtiesContext アノテーションのコメントを外せば合格ですが、それは私が望むものではないと思います。

何が欠けていますか？

同様の質問を見ましたが、WebFilterからManagedBeanにアクセスできるため、再投稿ではないと思いますが、奇妙なことに、更新されたプロパティは実際には更新されていません。詳細は次のとおりです。

私はそれを行うフィルターを持っています（Glassfish3.1.2のMojarra2.1.6、WebFilterアノテーションを使用）：

今Faceletで、私はこれを使用していますviewMode：

完全を期すために、ここに部分的なUserInfoViewがあります。

ここで何が起こるかというと、何らかの理由で（JSESSIONIDにリンクされているようです）期待される動作が発生します：
-GETリクエストセットに「vm = 1」がある（UserInfoView setViewModeを呼び出す）viewModeを1
に設定-Faceletは適切な値

次に、Glassfishを再起動し、次のようにします。
-GETリクエストに「vm = 1」を含めると、 viewModeが1に設定されます（UserInfoView setViewModeを呼び出します）
。Faceletは--default **値（つまり0）を取得します。

RESTORE_VIEWフェーズでは、変数がデフォルトにリセットされるのではないかと思いますが、リクエストのライフサイクルを追跡する以外に、この理論をサポートするものはありません...

SessionScopedマネージドBeanの変数をサーブレットフィルターから変更するときに注意すべき点はありますか？私のアプローチに何か問題がありますか？

統計または監視にEJB-@Singleton（javax.ejb.Singleton）を使用する必要がありますか、それとも共通の@ SessionScoped-Beanに統計をキャッシュする方がよいでしょうか？私の質問をクリアするために、ここに2つのシナリオがあります。

シナリオI：

ユーザーはWebセッションを開始し、統計またはデータテーブルを表示するためにデータベースクエリを実行します。これらのクエリは、そのセッション内で実行されます。したがって、10.000ユーザーは10.000の等しいデータベースクエリを作成します。

シナリオII：

ユーザーはWebセッションを開始し、事前に初期化された@Singleton-Beanから統計またはデータテーブルのデータを再試行します。@Singleton（javax.ejb.Singleton）は、Server-Startup（@Startup）の開始時にクエリを実行しました。したがって、10.000ユーザーは1つのキャッシュ（@Singleton）から読み取ることができ、データベースにクエリを実行する必要はありません。私の@Singleton-Beanは、他の誰かがデータを作成/編集/削除した場合に、キャッシュされたデータの更新をトリガーします。

だから私の質問は：

• シナリオIIはシナリオIよりもスケーリングが優れていますか？はい、そうですね。私は正しいですか？
• 他に考慮すべき注意事項や事柄はありますか？
• Stateless-Beansは、@statefulや@Singletonよりもはるかにスケールアウトします。@ Stateless-Beanを使用して、JPA /HibernateCachesなどでクエリをキャッシュすることを検討する必要があります。
• プロキシを使用するには、@ Singleton（javax.ejb.Singleton）の代わりに@ApplicationScoped（javax.enterprise.context）を使用する必要がありますか？それはもっと良いでしょうか？

IceFaces ページで見つかったパターンを使用しようとしています (IceFaces は使用していませんが、PrimeFaces を使用しています)。

この場合、2 つの Bean があります。

ユーザーコントローラー とユーザーモデル

私のUserModelには、 UserVO (別のプログラマーによって作成された)のインスタンスがあります。私のUserControllerにはこれがあります：

ご覧のとおり、UserModelの新しいインスタンスを作成し、から返されたものを設定するとbo.executeLogin()、オブジェクトが返されます。

ユーザーがログインしていることを確認するために、UserModelにプロパティがあります。

私はtemplate.xhtmlを持っています:

loggedIn問題は、それが機能しておらず、プロパティ値を取得していないことです。

私の推測では、この方法でアクセスすると、UserModelの新しいインスタンスを作成しているようなものです。もしそうなら、私のUserController はセッション スコープではなく、UserModelのみであるため、問題です。

編集

このプロパティを使用する代わりに、 UserModelloggedInプロパティが設定されているかどうかを簡単に確認できることはわかっていますが、問題はセッション スコープ Bean に関するものです。スコープ セッションではないため設定されているUserControllerからアクセスできません。 template.xhtml はすべてのページで使用されます。 userVo

コンバーターで問題に直面しています。私の xhtml ファイルには、オブジェクトのリストを含む selectOneMenu があり、managedBean にオブジェクトを設定したいと考えています。

マネージド Bean に @SessionScoped がある場合、マネージド Bean のオブジェクトは満たされますが、マネージド Bean に @ViewScoped がある場合、コンバーターは使用されず、オブジェクトは null です。

この問題を解決するには？

Xhtml :

typConverter :

たくさん送信

さまざまなビューを指すアイテムを含むメニューがあります。

各ビューには、リスナーが接続された選択コンボボックスがあります。

そのビューでは、セッションスコープのマネージドBeanを使用します。

初めてビューに移動すると、Beanの作成時にメソッドが呼び出されます。ユーザーが選択ボックスから値を変更すると、同じメソッドが呼び出されます。ただし、ビューが再表示されたときにメソッドは呼び出されません。

これは、セッションスコープのBeanを使用しているために発生します。より良い解決策は、代わりにビュースコープのBeanを使用することでしたが、私は別の方法を探しています。ビューが変更されたときに特定のコードを実行する方法はありますか？

セッション スコープ Bean の Web アプリ内のユーザーのアクションのコンテキストで保留中の実行リストを保存し、セッションの最後に@Predestroyアノテーション付きメソッドを介してそれらのアクションを確実に実行することは安全ですか (つまり、メソッドが呼び出されないコンテキストでの安全性@predestroy&したがって、何らかの状況でアクションが実行されないなど!?)。

編集: これは壮大な手のひらの状況です。SessionScoped のインポートが正しくありません。昨夜チェック中にとても疲れていたので、面のセッションスコープのインポートをまだ使用している間に、エンタープライズのセッションスコープのインポートを使用していたと確信していました。私は私のような愚か者への援助としてこれを残しておきます. :)

このプロジェクトの初期段階です。マネージド Bean を使用してこの時点まで実装した後、マネージド Bean を CDI Bean に変更しました。これが最善の方法に関する最新のコンセンサスであるように思われるからです。私は一生、理由を理解できません。ヘルプとアドバイスをいただければ幸いです。

ハッピー パス (要約... コードの抜粋の下に詳細)

ユーザーがログインしていない場合は、ログインまたは登録リンクを表示します。
ユーザーがログインしている場合、ユーザー設定またはログアウト リンクを表示します。

CDIを使用したCrappy Path（CDIのせいではありません）

ユーザーがログインしていない場合は、ログインまたは登録リンクを表示します。
ユーザーがログインしている場合でも、ログインまたは登録リンクが表示されます。(悪い、悪いアプリ)

関連するオブジェクトは次のとおりです。

1. ログインしているかどうかにかかわらずレンダリング属性を備えたfaceletメニューパネル（primefacesログインダイアログ付き...これはそれとは何の関係もないと思いますが、完全を期すために含まれています）
2. セッション スコープのユーザー Bean、
3. ユーザーをログインおよびログアウトするためのリクエスト スコープの認証 Bean。

使用したオブジェクトを以下に示します。CDI Bean として実装されます。

フェイスレット

認証 Bean

ユーザー Bean

デバッグモードで見るときの実際の使用例は次のとおりです。

ハッピー パス (CDI Bean に変更する前)

1) ユーザーはようこそページに移動します
。2) ユーザー Bean は、ログインしているかどうかを確認するために照会されます (facelet の user.loggedIn)。
3) userbean はログイン状態をチェックします。彼らがまだゲストである場合、ログインしていません。
4) 彼らはゲストとして識別されるため、isLoggedIn() は false を返します。
5) ログインボタンが表示されます。
6) ユーザーがログインを要求します。
7) 認証 Bean がログイン プロセスを開始します
。request.login が正常に返されます。 8) authenticationbean がユーザー データを設定します。
9) 認証 Bean の loginMethod が返されます (それらはサーバー上で userprincipal に記録されます)

別の (くだらない) パスはここで分岐します (ハッピー パスが続きます)

10) メニューはログイン状態 (user.loggedIn)
を再チェックします 11) userbean は適切な状態をチェックし、有効な非ゲスト ユーザーであることを確認します
12) userbean は (true) を返し、ログインしています
13) メニューはログアウト ボタンを表示します

Crappy Path (これらを CDI Bean に変更した後に何が起こるか)

10) メニューはログイン状態を再チェックします (user.loggedIn)
11) userbean は適切な状態をチェックし、ゲストであることを確認します //更新されたユーザー状態は、このセッションでこのユーザーから消えたようです。
12) userbean が (false) を返します。 //ログインしていませんが、ログインしています。
13) メニューにログイン ボタンが表示されます。 -ユーザー ID が既に存在する間にログインします)。

マネージド Bean を使用すると、ユーザー Bean がセッション スコープでデータを維持しているのを確認できるのに、cdi Bean ではそうでないのはなぜですか? 私は困惑しています。必要に応じて管理対象の Bean に戻します。大きな問題ではありませんが、何を台無しにしたかを調べたいと思います。

UserBean の init メソッドにデバッグ コードを追加したところ、システムが SessionScoped UserBean を RequestScoped であるかのように扱っているように見えます。つまり、すべての呼び出しで初期化されています。

実際に SessionScoped のように動作している場合、userInfo オブジェクトは毎回 null になることはなく、'if' ステートメントは毎回実行されるわけではありません。ただし、UserBean へのすべての呼び出しで実行されています。したがって、これが問題の核心です。実際のところ、セッション スコープ内にあるように動作した場合、初期化されているため、すべての呼び出しで init メソッドにヒットすることはありません。

sessionscoped Bean を適切に作成していませんか? そのように見えますが、方法がわかりません。前述のように、このコードはマネージド Bean として定義されている場合は正常に実行されました。

たくさんのドキュメントとたくさんの異なるビューコントロールを備えたかなり大きなアプリケーションがあります。

処理を高速化し、不要な表示および表示検索要求を回避するために、すでに要求されたドキュメントまたは表示エントリをキャッシュして、ユーザーが同じ要求を再度実行した場合、繰り返しが最初にキャッシュを検索するようにします。

アプリケーションが列の値ではなくドキュメントから値を取得するときに、すべてのビューコレクションに適用できるsessionScopeに要求されたすべてのユニドを格納するジェネリック関数を作成することを考えています。

この種類の関数は、どのリクエストが行われたかを追跡し、ユーザーがさらに行を必要とする場合は非キャッシュコンテンツに戻す必要があると思います。