war-packageと共有ライブラリの依存関係

Question

通常、依存関係はJavaの.war-packagesにバンドルされています。

ただし、デプロイメントを共有ライブラリにドロップして、デプロイされた各アーティファクトに対して同じ依存関係を使用することもできます。

質問：各アプローチのメリットと欠点は何ですか？どのような状況でそれらを使用しますか？

最も必要なのは直観性/保守性です。私は購入するのが安いので、メモリ消費、ディスクスペース使用、帯域幅などについてはあまり気にしません。とにかく

、それぞれにいくつかのポイント：WAR内の依存関係を含め

：（？）

• "事実上の" アプローチ
• は簡単に維持するために、（など以下の構成&スクリプトを、必要とします）
• アプリケーションサーバーへの展開が容易
• 各モジュールはライブラリの特定のバージョンを定義できます
• クラスローディングエラーのリスクを軽減できますか？
  • 削減メモリ消費彼らはクラスパスを共有するよう（ささいな？）
  • WARの展開は、同じインスタンス/変数などにアクセスすることができます：？共有ライブラリを使用して

  実際には本当に悪いと思う？ （実際には同じ方法で動作するのですか、別々のコンテキストで別々のコンテキストで実行されているのでしょうか？）

• 依存関係を別々に維持/展開する必要があるため、配布と展開が難しくなります
• パッケージは小さい
• 依存関係（ささい）サイズアップWARアプリケーションの実際の再展開せずにアップグレードすることができます（実際には、利益の何...）もちろん

、我々は両方のアプローチの最良の側面を使用することができ、ちょうど提供します共通ライブラリを共有ライブラリとして提供し、WAR内にバージョン特化を含めることができます。しかし、これはメンテナンスの労力を倍増させ、ノー・ノーのように感じます。

現在、私はGlassfish 3.1.1を使用していますが、この質問は本当にアプリのサーバーには無関係です。

Answer 1

あなたの操作によって異なります。サーバーにアプリケーションをデプロイし、そのようなサーバーの数が非常に限られている（たとえば、統合、QA、運用）場合は、に依存関係を共有ライブラリに置くことができます。

この戦争を自分のサーバーに展開しなければならない第三者のユーザーに戦争を送るつもりなら、それは非常に面倒です。不十分なユーザーは、必要なすべての依存関係（および依存関係の依存関係）を共有ライブラリにインストールする必要があります。

複数のエンタープライズアプリケーションを実行する必要のあるサーバーまたはサーバー以外のサーバーにアプリケーションをインストールする必要がある場合は、この方法を使用できません。すべての依存関係をwarファイルにパックする必要があります。それ以外の場合、競合は避けられません。

Answer 2

上記のあなたのプロ/コンリストを考えれば、すでにあなたの質問に答えたように見えます。あなたが言うように、メモリ/ディスクは来るのは簡単です。一方、時間は来るのが簡単ではありません。 WEB-INF/libに依存関係を置くことは実証済みで簡単で、他の人やシステムクラスローダーとの奇妙なやりとりを防ぐことができます。壊れていない場合...

Answer 3

各アプリケーションは自己完結しています。つまり、展開されたすべてのアプリケーションのライブラリを一度にアップグレードする必要はありません。クラスパスの衝突は、同じライブラリがコンテナとアプリケーションにある場合にのみ必要です。私はそれをうまく呼び出せず、クラスローディングはさまざまなコンテナで異なる場合があります。

「WARデプロイメント」のさまざまなアプリケーションを意味する場合は、何も共有しないことを想定してください。これらは意図的に分離されています。共有依存関係はディスク上で別々にアップグレードできますが、いつどのように起こるかはコンテナのクラスローダによって異なります。

ですから、アドバイスは：標準的な方法を守り、不要な依存関係のために構築するWARs/JARのみをチェックしてください。