![]() ![]() ![]() ![]() |
以下の節では、共有 J2EE ライブラリとオプション パッケージを使用してアプリケーション間でコンポーネントとクラスを共有する方法について説明します。
9.0 以前の WebLogic Server では、複数のエンタープライズ アプリケーションが J2EE の 1 つまたは複数のモジュールを簡単に共有することはできませんでした。J2EE モジュールを共有するには、モジュールのコピーを複数の EAR にパッケージ化するか、共有モジュールのパスをシステム クラスパスに追加して、共有モジュールのデプロイメント記述子の複製を参照側の各アプリケーションに追加する必要がありました。共有モジュールの更新には、そのモジュールを使用するすべてのエンタープライズ アプリケーションを再コピーして再パッケージ化する必要があったので、モジュールをコピーする方法では、以降のアプリケーションの更新が厄介な作業となりました。システム クラスパスにモジュールを追加する方法も同様で、更新したモジュールを使用するには、WebLogic Server インスタンスを再起動する必要がありました。
WebLogic Server の共有 J2EE ライブラリ機能では、複数のエンタープライズ アプリケーション間で、1 つまたは複数の種類の J2EE モジュールを簡単に共有できます。共有 J2EE ライブラリは、デプロイメントに際して J2EE アプリケーション コンテナに登録される 1 つまたは複数のモジュールです。共有 J2EE ライブラリは以下のいずれかです。
共有 J2EE ライブラリを適切なアーカイブ ファイル (EAR、JAR、または WAR) にパッケージ化することをお勧めします。ただし、開発目的の場合、展開されたアーカイブ ディレクトリとして共有 J2EE ライブラリをデプロイすれば、更新と再デプロイメントの繰り返しを簡単にすることができます。
共有 J2EE ライブラリを登録後、そのライブラリを参照するエンタープライズ アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に必要なライブラリへの参照を受け取り、参照側アプリケーション自体の一部としてパッケージ化されているかのように、ライブラリを構成するモジュールを使用できます。参照側アプリケーションのクラスパスに、ライブラリ クラスが追加され、参照側アプリケーションのデプロイメント記述子は、共有 J2EE ライブラリを構成するモジュールのデプロイメント記述子と (メモリ内で) 結合されます。
このトピックでは、大部分において、エンタープライズ アプリケーションでのみ参照可能な共有 J2EE ライブラリについて説明しています。ただし、別の Web アプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション ライブラリと非常に似ていますが、参照方法が多少異なります。詳細については、「Web アプリケーション共有 J2EE ライブラリの情報」を参照してください。
注意 : | WebLogic Server では、ドメイン ディレクトリの lib サブディレクトリを使用して、WebLogic Server システム クラスパスに 1 つまたは複数の JAR ファイルを追加するという簡単な方法も利用できます。「システム クラスパスへの JAR の追加」を参照してください。 |
WebLogic Server は、「J2EE 1.4 仕様」の節 8.2「Optional Package Support」に記載のとおり、オプション パッケージをサポートしています。バージョニングについては、「Optional Package Versioning」で説明しています。オプション パッケージは、J2EE ライブラリと似た機能を提供しており、これを使用すると複数のアプリケーション間で単一の JAR ファイルを簡単に共有できます。J2EE ライブラリの場合、最初に、関連する JAR ファイルをオプション パッケージとしてデプロイし、WebLogic Server にオプション パッケージを登録する必要があります。パッケージを登録したら、そのマニフェスト ファイルでパッケージを参照する J2EE モジュールをデプロイできます。
オプション パッケージは、どの J2EE モジュール (EAR、JAR、WAR、または RAR アーカイブ) または展開されたアーカイブ ディレクトリからでも参照できる点が J2EE ライブラリとは異なります。J2EE ライブラリは、有効なエンタープライズ アプリケーションからのみ参照できます。
たとえば、複数の Web アプリケーションで必要とされるサード パーティの Web アプリケーション フレームワーク クラスを、単一の JAR ファイル内にパッケージ化およびデプロイし、ドメイン内の複数の Web アプリケーション モジュールから参照することが可能です。この場合、個々の Web アプリケーション モジュールは共有 JAR ファイルを参照する必要があるので、J2EE ライブラリではなくオプション パッケージを使用します (J2EE ライブラリの場合、完全なエンタープライズ アプリケーションのみがライブラリを参照できます)。
注意 : | BEA のドキュメントと WebLogic Server ユーティリティでは、「ライブラリ」という語を J2EE ライブラリとオプション パッケージの両方の意味で使用します。必要な場合にのみオプション パッケージと呼びます。 |
WebLogic Server では、共有 J2EE ライブラリのバージョニングによって、参照側のアプリケーションは、使用するライブラリの最低限のバージョンを指定したり、必要なバージョンを完全一致の形で指定したりできます。WebLogic Server では、共有 J2EE ライブラリのバージョニングを、「Optional Package Versioning」の説明にある 2 種類のレベルでサポートしています。
ベスト プラクティスとして、共有 J2EE ライブラリを作成する際には、バージョン情報 (実装バージョンまたは実装バージョンと仕様バージョンの両方) を必ず含めることをお勧めします。共有コンポーネントの開発時にバージョン情報を作成および更新すると、テスト目的でコンポーネントの複数のバージョンを同時にデプロイできます。バージョン情報を指定しない場合、またはバージョン文字列のインクリメントに失敗した場合は、新しいライブラリをデプロイする前に既存のライブラリをアンデプロイする必要があります。「共有 J2EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
参照側アプリケーションのバージョニング情報によって、そのアプリケーションで必要なライブラリとパッケージのバージョンが決まります。各アプリケーションに応じて、必要となるライブラリまたはパッケージのバージョンが異なる場合があります。たとえば、プロダクション アプリケーションがある特定のバージョンのライブラリを要求することがあります。これはそのライブラリのみがプロダクション用に完全に適しているためです。同じライブラリの最低限のバージョンを常に使用するように内部アプリケーションをコンフィグレーションできます。特定のバージョンを必要としないアプリケーションで、最新バージョンのライブラリを使用するようにコンフィグレーションすることもできます。「エンタープライズ アプリケーションでの共有 J2EE ライブラリの参照」。
オプション パッケージと共有 J2EE ライブラリでは、以下の機能が共通しています。
オプション パッケージは、共有 J2EE ライブラリと以下の点が異なっています。
META-INF/MANIFEST.MF
を使用) が、共有 J2EE ライブラリを参照できるのはエンタープライズ アプリケーションと Web アプリケーションのみである (weblogic-application.xml
または weblogic.xml
を使用)。
通常、1 つまたは複数の EJB、Web アプリケーション、またはエンタープライズ アプリケーションを複数のエンタープライズ アプリケーション間で共有する場合は、共有 J2EE ライブラリを使用します。1 つまたは複数の (JAR ファイルにパッケージ化された) クラスを複数の J2EE モジュール間で共有する場合は、オプション パッケージを使用します。
プレーン JAR ファイルは、ライブラリとしてもオプション パッケージとしても共有できます。以下の場合には、オプション パッケージを使用します。
1 つまたは複数のエンタープライズ アプリケーションから JAR ファイルを参照するだけで、J2EE 仕様に厳密に準拠する必要がない場合は、共有 J2EE ライブラリを使用してプレーン JAR ファイルを共有します。
注意 : | BEA のドキュメントと WebLogic Server ユーティリティでは、「共有 J2EE ライブラリ」という語を J2EE ライブラリとオプション パッケージの両方の意味で使用します。必要な場合にのみオプション パッケージと呼びます。 |
管理者側から見た共有 J2EE ライブラリ、オプション パッケージ、および参照側アプリケーションのデプロイおよび管理の詳細については、『WebLogic Server アプリケーションのデプロイメント』の「共有 J2EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
複数のアプリケーションで共有可能な新しい共有 J2EE ライブラリを作成するには、次の手順に従います。
「共有 J2EE ライブラリ ファイルの作成」を参照してください。
「オプション パッケージ クラス ファイルの作成」を参照してください。
MANIFEST.MF
ファイルを作成および編集して、名前およびバージョン文字列情報を指定します。
「共有 J2EE ライブラリのマニフェスト属性の編集」を参照してください。
「配布およびデプロイメント用共有 J2EE ライブラリのパッケージ化」を参照してください。
以下の種類の J2EE モジュールを共有 J2EE ライブラリとしてデプロイできます。
共有 J2EE ライブラリを、スタンドアロン J2EE モジュールではなく、エンタープライズ アプリケーションとしてパッケージ化することをお勧めします。これは、スタンドアロン モジュールの URI がデプロイメント名から派生しており、モジュールがどのようにデプロイされたかによって変わる可能性があるためです。デフォルトでは、WebLogic Server はデプロイメント アーカイブ ファイル名または展開されたアーカイブ ディレクトリ名をデプロイメント名として使用します。別のファイルまたは場所からスタンドアロン共有 J2EE ライブラリを再デプロイする場合、デプロイメント名と URI も変わり、誤った URI を使用している参照側アプリケーションは、デプロイされたライブラリにアクセスできません。
スタンドアロン J2EE モジュールとして共有 J2EE ライブラリをデプロイする場合は、デプロイメント時に既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前を URI として使用します。
任意のクラスのセットをオプション パッケージ ファイルにまとめることができます。共有クラスのコレクションは、最終的に標準 JAR アーカイブにパッケージ化されます。ただし、JAR のマニフェスト ファイルを編集する必要があるので、最初にすべてのクラス ファイルを作業ディレクトリに作成します。
mkdir /apps/myOptPkg
mkdir -p /apps/myOptPkg/org/myorg/myProduct
cp /build/classes/myOptPkg/org/myOrg/myProduct/*.class /apps/myOptPkg/org/myOrg/myProduct
cd /apps/myOptPkg
jar xvf /build/libraries/myLib.jar
共有 J2EE ライブラリの名前とバージョン情報は、META-INF/MANIFEST.MF
ファイルで指定します。表 8-1 に、有効な共有 J2EE ライブラリ マニフェストの属性を示します。
|
|
マニフェスト ファイルの属性を指定するには、次の手順に従います。
cd /apps/myLibrary
mkdir META-INF
emacs META-INF/MANIFEST.MF
cd /apps/myOptPkg
mkdir META-INF
emacs META-INF/MANIFEST.MF
Extension-Name: myExtension
ライブラリを参照するアプリケーションは、Extension-Name
値に完全一致した共有ファイルを指定する必要があります。
Extension-Name: myExtension
Specification-Version: 2.0
Implementation-Version: 9.0.0
バージョン識別子に対してメジャー/マイナー フォーマットを使用すると、別のアプリケーションからライブラリを参照する際に最も柔軟な指定が可能です (表 8-1 を参照)。
注意 : | デプロイ時に必要に応じてコマンドラインで Specification-Version および Implementation-Version を指定できますが、これらの文字列を MANIFEST.MF ファイルで指定しておくことをお勧めします。マニフェストにバージョン文字列を指定すると、旧バージョンと並行して新しいバージョンのライブラリをデプロイできるようになります。「共有 J2EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。 |
管理者によるデプロイメント用に共有 J2EE ライブラリまたはオプション パッケージを配布する場合、デプロイメント ファイルをアーカイブ ファイル (共有 J2EE ライブラリの場合は .EAR
ファイルまたはスタンドアロン モジュール アーカイブ ファイル、オプション パッケージの場合は単純な .JAR
ファイル) にパッケージ化して配布します。「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。
共有 J2EE ライブラリは標準 J2EE アプリケーションまたはスタンドアロン モジュールとしてパッケージ化されるので、『WebLogic Server アプリケーションのデプロイメント』で説明されているように、ライブラリのデプロイメント コンフィグレーションをデプロイメント プランにエクスポートすることもできます。オプション パッケージ .JAR
ファイルにはデプロイメント記述子が含まれていないので、エクスポートすることはできません。
開発目的で、展開されたアーカイブ ディレクトリとしてライブラリをデプロイすると、更新と再デプロイメントの繰り返しが簡単になります。
J2EE アプリケーションは、アプリケーションの weblogic-application.xml
デプロイメント記述子のエントリを基に、登録された共有 J2EE ライブラリを参照できます。表 8-2 に、ライブラリ参照を定義する XML 要素を示します。
library-name は、ライブラリのマニフェスト ファイルの Extension-Name 属性の値に完全に一致する必要がある。 (表 8-3 を参照)。
|
|
specification-version よりも古い場合、アプリケーションをデプロイすることはできない。下記の exact-match 要素を使用すると、必要なバージョンをさらに絞り込むことができる。
Specification-Version 属性に完全一致する文字列値を持つ共有 J2EE ライブラリが必要になる (表 8-3 を参照)。
|
|
implementation-version よりも古い場合、アプリケーションをデプロイすることはできない。下記の exact-match 要素を使用すると、必要な実装バージョンをさらに絞り込むことができる。
Implementation-Version 属性に完全一致する文字列値を持つ共有 J2EE ライブラリが必要になる (表 8-3 を参照)。
|
|
たとえば、次の weblogic-application.xml
記述子の単純なエントリでは、共有 J2EE ライブラリ myLibrary
を参照します。
<library-ref>
<library-name>myLibrary</library-name>
</library-ref>
上記の例では、WebLogic Server は、依存関係にあるアプリケーションをデプロイする際に myLibrary
というライブラリを探します。myLibrary
のコピーが複数登録されている場合、WebLogic Server は、最新の仕様バージョンのライブラリを選択します。選択した仕様バージョンを複数のライブラリのコピーが使用している場合、WebLogic Server は、最新の実装バージョンのコピーを選択します。
次の例では、仕様バージョンの要件を指定して共有 J2EE ライブラリを参照します。
<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
</library-ref>
上記の例では、WebLogic Server は、仕様バージョン 2.0 以降のライブラリを探します。バージョン 2.0 以降のライブラリが複数ある場合、WebLogic Server は、実装バージョンに Float 値を使用しているライブラリを調べ、最新バージョンを選び出します。WebLogic Server は、実装バージョンに Float 以外の値を使用している選択ライブラリを無視します。
次の例では、仕様バージョンと非 Float 値の実装バージョンの両方を指定して共有 J2EE ライブラリを参照します。
<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
<implementation-version>81Beta</implementation-version>
</library-ref>
上記の例では、WebLogic Server は、仕様バージョンが 2.0 以降で、実装バージョンが 81Beta
に完全一致するライブラリを探します。
次の例では、仕様バージョンと実装バージョンの両方が完全一致しなければならないケースを示します。
<library-ref>
<library-name>myLibrary</library-name>
<specification-version>2.0</specification-version>
<implementation-version>8.1</implementation-version>
<exact-match>true</exact-match>
</library-ref>
スタンドアロン モジュール (EJB または Web アプリケーション) としてデプロイされた共有 J2EE ライブラリの URI を参照する場合、モジュール URI は、共有 J2EE ライブラリのデプロイメント名に対応している必要があります。これは、デプロイメント時に手動で割り当てた名前でも、デプロイされたアーカイブ ファイルの名前でも、デプロイされた展開アーカイブ ディレクトリの名前でも構いません。同じモジュールを異なるファイル名で、または別の場所から再デプロイする場合、デフォルト デプロイメント名も変わるので、適切な URI を使用するように参照側アプリケーションを更新する必要があります。
この問題を避けるには、すべての共有 J2EE ライブラリを、スタンドアロン モジュールではなく、エンタープライズ アプリケーションとしてパッケージ化します。スタンドアロン J2EE モジュールとしてライブラリをデプロイする場合は、既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前を URI として使用します。
J2EE アーカイブ (JAR、WAR、RAR、EAR) は、アーカイブのマニフェスト ファイルの属性を使用して 1 つまたは複数の登録済みオプション パッケージを参照できます。
specification-version 値を指定した場合、アーカイブは、コンフィグレーションした値を下回らない最新の仕様バージョンに一致するパッケージを使用する。使用可能なすべてのパッケージが、コンフィグレーションされた specification-version よりも古い場合、アーカイブをデプロイすることはできない。
Specification-Version 属性に完全一致する文字列値を持つオプション パッケージが必要になる (表 8-1 を参照)。
|
|
implementation-version よりも古い場合、アプリケーションをデプロイすることはできない。
Implementation-Version 属性に完全一致する文字列値を持つオプション パッケージが必要になる (表 8-1 を参照)。
|
たとえば、依存関係のあるアーカイブの場合、マニフェスト ファイルの以下の単純なエントリでは、myAppPkg
および my3rdPartyPkg
という 2 つのオプション パッケージを参照します。
Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg
次の例では、仕様バージョン 2.0 以降の myAppPkg
を要求します。
Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg
internal-Specification-Version: 2.0
次の例では、仕様バージョン 2.0 以降の myAppPkg
、実装バージョンが完全一致する my3rdPartyPkg
を要求します。
Extension-List: internal 3rdparty
internal-Extension-Name: myAppPkg
3rdparty-Extension-Name: my3rdPartyPkg
internal-Specification-Version: 2.0
3rdparty-Implementation-Version: 8.1GA
デフォルトでは、WebLogic Server は、アプリケーションまたはモジュールをデプロイする際にマニフェスト ファイルのオプション パッケージに対する参照を解決できない場合、警告を出力しますが、デプロイメントは続行します。この動作を変更するには、WebLogic Server の起動時に、コマンドラインまたはサーバの起動を制御するコマンド スクリプト ファイルで、システム プロパティ weblogic.application.RequireOptionalPackages
を true
に設定します。このシステム プロパティを true
に設定すると、WebLogic Server は、マニフェスト ファイルのオプション パッケージの参照を解決できない場合にアプリケーションまたはモジュールをデプロイしません。
weblogic.appmerge はライブラリを 1 つのアプリケーションに結合するために使用するツールです (コンテンツと記述子がそれぞれ結合されます)。結合されたアプリケーションをディスクに書き込む機能もあります。その後で weblogic.appmerge を使用し、ディスクに書き込んだ結合されたアプリケーションを調べることで、ライブラリの結合を理解することもできます。
次の構文を使用して weblogic.appmerge を呼び出します。
java weblogic.appmerge [オプション] <ear、jar、war ファイル、またはディレクトリ>
有効なオプションを表 8-4 に示します。
$ java weblogic.appmerge -output CompleteSportsApp.ear -library Weather.war,Calendar.ear SportsApp.ear
Ant タスクではコマンドライン ユーティリティと同様の機能を提供しています。source、output、libraryDir、plan、および verbose の各属性と、複数の <library> 下位要素がサポートされています。次に例を示します。
<taskdef name="appmerge" classname="weblogic.ant.taskdefs.j2ee.AppMergeTask"/>
<appmerge source="SportsApp.ear" output="CompleteSportsApp.ear">
<library file="Weather.war"/>
<library file="Calendar.ear"/>
</appmerge>
BuildXMLGen
には、1 つまたは複数の共有 J2EE ライブラリ ディレクトリを含むビルド ターゲットを生成するための -librarydir
オプションがあります。「weblogic.BuildXMLGen を使用した基本的な build.xml ファイルの生成」を参照してください。
wlcompile
および wlappc
Ant タスクには、アプリケーション ビルドのクラスパスに含める 1 つまたは複数の共有 J2EE ライブラリを指定するための librarydir
属性と library
要素があります。「分割開発ディレクトリでのアプリケーションのビルド」を参照してください。
共有 J2EE ライブラリを 1 つまたは複数の WebLogic Server インスタンスに登録するには、対象サーバにライブラリをデプロイし、デプロイメントが共有されるように指定します。共有 J2EE ライブラリは、ライブラリを参照するアプリケーションのデプロイ先と同じ WebLogic Server インスタンスに登録する必要があります。必要なライブラリを登録していないサーバ インスタンスに参照側アプリケーションをデプロイする場合、参照側アプリケーションのデプロイメントは失敗します。詳細については、『WebLogic Server アプリケーションのデプロイメント』の「WebLogic Server でのライブラリの登録」を参照してください。
Administration Console を使用して共有 J2EE ライブラリをインストール (デプロイ) する場合の詳細な手順については、「J2EE ライブラリのインストール」を参照してください。Administration Console を使用して、ライブラリを参照するアプリケーションのデプロイ先となるサーバまたはクラスタにライブラリをデプロイする場合の手順については、「J2EE ライブラリのサーバまたはクラスタへの割り当て」を参照してください。
繰り返しの開発プロセスの一部として wldeploy
Ant タスクを使用する場合は、library
、libImplVer
、および libSpecVer
属性を使用して共有 J2EE ライブラリをデプロイします。詳細と例については、「wldeploy Ant タスクのリファレンス」を参照してください。
共有 J2EE ライブラリを登録後、そのライブラリと依存関係にあるアプリケーションおよびアーカイブをデプロイできます。依存関係のあるアプリケーションは、対象サーバが必要なライブラリを登録しており、登録されたデプロイメントがアプリケーションまたはアーカイブのバージョン要件に従っている場合にのみデプロイできます。詳細については、『WebLogic Server アプリケーションのデプロイメント』の「ライブラリを参照するアプリケーションのデプロイ」を参照してください。
このトピックでは、大部分において、エンタープライズ アプリケーションでのみ参照可能な共有 J2EE ライブラリについて説明しています。ただし、別の Web アプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション ライブラリと非常に似ていますが、参照方法が多少異なります。
注意 : | 便宜上、この節では、別の Web アプリケーションでのみ参照される共有 J2EE ライブラリのことを指すのに「Web アプリケーション ライブラリ」という用語を使います。 |
weblogic-application.xml
ファイルではなく weblogic.xml
デプロイメント記述子ファイルを更新します。要素は、「エンタープライズ アプリケーションでの共有 J2EE ライブラリの参照」で説明されているものとほぼ同じです。唯一の違いは、<library-ref>
の <context-root>
子要素がここでは無視されることです。weblogic.xml
デプロイメント記述子ファイルから、別の種類の共有 J2EE ライブラリ (EJB、エンタープライズ アプリケーション、プレーン JAR ファイル) を参照することはできません。
こうした参照方法の違いを除けば、Web アプリケーション ライブラリを作成、パッケージ化、デプロイする方法は、通常の共有 J2EE ライブラリの場合と同じです。
標準の共有 J2EE アプリケーションをアプリケーション ライブラリとして WebLogic Server にデプロイできるのと同様に、標準の Web アプリケーションを Web アプリケーション ライブラリとして WebLogic Server にデプロイし、他の Web アプリケーションがこれらのライブラリを参照できるようにすることが可能です。
Web アプリケーション ライブラリを使用するとコードとリソースの再利用が容易になります。また、Web アプリケーションが使用する可能性のあるサードパーティの Web アプリケーションまたはフレームワークを分離するのにも役立ちます。さらに、共通のリソースをライブラリとして個別にパッケージ化し、さまざまな Web アプリケーションで参照されるようにすることもできます。こうすると、そのリソースを各 Web アプリケーションにバンドルする必要がなくなります。Web アプリケーションに Web アプリケーション ライブラリを含める場合、コンテナはデプロイメント時に、すべての静的リソース、クラス、および JAR
ファイルを Web アプリケーションに結合します。
Web アプリケーション ライブラリを使用する最初の手順は、Web アプリケーションを Web アプリケーション ライブラリとして登録することです。それには、Administration Console または
weblogic.Deployer
ツールを使用して Web アプリケーションをライブラリとしてデプロイします。他の Web アプリケーションにこのライブラリを参照させるには、次のように、各アプリケーションの weblogic.xml
ファイルで、Web アプリケーション ライブラリを指す library-ref
要素を指定する必要があります。
<library-ref>
<library-name>BaseWebApp</library-name>
<specification-version>2.0</specification-version>
<implementation-version>8.1beta</implementation-version>
<exact-match>false</exact-match>
</library-ref>
複数のライブラリがある場合、CLASSPATH/resource
パスの優先順位は、weblogic.xml
ファイルで library-ref
要素が出現する順序に従います。
デプロイされた各共有 J2EE ライブラリは、LibraryRuntimeMBean
で表されます。この MBean を使用すると、名前やバージョンなど、ライブラリ自体の情報を取得できます。また、デプロイされたアプリケーションに関連付けられた ApplicationRuntimeMBean
を取得することもできます。ApplicationRuntimeMBean
では、アプリケーションが使用するライブラリにアクセスする際に、次の 2 種類の方法を用いることができます。
詳細については、『WebLogic Server API リファレンス』を参照してください。
エンタープライズ アプリケーションが 1 つまたは複数の共有 J2EE ライブラリを参照し、アプリケーションが WebLogic Server にデプロイされている場合、サーバは、内部で参照側のエンタープライズ アプリケーションの weblogic-application.xml
ファイルの情報を参照されるライブラリのデプロイメント記述子の情報に結合します。これは、次の順序で行われます。
weblogic-application.xml
デプロイメント記述子を読み込みます。weblogic-application.xml
、weblogic.xml
、weblogic-ejb-jar.xml
などになります。 weblogic-application.xml
ファイルを結合します。
記述子ファイルの結合方法の結果、weblogic-application.xml
ファイルで最初に参照される共有 J2EE ライブラリの記述子の要素が、最後にあるものよりも優先されます。エンタープライズ アプリケーションの記述子自体の要素は、ライブラリの記述子のすべての要素よりも優先されます。
たとえば、myApp
というエンタープライズ アプリケーションが、それぞれエンタープライズ アプリケーションとしてパッケージ化されている 2 つの共有 J2EE ライブラリ myLibA
と myLibB
をその順序で参照するとします。myApp
アプリケーションと myLibA
アプリケーションには、myEJB
という EJB モジュール、myLibA
アプリケーションと myLibB
アプリケーションには、myOtherEJB
という EJB モジュールがあります。
さらに、myApp
アプリケーションがデプロイされると、クライアントが myApp
アプリケーションを介して myEJB
モジュールを呼び出すとします。この場合、参照側アプリケーションのモジュールは参照対象アプリケーションのモジュールよりも優先されるので、WebLogic Server は、実際には myLibA
の EJB ではなく myApp
アプリケーションの EJB を呼び出します。クライアントが myOtherEJB
の EJB を呼び出すと、WebLogic Server は myLibA
の EJB を呼び出します。これは、myApp
の weblogic-application.xml
ファイルで最初にライブラリが参照され、同じ名前を持つ myLibB
アプリケーションの EJB よりも優先されるためです。
共有 J2EE ライブラリおよびオプション パッケージを開発する際には、以下のベスト プラクティスに留意してください。
/lib
サブディレクトリを使用します。/lib
サブディレクトリ内のクラスは、サーバの起動時にシステム クラスパスに追加されます。Extension-Name
値を必ず指定します。拡張名を指定しない場合は、ライブラリのデプロイメント名から派生した名前を使用します。デフォルトのデプロイメント名は、アーカイブ デプロイメントと展開されたアーカイブ デプロイメントでは異なります。デプロイメント コマンドで任意の値に設定できます。weblogic-application.xml
デプロイメント記述子の context-root
要素を使用して、ライブラリのコンテキスト ルートをオーバーライドします。
![]() ![]() ![]() |