私は 4 つの異なるプロジェクトを持っており、Weblogic を使用してプロジェクトを展開しています。すべてのプロジェクトに共通のライブラリ (jar ファイル) がいくつかあります。現在、私の各プロジェクトにはlibディレクトリがあり、ほぼ同じライブラリ セットがあります。さて、この lib ディレクトリを WAR ファイルの外に置いて、それらにアクセスすることは可能ですか。
7 に答える
jarファイルをコンテナーの「共有」フォルダーに入れようとする誘惑に抵抗してください。jarファイルを現在の場所に保持することをお勧めします。今すぐ共有フォルダーを使用するのは良い考えに聞こえるかもしれませんが、将来的には、共有ライブラリを必要とするがバージョンが異なるアプリケーションをデプロイする必要があるかもしれません。
そうは言っても、私はWebLogicの経験がありません。Tomcatには、デプロイされたすべてのアプリケーションに共通のライブラリを含む共有フォルダがあります。これを使用するのは良い考えではありません。アプリケーションのセットごとに(デプロイされたすべてのアプリケーションではなく)共有フォルダを使用するようにWebLogicを構成できる場合は、それを使用できます。
これを実行しますか?あなたが展開スペースで立ち往生していない限り、私は(おそらく)それに反対することをお勧めします。
なんで ?現在、これらのライブラリから実行されている4つのソリューションがあります。ライブラリの1つをアップグレードする必要がある場合(たとえば、バグを発見した場合、または新しい機能が必要な場合)、4つのソリューションすべての互換性と機能をテストする必要があります。各ソリューションに独自のライブラリのセットがある場合、それらはサンドボックス化されており、4つすべてを段階的に移動する必要はありません。
これはすべて、ソリューションの回帰テストがいかに簡単であるかにかかっていることに注意してください。簡単だと思うかもしれませんが、その場合は同じライブラリのセットを使用することが可能です。
そうしないでください。
WARファイルの全体的な考え方は、それらが自己完結型のユニットであるということです。これにより、展開が非常に簡単になります。
他の人が指摘している可能性のあるバージョンの競合に加えて、jarファイルを/ sharedに配置すると、クラスの可視性に非常にネストされた結果が生じる可能性があります。それらは別のクラスローダー上にあり、WARファイル内のクラスを表示できません。Class.forName()に依存するライブラリを使用して機能する場合(そしてたくさんあります)、これは非常に苦痛になる可能性があります。
もしあなたが本当に、OSGiやSpring DMを見て、余分なディスクスペースとメモリを買う余裕がないのなら。彼らはこの問題を解決しましたが、複雑さが増すという代償を払っています。
すべての共有 jar ファイルを weblogic の common\lib フォルダーに配置します。common\lib は、デプロイされたすべてのアプリからアクセスできます。
まず第一に、すべてのライブラリを同じ場所に置き、ビルド プロセスで必要なものをインポートすることができます。
新しい Weblogic 10 のデプロイでは、共有ライブラリを配置できる各ドメインに lib フォルダーがあります。Weblogic 10より前にそれが可能だとは思わない
jar を独自の ear ファイルに入れて、共有ライブラリとしてデプロイできます。
wars を耳に入れて、共有 jar を APP-INF/lib に追加することもできます。これは J2EE の Weblogic 拡張であるため、他のサーバーでは動作しません。
私は現在、別のアプローチを使用しています。
- 中央リポジトリ フォルダーを作成し、すべての共通ライブラリをそこに配置します。
- 各プロジェクトで、必要なすべてのライブラリへの参照を作成できます。Subversion では、外部で動作します
ローカルの作業コピーが更新されるたびに、外部ファイルが更新されるため、中央のフォルダーにコミットするだけで、すべてのプロジェクトに自動的に配布されます。