私はこの問題の回避策をかなり長い間探していましたが、結果が得られなかったので、ここで質問します。
簡単に言うと、プロジェクトでCDI SessionScoped Beanを使用して、Userユーザー情報を管理し、jsfページに表示しています。また、コンテナ管理j_security_checkは認証の問題を解決するために使用されます。
session.invalidate()最初にログアウトしてから、別のユーザーで同じブラウザタブにログインすれば、すべて問題ありません。しかし、login.jsf事前にログアウトせずに新しいユーザーで直接ログイン（を介して）しようとすると、ユーザー情報が変更されていないことがわかりました。
デバッグしたところ、同じブラウザで別のユーザーにログインしても、呼び出されない限り、 UserBeanとインスタンスは常に同じままであることがわかりました。しかし奇妙なことに、セッションIDが変更され、JavaコードとFirebugの両方をチェックインしました。HttpSessionsession.invalidate()
org.apache.catalina.session.StandardSessionFacade@5d7b4092
StandardSession[c69a71d19f369d08b5dddbea2ef0]
attrName = org.jboss.weld.context.conversation.ConversationIdGenerator : attrValue=org.jboss.weld.context.conversation.ConversationIdGenerator@583c9dd8
attrName = org.jboss.weld.context.ConversationContext.conversations : attrValue = {}
attrName = org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-Discipline-ManagedBean-class com.netease.qa.discipline.profile.User : attrValue = Bean: Managed Bean [class com.netease.qa.discipline.profile.User] with qualifiers [@Any @Default @Named]; Instance: com.netease.qa.discipline.profile.User@c497c7c; CreationalContext: org.jboss.weld.context.CreationalContextImpl@739efd29
attrName = javax.faces.request.charset : attrValue = UTF-8
org.apache.catalina.session.StandardSessionFacade@5d7b4092
StandardSession[c6ab4b0c51ee0a649ef696faef75]
attrName = org.jboss.weld.context.conversation.ConversationIdGenerator : attrValue = org.jboss.weld.context.conversation.ConversationIdGenerator@583c9dd8
attrName = com.sun.faces.renderkit.ServerSideStateHelper.LogicalViewMap : attrValue = {-4968076393130137442={-7694826198761889564=[Ljava.lang.Object;@43ff5d6c}}
attrName = org.jboss.weld.context.ConversationContext.conversations : attrValue = {}
attrName = org.jboss.weld.context.http.HttpSessionContext#org.jboss.weld.bean-Discipline-ManagedBean-class com.netease.qa.discipline.profile.User : attrValue = Bean: Managed Bean [class com.netease.qa.discipline.profile.User] with qualifiers [@Any @Default @Named]; Instance: com.netease.qa.discipline.profile.User@c497c7c; CreationalContext: org.jboss.weld.context.CreationalContextImpl@739efd29
attrName = javax.faces.request.charset : attrValue = UTF-8
上記のブロックには、2つの連続したログインとそのSession情報が含まれています。インスタンス（1行目）は同じですが、セッションID（2行目）は異なります。セッションオブジェクトは異なるセッションIDを含むために再利用され、CDIフレームワークはセッションオブジェクトのみ（？）に従ってセッションBeanのライフサイクルを管理しているようです。
無効にしない限り、同じブラウザ内にサーバー側のセッションオブジェクトが1つしかないのではないかと思います。
私はそれを採用しているのでj_security_check、それを傍受して古いセッションを無効にするのはそれほど簡単ではありません。それで、同じブラウザ内の同じまたは異なるタブで異なるアカウントで再ログインできるCDI + JSF + j_security_checkの設計を変更せずに、目標を達成することは可能ですか？
ご返信を心よりお待ちしております。
詳細：Glassfishv3.1は私のappserverです。