1 つのメイン Web アプリ コンテキストと多数のマイナー Web アプリ コンテキスト (プラグイン) を持つポータル アプリケーションがあります。現在（非常に単純化されています）メインのものには独自のスプリングライブラリがあり、プラグインもスプリングを使用したい場合はそれらを持っている必要があります. 共通/共有の tomcat コンテキストでは、ドライバーとインターフェースだけがあります。
Spring ライブラリが、Spring が間接的に使用する可能性のある、または spring を使用する可能性がある他のライブラリに関して共通のコンテキストに移動された場合、機能しますか? アプリがspring-txなどを使用しているため、休止状態と同様に、休止状態も共通/共有コンテキストに移動する必要がありますか?
あなたはどう思いますか、他の側面は何ですか？春のアプリケーションコンテキストの観点からは、このようにはるかに簡単になります.
@RichWは、SpringライブラリをTomcatの一般的なクラスローダーに配置することは悪い習慣であると述べているのは正しいです。そして、それが機能しない可能性は十分にあります。
Javaはクラスローダー階層を使用します）。クラスのロードが要求されると、クラスローダーは、独自のクラスパスを使用してクラスをロードしようとする前に、親のクラスローダーからクラスを再帰的に要求します。このプロセスは、ルートクラスローダー（ブートストラップクラスローダーとして知られています）まで続きます。このように、親クラスローダーから参照されるクラスは、階層のさらに下のクラスローダーで参照されるクラスよりも常に優先されます。
このプロセスでは、クラスが子クラスローダーからロードされることはないことに注意することが重要です。したがって、Springに必要なクラスは、asm、log4j、commons-logging、cglib（すべてSpringが依存します）などの共通クラスローダーにロードする必要があります。これにより、多くの問題が発生します。特に、コモンズを含め、共通のクラスパスにログインすることは、世界全体に悪影響を及ぼします。
実際にTomcatを起動できた場合、アプリケーションをリサイクルするときにメモリリークの問題が発生します。Tomcatでは、アプリケーションは従来のガベージコレクションを使用してアンロードされるため、後で再起動されたアプリケーション内のクラスへの参照を保持しているものがある場合、そのアプリケーションはガベージコレクションを取得しません。Springおよびロギングフレームワークは、クラスへの参照を保持するための主要な候補であるため、アプリケーションを数回再起動すると、おそらくOOMエラーが発生します。
これを安全に行う唯一の方法は、本格的なアプリケーションサーバー（JBoss ASなど）の使用を検討し、アプリケーションをEARとしてデプロイすることです。
Tomcat から本格的な Java EE コンテナーに移行できた場合は、 Bundled Optional Classes メカニズムを使用して、すべてをEARとしてパッケージ化するオプションがあります。
次に、共通の JAR を WAR の外に移動し、EAR のトップ レベルに移動します。
はい、私はそれが魅力的であることを知っています。はい、動作します。しかし、アプリ サーバーの共有ライブラリ フォルダーにアプリケーション固有またはフレームワーク固有のライブラリを配置することは、悪い習慣だと考える人もいますが、私も同意します。
私の意見では、Web アプリには独自の依存関係 (アプリ jar、フレームワーク jar など) が含まれている必要があります。フレームワークにも依存関係があり、多くの場合、特定のバージョンの複数の jar が必要になります。これらのバージョンが変更されることもあれば、依存関係が変更されることもあります。時間の経過とともに、その共有ライブラリ フォルダーは jar の流し台になり、おそらく予測できない方法ですべてのアプリに影響を与えます。
共有ライブラリ フォルダー ルートに進むと、初期の利便性がわずかに得られますが、失われるのは選択です。つまり、一度に 1 つの Web アプリにのみ影響を与えるという選択です。jar を Web アプリ内に保持し、他の Web アプリとは適切に分離して保管することをお勧めします。これにより信頼性が向上し、フレームワークのアップグレードが扱いやすくなります。長い目で見れば、あなたはもっと幸せになるでしょう、約束します。