|
|
以下の節では、共有 Java EE ライブラリとオプション パッケージを使用してアプリケーション間でコンポーネントとクラスを共有する方法について説明します。
WebLogic Server の共有 Java EE ライブラリ機能では、複数のエンタープライズ アプリケーション間で、1 つまたは複数の種類の Java EE モジュールを簡単に共有できます。共有 Java EE ライブラリは、デプロイメントに際して Java EE アプリケーション コンテナに登録される 1 つまたは複数のモジュールです。共有 Java EE ライブラリは以下のいずれかです。
共有 Java EE ライブラリを適切なアーカイブ ファイル (EAR、JAR、または WAR) にパッケージ化することをお勧めします。ただし、開発目的の場合、展開されたアーカイブ ディレクトリとして共有 Java EE ライブラリをデプロイすれば、更新と再デプロイメントの繰り返しを簡単にすることができます。
共有 Java EE ライブラリを登録後、そのライブラリを参照するエンタープライズ アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に必要なライブラリへの参照を受け取り、参照側アプリケーション自体の一部としてパッケージ化されているかのように、ライブラリを構成するモジュールを使用できます。参照側アプリケーションのクラスパスにライブラリ クラスが追加され、参照側アプリケーションのデプロイメント記述子は、共有 Java EE ライブラリを構成するモジュールのデプロイメント記述子と (メモリ内で) 結合されます。
このトピックでは、大部分において、エンタープライズ アプリケーションでのみ参照可能な共有 Java EE ライブラリについて説明しています。ただし、別の Web アプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション ライブラリと非常に似ていますが、参照方法が多少異なります。詳細については、「Web アプリケーション共有 Java EE ライブラリの情報」を参照してください。
| 注意 : | WebLogic Server では、ドメイン ディレクトリの lib サブディレクトリを使用して、WebLogic Server システム クラスパスに 1 つまたは複数の JAR ファイルを追加するという簡単な方法も利用できます。「システム クラスパスへの JAR の追加」を参照してください。 |
WebLogic Server は、Java EE 5.0 仕様の節 8.2「Optional Package Support」に記載のとおり、オプション パッケージをサポートしています。バージョニングについては、「Optional Package Versioning」で説明しています。オプション パッケージは、Java EE ライブラリと似た機能を提供しており、これを使用すると複数のアプリケーション間で単一の JAR ファイルを簡単に共有できます。Java EE ライブラリの場合、最初に、関連する JAR ファイルをオプション パッケージとしてデプロイし、WebLogic Server にオプション パッケージを登録する必要があります。パッケージを登録したら、そのマニフェスト ファイルでパッケージを参照する Java EE モジュールをデプロイできます。
オプション パッケージは、weblogic.BuildXMLGen で Java EE 共有ライブラリとしてもサポートされます。そのため、オプション パッケージ参照の検索では、アプリケーションおよびそのモジュールのすべてのマニフェストがスキャンされます。オプション パッケージ参照が見つかると、生成された build.xml ファイル内の wlcompile および appc タスクに追加されます。
オプション パッケージは、どの Java EE モジュール (EAR、JAR、WAR、または RAR アーカイブ) または展開されたアーカイブ ディレクトリからでも参照できる点が Java EE ライブラリとは異なります。Java EE ライブラリは、有効なエンタープライズ アプリケーションからのみ参照できます。
たとえば、複数の Web アプリケーションで必要とされるサード パーティの Web アプリケーション フレームワーク クラスを、単一の JAR ファイル内にパッケージ化およびデプロイし、ドメイン内の複数の Web アプリケーション モジュールから参照することが可能です。この場合、個々の Web アプリケーション モジュールは共有 JAR ファイルを参照する必要があるので、Java EE ライブラリではなくオプション パッケージを使用します (Java EE ライブラリの場合、完全なエンタープライズ アプリケーションのみがライブラリを参照できます)。
| 注意 : | Oracle のドキュメントと WebLogic Server ユーティリティでは、「ライブラリ」という語を Java EE ライブラリとオプション パッケージの両方の意味で使用します。必要な場合にのみオプション パッケージと呼びます。 |
Java EE プラットフォームには、アプリケーションでオプション パッケージや共有ライブラリを使用するためのいくつかのメカニズムが用意されています。ライブラリはアプリケーションにバンドルすることもできますし、アプリケーションで使用するために個別にインストールすることもできます。EAR ファイルには、JAR ファイルにパッケージ化されたライブラリを格納するディレクトリを含めることができます。このディレクトリの名前は、EAR ファイルのデプロイメント記述子の library-directory 要素内に指定されます。library-directory が指定されていない場合、または EAR ファイルにデプロイメント記述子が含まれていない場合は、lib というディレクトリが使用されます。ライブラリ ディレクトリが存在しないことを指定するには、空の library-directory 要素を使用します。このディレクトリ (サブディレクトリは除く) 内にある、拡張子 .jar が付いたファイルはすべて、アプリケーション クライアントを含む EAR ファイル内にパッケージ化されているすべてのコンポーネントで利用可能とする必要があります。これらのライブラリは、アプリケーションにバンドルされている他のライブラリ、または別個にインストールされている他のライブラリを参照できます。
この機能は、WebLogic Server でサポートされている APP-INF/lib 機能に似ています。APP-INF/lib と library-directory が両方とも存在する場合は、library-directory 内の jar が優先されます。つまり、これらのファイルが、クラスパス内の APP-INF/lib jar ファイルよりも前に置かれます。APP-INF/lib の詳細については、「モジュールおよびアプリケーション間のクラス参照の解決」および「分割開発ディレクトリでの共有クラスの配置」を参照してください。
WebLogic Server では、共有 Java EE ライブラリのバージョニングによって、参照側のアプリケーションは、使用するライブラリの最低限のバージョンを指定したり、必要なバージョンを完全一致の形で指定したりできます。WebLogic Server では、共有 Java EE ライブラリのバージョニングを、「Optional Package Versioning」の説明にある 2 種類のレベルでサポートしています。
ベスト プラクティスとして、共有 Java EE ライブラリを作成する際には、バージョン情報 (実装バージョンまたは実装バージョンと仕様バージョンの両方) を必ず含めることをお勧めします。共有コンポーネントの開発時にバージョン情報を作成および更新すると、テスト目的でコンポーネントの複数のバージョンを同時にデプロイできます。バージョン情報を指定しない場合、またはバージョン文字列のインクリメントに失敗した場合は、新しいライブラリをデプロイする前に既存のライブラリをアンデプロイする必要があります。「共有 Java EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
参照側アプリケーションのバージョニング情報によって、そのアプリケーションで必要なライブラリとパッケージのバージョンが決まります。各アプリケーションに応じて、必要となるライブラリまたはパッケージのバージョンが異なる場合があります。たとえば、プロダクション アプリケーションがある特定のバージョンのライブラリを要求することがあります。これはそのライブラリのみがプロダクション用に完全に適しているためです。同じライブラリの最低限のバージョンを常に使用するように内部アプリケーションをコンフィグレーションできます。特定のバージョンを必要としないアプリケーションで、最新バージョンのライブラリを使用するようにコンフィグレーションすることもできます。「エンタープライズ アプリケーションでの共有 Java EE ライブラリの参照」を参照してください。
オプション パッケージと共有 Java EE ライブラリでは、以下の機能が共通しています。
オプション パッケージは、共有 Java EE ライブラリと以下の点が異なっています。
META-INF/MANIFEST.MF を使用) が、共有 Java EE ライブラリを参照できるのはエンタープライズ アプリケーションと Web アプリケーションのみである (weblogic-application.xml または weblogic.xml を使用)。
通常、1 つまたは複数の EJB、Web アプリケーション、またはエンタープライズ アプリケーションを複数のエンタープライズ アプリケーション間で共有する場合は、共有 Java EE ライブラリを使用します。1 つまたは複数の (JAR ファイルにパッケージ化された) クラスを複数の Java EE モジュール間で共有する場合は、オプション パッケージを使用します。
プレーン JAR ファイルは、ライブラリとしてもオプション パッケージとしても共有できます。以下の場合には、オプション パッケージを使用します。
1 つまたは複数のエンタープライズ アプリケーションから JAR ファイルを参照するだけで、Java EE 仕様に厳密に準拠する必要がない場合は、共有 Java EE ライブラリを使用してプレーン JAR ファイルを共有します。
| 注意 : | Oracle のドキュメントと WebLogic Server ユーティリティでは、「共有 Java EE ライブラリ」という語をライブラリとオプション パッケージの両方の意味で使用します。必要な場合にのみオプション パッケージと呼びます。 |
管理者側から見た共有 Java EE ライブラリ、オプション パッケージ、および参照側アプリケーションのデプロイおよび管理の詳細については、『WebLogic Server アプリケーションのデプロイメント』の「共有 Java EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
複数のアプリケーションで共有可能な新しい共有 Java EE ライブラリを作成するには、次の手順に従います。
「共有 Java EE ライブラリ ファイルの作成」を参照してください。
「オプション パッケージ クラス ファイルの作成」を参照してください。
MANIFEST.MF ファイルを作成および編集して、名前およびバージョン文字列情報を指定します。
「共有 Java EE ライブラリのマニフェスト属性の編集」を参照してください。
「配布およびデプロイメント用共有 Java EE ライブラリのパッケージ化」を参照してください。
以下の種類の Java EE モジュールを共有 Java EE ライブラリとしてデプロイできます。
共有 Java EE ライブラリを、スタンドアロン Java EE モジュールではなく、エンタープライズ アプリケーションとしてパッケージ化することをお勧めします。これは、スタンドアロン モジュールの URI がデプロイメント名から派生しており、モジュールがどのようにデプロイされたかによって変わる可能性があるためです。デフォルトでは、WebLogic Server はデプロイメント アーカイブ ファイル名または展開されたアーカイブ ディレクトリ名をデプロイメント名として使用します。別のファイルまたは場所からスタンドアロン共有 Java EE ライブラリを再デプロイする場合、デプロイメント名と URI も変わり、誤った URI を使用している参照側アプリケーションは、デプロイされたライブラリにアクセスできません。
スタンドアロン Java EE モジュールとして共有 Java EE ライブラリをデプロイする場合は、デプロイメント時に既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前を 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
共有 Java EE ライブラリの名前とバージョン情報は、META-INF/MANIFEST.MF ファイルで指定します。表 9-1 では、有効な共有 Java EE ライブラリ マニフェストの属性を示します。
|
|
マニフェスト ファイルの属性を指定するには、次の手順に従います。
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
バージョン識別子に対してメジャー/マイナー フォーマットを使用すると、別のアプリケーションからライブラリを参照する際に最も柔軟な指定が可能です (表 9-1 を参照)。
| 注意 : | デプロイ時に必要に応じてコマンドラインで Specification-Version および Implementation-Version を指定できますが、これらの文字列を MANIFEST.MF ファイルで指定しておくことをお勧めします。マニフェストにバージョン文字列を指定すると、旧バージョンと並行して新しいバージョンのライブラリをデプロイできるようになります。「共有 Java EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。 |
管理者によるデプロイメント用に共有 Java EE ライブラリまたはオプション パッケージを配布する場合、デプロイメント ファイルをアーカイブ ファイル (共有 Java EE ライブラリの場合は .EAR ファイルまたはスタンドアロン モジュール アーカイブ ファイル、オプション パッケージの場合は単純な .JAR ファイル) にパッケージ化して配布します。「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。
共有 Java EE ライブラリは標準 Java EE アプリケーションまたはスタンドアロン モジュールとしてパッケージ化されるので、『WebLogic Server アプリケーションのデプロイメント』で説明されているように、ライブラリのデプロイメント コンフィグレーションをデプロイメント プランにエクスポートすることもできます。オプション パッケージ .JAR ファイルにはデプロイメント記述子が含まれていないので、エクスポートすることはできません。
開発目的で、展開されたアーカイブ ディレクトリとしてライブラリをデプロイすると、更新と再デプロイメントの繰り返しが簡単になります。
Java EE アプリケーションは、アプリケーションの weblogic-application.xml デプロイメント記述子のエントリを基に、登録された共有 Java EE ライブラリを参照できます。表 9-2 では、ライブラリ参照を定義する XML 要素を示します。
library-name は、ライブラリのマニフェスト ファイルの Extension-Name 属性の値に完全に一致する必要がある (表 9-4 を参照)。
|
|
specification-version よりも古い場合、アプリケーションをデプロイすることはできない。下記の exact-match 要素を使用すると、必要なバージョンをさらに絞り込むことができる。
Specification-Version 属性に完全一致する文字列値を持つ共有 Java EE ライブラリが必要になる (表 9-4 を参照)。
|
|
implementation-version よりも古い場合、アプリケーションをデプロイすることはできない。下記の exact-match 要素を使用すると、必要な実装バージョンをさらに絞り込むことができる。
Implementation-Version 属性に完全一致する文字列値を持つ共有 Java EE ライブラリが必要になる (表 9-4 を参照)。
|
|
たとえば、次の weblogic-application.xml 記述子の単純なエントリでは、共有 Java EE ライブラリ myLibrary を参照します。
<library-ref>
<library-name>myLibrary</library-name>
</library-ref>
上記の例では、WebLogic Server は、依存関係にあるアプリケーションをデプロイする際に myLibrary というライブラリを探します。myLibrary のコピーが複数登録されている場合、WebLogic Server は、最新の仕様バージョンのライブラリを選択します。選択した仕様バージョンを複数のライブラリのコピーが使用している場合、WebLogic Server は、最新の実装バージョンのコピーを選択します。
次の例では、仕様バージョンの要件を指定して共有 Java EE ライブラリを参照します。
<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 値の実装バージョンの両方を指定して共有 Java EE ライブラリを参照します。
<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>
次の例では、context-root-override を指定しています。これがライブラリの 1 つで指定された古い context-root と、代わりに使用する (オーバーライド) 新しい context-root を参照します。
<library-ref>
<library-name>myLibrary</library-name>
<library-context-root-override>
<library-context-root>webapp</library-context-root>
<override-value>mywebapp</override-value>
</library-context-root-override>
</library-ref>
Java EE アプリケーションは、weblogic-application.xml デプロイメント記述子内のエントリを使用して、参照された EAR ライブラリ内の context-root をオーバーライドできます。表 9-3 で、ライブラリ参照において context-root をオーバーライドする XML 要素について説明します。
次の例では、context-root-override を指定しています。これがライブラリの 1 つで指定された古い context-root と、代わりに使用する (オーバーライド) 新しい context-root を参照します。
<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>
<library-context-root-override>
<library-context-root>webapp</library-context-root>
<override-value>mywebapp</override-value>
</library-context-root-override>
上記の例では、現行のアプリケーションが myLibrary を参照します。これには、webapp の context-root が格納されています。この参照をオーバーライドする唯一の方法は、webapp を mywebapp にマップする library-context-root-override を宣言することです。
スタンドアロン モジュール (EJB または Web アプリケーション) としてデプロイされた共有 Java EE ライブラリの URI を参照する場合、モジュール URI は、共有 Java EE ライブラリのデプロイメント名に対応している必要があります。これは、デプロイメント時に手動で割り当てた名前でも、デプロイされたアーカイブ ファイルの名前でも、デプロイされた展開アーカイブ ディレクトリの名前でも構いません。同じモジュールを異なるファイル名で、または別の場所から再デプロイする場合、デフォルト デプロイメント名も変わるので、適切な URI を使用するように参照側アプリケーションを更新する必要があります。
この問題を避けるには、すべての共有 Java EE ライブラリを、スタンドアロン モジュールではなく、エンタープライズ アプリケーションとしてパッケージ化します。スタンドアロン Java EE モジュールとしてライブラリをデプロイする場合は、既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前を URI として使用します。
Java EE アーカイブ (JAR、WAR、RAR、EAR) は、アーカイブのマニフェスト ファイルの属性を使用して 1 つまたは複数の登録済みオプション パッケージを参照できます。
specification-version 値を指定した場合、アーカイブは、コンフィグレーションした値を下回らない最新の仕様バージョンに一致するパッケージを使用する。使用可能なすべてのパッケージが、コンフィグレーションされた specification-version よりも古い場合、アーカイブをデプロイすることはできない。
Specification-Version 属性に完全一致する文字列値を持つオプション パッケージが必要になる (表 9-1 を参照)。
|
|
implementation-version よりも古い場合、アプリケーションをデプロイすることはできない。
Implementation-Version 属性に完全一致する文字列値を持つオプション パッケージが必要になる (表 9-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 ファイル、またはディレクトリ>
有効なオプションを表 9-5 に示します。
$ 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 つまたは複数の共有 Java EE ライブラリ ディレクトリを含むビルド ターゲットを生成するための -librarydir オプションがあります。「weblogic.BuildXMLGen を使用した基本的な build.xml ファイルの生成」を参照してください。
wlcompile および wlappc Ant タスクには、アプリケーション ビルドのクラスパスに含める 1 つまたは複数の共有 Java EE ライブラリを指定するための librarydir 属性と library 要素があります。「分割開発ディレクトリでのアプリケーションのビルド」を参照してください。
共有 Java EE ライブラリを 1 つまたは複数の WebLogic Server インスタンスに登録するには、対象サーバにライブラリをデプロイし、デプロイメントが共有されるように指定します。共有 Java EE ライブラリは、ライブラリを参照するアプリケーションのデプロイ先と同じ WebLogic Server インスタンスに登録する必要があります。必要なライブラリを登録していないサーバ インスタンスに参照側アプリケーションをデプロイする場合、参照側アプリケーションのデプロイメントは失敗します。詳細については、『WebLogic Server アプリケーションのデプロイメント』の「WebLogic Server でのライブラリの登録」を参照してください。
Administration Console を使用して共有 Java EE ライブラリをインストール (デプロイ) する場合の詳細な手順については、「Java EE ライブラリのインストール」を参照してください。Administration Console を使用して、ライブラリを参照するアプリケーションのデプロイ先となるサーバまたはクラスタにライブラリをデプロイする場合の手順については、「Java EE ライブラリのサーバまたはクラスタへの割り当て」を参照してください。
繰り返しの開発プロセスの一部として wldeploy Ant タスクを使用する場合は、library、libImplVer、および libSpecVer 属性を使用して共有 Java EE ライブラリをデプロイします。詳細と例については、「wldeploy Ant タスクのリファレンス」を参照してください。
共有 Java EE ライブラリを登録後、そのライブラリと依存関係にあるアプリケーションおよびアーカイブをデプロイできます。依存関係のあるアプリケーションは、対象サーバが必要なライブラリを登録しており、登録されたデプロイメントがアプリケーションまたはアーカイブのバージョン要件に従っている場合にのみデプロイできます。詳細については、『WebLogic Server アプリケーションのデプロイメント』の「ライブラリを参照するアプリケーションのデプロイ」を参照してください。
このトピックでは、大部分において、エンタープライズ アプリケーションでのみ参照可能な共有 Java EE ライブラリについて説明しています。ただし、別の Web アプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション ライブラリと非常に似ていますが、参照方法が多少異なります。
| 注意 : | 便宜上、この節では、別の Web アプリケーションでのみ参照される共有 Java EE ライブラリのことを指すのに「Web アプリケーション ライブラリ」という用語を使います。 |
weblogic-application.xml ファイルではなく weblogic.xml デプロイメント記述子ファイルを更新する。要素は、「エンタープライズ アプリケーションでの共有 Java EE ライブラリの参照」で説明されているものとほぼ同じです。唯一の違いは、<library-ref> の <context-root> 子要素がここでは無視されることです。weblogic.xml デプロイメント記述子ファイルから、別の種類の共有 Java EE ライブラリ (EJB、エンタープライズ アプリケーション、プレーン JAR ファイル) を参照することはできない。
こうした参照方法の違いを除けば、Web アプリケーション ライブラリを作成、パッケージ化、デプロイする方法は、通常の共有 Java EE ライブラリの場合と同じです。
標準の共有 Java EE アプリケーションをアプリケーション ライブラリとして 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 要素が出現する順序に従います。
デプロイされた各共有 Java EE ライブラリは、LibraryRuntimeMBean で表されます。この MBean を使用すると、名前やバージョンなど、ライブラリ自体の情報を取得できます。また、デプロイされたアプリケーションに関連付けられた ApplicationRuntimeMBean を取得することもできます。ApplicationRuntimeMBean では、アプリケーションが使用するライブラリにアクセスする際に、次の 2 種類の方法を用いることができます。
詳細については、『WebLogic Server API リファレンス』を参照してください。
エンタープライズ アプリケーションが 1 つまたは複数の共有 Java EE ライブラリを参照し、アプリケーションが WebLogic Server にデプロイされている場合、サーバは、内部で参照側のエンタープライズ アプリケーションの weblogic-application.xml ファイルの情報を参照されるライブラリのデプロイメント記述子の情報に結合します。これは、次の順序で行われます。
weblogic-application.xml デプロイメント記述子を読み込みます。weblogic-application.xml、weblogic.xml、weblogic-ejb-jar.xml などになります。 weblogic-application.xml ファイルを結合します。
記述子ファイルの結合方法の結果、weblogic-application.xml ファイルで最初に参照される共有 Java EE ライブラリの記述子の要素が、最後にあるものよりも優先されます。エンタープライズ アプリケーションの記述子自体の要素は、ライブラリの記述子のすべての要素よりも優先されます。
たとえば、myApp というエンタープライズ アプリケーションが、それぞれエンタープライズ アプリケーションとしてパッケージ化されている 2 つの共有 Java EE ライブラリ 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 よりも優先されるためです。
共有 Java EE ライブラリおよびオプション パッケージを開発する際には、以下のベスト プラクティスに留意してください。
/lib サブディレクトリを使用する。/lib サブディレクトリ内のクラスは、サーバの起動時にシステム クラスパスに追加されます。Extension-Name 値を必ず指定する。拡張名を指定しない場合は、ライブラリのデプロイメント名から派生した名前を使用します。デフォルトのデプロイメント名は、アーカイブ デプロイメントと展開されたアーカイブ デプロイメントでは異なります。デプロイメント コマンドで任意の値に設定できます。weblogic-application.xml デプロイメント記述子の context-root 要素を使用して、ライブラリのコンテキスト ルートをオーバーライドします。
  
|