WebLogic サーバーで作成する多くの Spring Web アプリケーションがあり、いつ WAR を EAR に入れ、いつ WAR として存在させるべきかについて興味があります。ときどき、WAR は共通ロジック JAR にアクセスする必要がありますが、WAR にパッケージ化できるのに、これらを EAR に入れる必要がある理由がわかりません。
私の理解では、EAR に複数の WAR があり、それらの WAR の 1 つを変更する必要がある場合は、EAR 全体を再デプロイしてサーバーを更新する必要があります。これにより、すべての WAR が跳ね返ります。ただし、それらが EAR に含まれていない場合は、1 つの WAR を更新するだけで、バウンスするのは 1 つだけになります。
100 個の異なる WAR ファイルを単独で使用し、パッケージ化された JAR と共有ライブラリ (WebLogic を使用) を使用することの何が問題になっていますか?
洞察をありがとう！
WAR ファイルしかない場合、EAR の有用性は限られており、WAR のデプロイメント コンテナーとしてのみ機能します。このように WAR 間で JAR を共有することにより、多少の膨張を抑えることができますが、それ自体はそれほど魅力的ではありません。
ただし、EAR は、WAR、EJB、JMS、JCA リソースなどを使用する完全な JavaEE/J2EE アプリケーションを扱う場合に不可欠です。これらの種類のアプリケーションのコンポーネント間の相互作用と依存関係は、EAR で管理する方がはるかに簡単です。
しかし、Weblogic を使用しているのは WAR コンテナーだけである場合は、Tomcat や Jetty などのバニラ サーブレット コンテナーを使用して、Weblogic から得られるすべての機能を使用することもできます。
私は、ほとんどすべてのスキャフマンの (通常は) スポット コメントに同意します。
EJB なしで Spring を使用している場合は、もちろん WAR ファイルを使用できます。私が見ることができるEARは必要ありません。
ただし、Spring アプリがメッセージ駆動型 POJO を使用している場合、JMS を利用するために、WebLogic のどこに WAR ファイルをデプロイするかがわかります。
EJB または JCA を使用している場合は EAR が必要かもしれませんが、JMS が EAR を義務付けているとは言いません。JMS を使用し、WAR ファイルを WebLogic にデプロイしましたが、問題なく動作しました。
Tomcat を使用してそこに WAR をデプロイすることにした場合でも、ActiveMQ を使用すれば JMS 機能を維持できます。
複数の WAR を EAR にパッケージ化するという議論は、私の最後の雇用主が行ったような状況に遭遇した場合、説得力のあるものになる可能性があります。この場合、複数の WAR で使用されるライブラリ JAR の共通セットがあり、その JAR のコレクションのサイズがかなり大きくなります。 . この特定の状況では、共通の JAR が各 WAR にパッケージ化された 3 つの WAR の合計サイズは、合計 124MB でした。含まれている EAR に JAR を配置し、それらの JAR を使用するように各 WAR のクラスパスを構成することで、3 つの WAR を含む EAR のフットプリントが 40MB に削減されました。決定的な理由だと思います。
JAR (または JAR のセット) はいつでも "ライブラリ" として weblogic にデプロイできるため、複数の共有ライブラリを使用することは EAR を選択する説得力のある理由にはなりません。したがって、すべての WAR で共有できます。そうでしょ？