1 つの Java EE サーバーにデプロイされている Java EE アプリケーションはほとんどないと仮定します (ベンダーは意味がありません。Glassfish、JBoss、WebLogic などの可能性があります)。各アプリには、展開された .war または .ear に同じライブラリが含まれています (例: log4j.jar)。(はい、サーバーの ext-lib ディレクトリに 1 つの .jar をインストールして、これをすべてのアプリで共有するのが良いことはわかっていますが、この場合、すべてのアプリが log4j.jar の独自のコピーを持っています)。
現在、サーバーはこれらすべてのアプリをデプロイしており、次を実行しています。
1) log4j.jar の 1 つのバージョン (最初にデプロイされる可能性があります)、他のアプリと共有しますか?
2) デプロイされたアプリケーションごとの log4j インスタンスの数 (デプロイされたアプリの数と同じ数の RAM を消費します)?
どの文が正しいですか？
一般的には 2) (以前のバージョンの JBoss は 1) を実行していました。つまり、デフォルトでアプリケーション間でクラスを共有していました) が、ある Web アプリでのライブラリ アクセスが別の Web アプリに影響を与えないことを意味するため、これは一般的には良いことです。特定の例では、アプリごとに異なるログ構成を使用できます。
各アプリケーションには独自のクラスパスがあるため、通常、アプリケーションに含めるすべてのjarはアプリケーションにのみ表示されます。したがって、複数のアプリケーションで同じライブラリを使用すると、同じライブラリのより多くのインスタンスがメモリにロードされます。
この重複を回避し、ライブラリをアプリケーションサーバーの共有フォルダーに保存し、アプリケーションアーカイブに含めないようにするのは、開発者の責任です。
mavenを使用している場合は、依存ライブラリを「提供済み」として宣言して、デプロイメントアーカイブに含めないようにすることができます。
残念ながら、各アプリケーションサーバーには共有jarの独自の構成があります。たとえば、Glassfishはそれらをdomain/lib/extフォルダーに入れたいと考えています。
これは、デプロイするアプリケーションサーバーごとに1つずつ、プロファイルを使用してMavenを構成し、プロファイルごとにライブラリを適切なフォルダーにコピーするプラグインを構成することで管理できます。
私の知る限り、アプリケーション コンテナはアプリケーションごとに異なるクラスローダを使用します。したがって、それはおそらく2番目のオプションです。