WARがセッション情報を共有できないのはなぜですか？
別のWARからのセッション情報へのアクセス（同じEAR内であっても）-ここにいくつかありますサンプル： tomcatの異なるアプリケーション間でセッション状態を共有する方法はありますか？ 、 別のWebアプリケーションのセッションにアクセスする 、 異なるWARファイル、共有リソース 、 Tomcat：2つのアプリケーション間でデータを共有する方法 、 TomcatのcrossContext属性は何をしますか？セッション共有を有効にしますか？ など...
私が検索したすべてから、コンテナに応じていくつかの特定の解決策がありますが、それはどういうわけか「仕様に反しています」です。また、Java= EE仕様を調べて、答えを見つけるのに運がありませんでした。
一部の開発者はWebアプリケーション間の結合について話しますが、私はそう思わない傾向があります。結合しない場合、WARを同じEAR内に維持する理由は何ですか？たとえば、EJBはローカルにアクセスできます（同じEAR内の別のEJB JAR内にある場合でも）。
より具体的には、私のWARの1つが認証と承認を処理し、この情報を他のWAR（同じEAR内）と共有したいと考えています。以前は、WARをJARとしてパッケージ化し、それらを単一のWARプロジェクト（WEB-INF/lib）に入れることで、同様の問題を回避することができました。しかし、私はこのソリューションが好きではありません（サーブレットの命名などに多大な労力が必要です）。
そして、最初の（そして最も重要な）質問に答えた解決策はありません：WARがセッション情報を共有できないのはなぜですか？
EARを疑似仮想マシンのように扱う
EARは、通常JARからの共通の構成とライブラリを共有するWARファイルのコレクションです。これにより、相互依存するサービスのコレクションをアプリケーションコンテナ内でより簡単に管理できます。したがって、コンテナにデプロイされたEARは、仮想マシンの単純な形式と考えることができます。
仮想マシン上の1つのプロセスが別のプロセスに影響を与えることができないのと同じように、EARについても同様です。すべてのWARは、内部状態を保護するために分離されています。
スケーリング認証
一般に、Webアプリケーションは、適切にスケーリングするためにステートレスである必要があります。セッションで多くの情報を持つことは、これを防ぐアンチパターンです。これにより、HTTPのステートレスな性質と、カスタマイズされた迅速なユーザーエクスペリエンスを維持する必要性との間に矛盾が生じます。認証は古典的なユースケースであり、エンドユーザーの機能を提供するために多くの認証済みリクエストを必要とするチャットAPIで普及しています。
シングルサインオンとシングルサインオフは、特に水平方向のスケーリングが適切に行われている場合に、正しく機能するように慎重にシグナリングする必要があります（部分的なサインオフを考慮してください）。セッション状態を単に共有することは、ほとんどの場合良い解決策ではありません。より良いアプローチは、クラスター内のすべてのノードがアクセスできるユーザー情報に単一の参照ポイントを使用することです。
関連情報への高速キャッシュアクセスに集中すると、複雑で壊れやすいセッション共有ソリューションよりもはるかにスケーラブルな結果が得られます。
これは、JEE EAR仕様（EAR内にバインドされた複数のWebアーカイブ間でWebセッションを共有する機能）の機能が欠けていると私が思うものです。
Weblogicなどのアプリサーバーには、この機能の非std実装があります。
まあ、AFAIKS、あなたがこれをしたい本当の理由はありません。 WARは自己完結型のWebアプリケーションであり、独自の（Webアプリケーション固有の）スコープ（セッションスコープなど）を備えています。機能（Javaコード、JSPページ、CSSファイル）を共有する必要がある場合、複数のWAR間でそれらをJARファイルとしてパッケージ化し、アプリケーションサーバーにデプロイするというはるかに賢明なオプションがあります。 WARパッケージは、より複雑なパッケージソリューションであり、単純な「共通コード/機能」とは異なるものをカプセル化するように設計されています。 JARはより単純な形式であり、コードと機能をパッケージ化して共有するために設計されています。より単純でより適したパッケージ形式がすでに利用可能であるのに、より複雑で、特別に設計されたものではないパッケージを使用して何かを共有したいのはなぜですか？ JSTLタグ、Struts JQueryプラグイン、Springセキュリティを考えてみてください。これらはすべてJARとして提供されます。
これは、異なるWebアプリが誤ってお互いのセッション情報を上書きしないようにするために、意図的に行われたと思います。あなたのケースでは便利かもしれませんが、一般的に、ユーザーが2つのWebアプリを同時に使用しているという理由だけで、ユーザーにアプリをクラッシュさせたり、権限を昇格させたりすることは望ましくありません。 Webアプリ間で明示的に情報を共有することはそれほど難しくありません。静的HashMapでクラスを作成し、キーとしてGUIDを使用して、URLまたはHTTPパラメータの一部としてそれらを転送します。