| Oracle® Fusion Middleware Oracle WebLogic Serverアプリケーションの開発 11g リリース1(10.3.6) B60990-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverアプリケーションの開発 11g リリース1(10.3.6) B60990-04 |
|
前 |
次 |
次の項では、共有Java EEライブラリとオプション・パッケージを使用してアプリケーション間でコンポーネントとクラスを共有する方法について説明します。
WebLogic Serverの共有Java EEライブラリ機能では、複数のエンタープライズ・アプリケーション間で、1つまたは複数の種類のJava EEモジュールを簡単に共有できます。共有Java EEライブラリは、デプロイメントに際してJava EEアプリケーション・コンテナに登録される1つまたは複数のモジュールです。共有Java EEライブラリは次のいずれかです。
スタンドアロンEJBモジュール
スタンドアロンWebアプリケーション・モジュール
エンタープライズ・アプリケーションにパッケージ化された複数のEJBモジュール
エンタープライズ・アプリケーションにパッケージ化された複数のWebアプリケーション・モジュール
単独のプレーンJARファイル
共有Java EEライブラリを適切なアーカイブ・ファイル(EAR、JAR、またはWAR)にパッケージ化することをお薦めします。ただし、開発目的の場合、展開されたアーカイブ・ディレクトリとして共有Java EEライブラリをデプロイすれば、更新と再デプロイメントの繰返しを簡単にすることができます。
共有Java EEライブラリを登録後、そのライブラリを参照するエンタープライズ・アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に必要なライブラリへの参照を受け取り、参照側アプリケーション自体の一部としてパッケージ化されているかのように、ライブラリを構成するモジュールを使用できます。参照側アプリケーションのクラスパスにライブラリ・クラスが追加され、参照側アプリケーションのデプロイメント記述子は、共有Java EEライブラリを構成するモジュールのデプロイメント記述子と(メモリー内で)結合されます。
このトピックでは、大部分において、エンタープライズ・アプリケーションでのみ参照可能な共有Java EEライブラリについて説明しています。ただし、別のWebアプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション・ライブラリと非常に似ていますが、参照方法が多少異なります。詳細は、「Webアプリケーション共有Java EEライブラリの情報」を参照してください。
|
注意: WebLogic Serverでは、ドメイン・ディレクトリのlibサブディレクトリを使用して、WebLogic Serverシステム・クラスパスに1つまたは複数のJARファイルを追加するという簡単な方法も利用できます。「ドメイン/libディレクトリへのJARの追加」を参照してください。 |
WebLogic Serverは、Java EE 5.0仕様の項8.2 Optional Package Supportに記載のとおり、オプション・パッケージをサポートしています。バージョニングについては、オプション・パッケージのバージョニングで説明しています(http://download.oracle.com/javase/6/docs/technotes/guides/extensions/versioning.htmlを参照)。オプション・パッケージは、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ライブラリのバージョニングを、http://download.oracle.com/javase/1.4.2/docs/guide/extensions/versioning.htmlのオプション・パッケージのバージョニングのドキュメントで説明されている2種類のレベルでサポートしています。
仕様バージョン - 共有Java EEライブラリまたはオプション・パッケージが従う仕様のバージョン番号(Java EE仕様バージョンなど)を指定します。
実装バージョン - ライブラリまたはパッケージの実際のコード実装のバージョン番号を指定します。たとえば、コードの実際の改訂番号またはリリース番号が実装バージョンに当たります。実装バージョンを指定するには、仕様バージョンを指定する必要があります。
ベスト・プラクティスとして、共有Java EEライブラリを作成する際には、バージョン情報(仕様バージョンまたは実装バージョンと仕様バージョンの両方)を必ず含めることをお薦めします。共有コンポーネントの開発時にバージョン情報を作成および更新すると、テスト目的でコンポーネントの複数のバージョンを同時にデプロイできます。バージョン情報を指定しない場合、またはバージョン文字列のインクリメントに失敗した場合は、新しいライブラリをデプロイする前に既存のライブラリをアンデプロイする必要があります。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
参照側アプリケーションのバージョニング情報によって、そのアプリケーションで必要なライブラリとパッケージのバージョンが決まります。各アプリケーションに応じて、必要となるライブラリまたはパッケージのバージョンが異なる場合があります。たとえば、本番アプリケーションがある特定のバージョンのライブラリを要求することがあります。これはそのライブラリのみが本番用に完全に適しているためです。同じライブラリの最低限のバージョンを常に使用するように内部アプリケーションを構成できます。特定のバージョンを必要としないアプリケーションで、最新バージョンのライブラリを使用するように構成することもできます。「エンタープライズ・アプリケーションでの共有Java EEライブラリの参照」を参照してください。
オプション・パッケージと共有Java EEライブラリでは、以下の機能が共通しています。
両方とも、デプロイメント時にWebLogic Serverインスタンスに登録されます。
両方とも、省略可能な実装バージョン文字列と仕様バージョン文字列をサポートしています。
共有Java EEライブラリとオプション・パッケージを参照するアプリケーションは、共有ファイルの必須バージョンを指定できます。
オプション・パッケージは他のオプション・パッケージを、共有Java EEライブラリは他の共有Java EEライブラリを参照できます。
オプション・パッケージは、共有Java EEライブラリと以下の点が異なっています。
オプション・パッケージはプレーンJARファイルであるのに対し、共有Java EEライブラリは、プレーンJARファイル、Java EEエンタープライズ・アプリケーション、スタンドアロンJava EEモジュール(EJBまたはWebアプリケーション)のいずれでも可能です。つまり、ライブラリは有効なJava EEおよびWebLogic Serverデプロイメント記述子を持つことができます。オプション・パッケージのJARファイルのデプロイメント記述子は無視されます。
すべてのJava EEアプリケーションまたはモジュールがオプション・パッケージを参照できる(META-INF/MANIFEST.MFを使用)のに対し、共有Java EEライブラリを参照できるのはエンタープライズ・アプリケーションとWebアプリケーションのみです(weblogic-application.xmlを使用)。またはweblogic.xml
通常、1つまたは複数のEJB、Webアプリケーションまたはエンタープライズ・アプリケーションを複数の異なるエンタープライズ・アプリケーション間で共有する場合は、共有Java EEライブラリを使用します。1つまたは複数の(JARファイルにパッケージ化された)クラスを複数のJava EEモジュール間で共有する場合は、オプション・パッケージを使用します。
プレーンJARファイルは、ライブラリとしてもオプション・パッケージとしても共有できます。次を行う場合は、オプション・パッケージを使用します。
複数のJava EEモジュール間でプレーンJARファイルを共有
共有JARから別の共有JARファイルを参照
Java EE 5.0仕様の説明に従ってプレーンJARを共有
1つまたは複数のエンタープライズ・アプリケーションからJARファイルを参照するだけで、Java EE仕様に厳密に準拠する必要がない場合は、共有Java EEライブラリを使用してプレーンJARファイルを共有します。
|
注意: OracleのドキュメントとWebLogic Serverユーティリティでは、共有Java EEライブラリという語をライブラリとオプション・パッケージの両方の意味で使用します。必要な場合にのみオプション・パッケージと呼びます。 |
複数のアプリケーションで共有可能な新しい共有Java EEライブラリを作成するには:
有効かつデプロイ可能なJava EEモジュールまたはエンタープライズ・アプリケーションに共有Java EEライブラリを作成します。ライブラリは、Java EEモジュールまたはエンタープライズ・アプリケーションで必要なJava EEデプロイメント記述子を持つ必要があります。
「共有Java EEライブラリ・ファイルの作成」を参照してください。
オプション・パッケージ・クラスを作業ディレクトリに作成します。
「オプション・パッケージ・クラス・ファイルの作成」を参照してください。
共有Java EEライブラリのMANIFEST.MFファイルを作成および編集して、名前およびバージョン文字列情報を指定します。
「共有Java EEライブラリのマニフェスト属性の編集」を参照してください。
配布およびデプロイメント用共有Java EEライブラリをパッケージ化します。
「配布およびデプロイメント用共有Java EEライブラリのパッケージ化」を参照してください。
以下の種類のJava EEモジュールを共有Java EEライブラリとしてデプロイできます。
展開されたディレクトリの形式またはJARファイルでパッケージ化された形式のEJBモジュール
展開されたディレクトリの形式またはWARファイルでパッケージ化された形式のWebアプリケーション・モジュール
展開されたディレクトリの形式またはEARファイルでパッケージ化された形式のエンタープライズ・アプリケーション
JARファイルでパッケージ化された形式のプレーンJavaクラス(複数可)
別のライブラリから参照される共有Java EEライブラリ(「Webアプリケーション共有Java EEライブラリの情報」を参照)
共有Java EEライブラリには以下の制限があります。
共有Java EEライブラリのWebアプリケーション・モジュールのコンテキスト・ルートは、参照側のエンタープライズ・アプリケーションのコンテキスト・ルートとは競合しません。必要に応じて、ライブラリのコンテキスト・ルートをオーバーライドするように参照側アプリケーションを構成できます。「エンタープライズ・アプリケーションでの共有Java EEライブラリの参照」を参照してください。
共有Java EEライブラリをネストすることはできません。たとえば、共有Java EEライブラリとしてEARをデプロイする場合は、EAR全体をライブラリとして指定する必要があります。EAR内の個々のJava EEモジュールを名前が付けられた個別のライブラリとして指定することはできません。
他のJava EEモジュールまたはエンタープライズ・アプリケーションの場合と同様、ドメイン内のターゲット・サーバーまたはクラスタにデプロイメントするために共有Java EEライブラリを構成する必要があります。つまり、ライブラリには、WebLogic Server固有のデプロイメント記述子およびオプション・デプロイメント・プランとともに、有効なJava EEデプロイメント記述子が必要です。『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
共有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
オプション・パッケージとして使用するJARファイルがすでにある場合、その内容を作業ディレクトリに展開して、マニフェスト・ファイルを編集できるようにします。
cd /apps/myOptPkg jar xvf /build/libraries/myLib.jar
共有Java EEライブラリの名前とバージョン情報は、META-INF/MANIFEST.MFファイルで指定します。表9-1で、有効な共有Java EEライブラリ・マニフェストの属性を示します。
表9-1 Java EEライブラリのマニフェスト属性
| 属性 | 説明 |
|---|---|
Extension-Name |
共有Java EEライブラリの名前を識別する文字列値(オプション)。参照するアプリケーションでは、ライブラリを使用するには、完全に一致する ベスト・プラクティスとしては、ライブラリごとに |
Specification-Version |
共有Java EEライブラリの仕様バージョンを定義する文字列値(オプション)。参照するアプリケーションでは、ライブラリで要求されている
バージョン番号および改訂番号をピリオドで区切ったメジャー/マイナー・バージョン・フォーマット(「9.0.1.1」など) 特定の共有Java EEライブラリを完全一致の形で示すバージョン、最低限のバージョン、使用可能な最新バージョンのいずれかを要求するようにアプリケーションの参照を構成できます。 共有Java EEライブラリの仕様バージョンは、一部制約があるものの、ライブラリのデプロイ時にコマンド・ラインでも設定できます。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。 |
Implementation-Version |
共有Java EEライブラリのコード実装バージョンを定義する文字列値(オプション)。
メジャー/マイナー・バージョン・フォーマットを使用する場合、特定の共有Java EEライブラリを完全一致の形で示すバージョン、最低限のバージョン、使用可能な最新バージョンのいずれかを要求するようにアプリケーションの参照を構成できます。テキスト・フォーマットを使用する場合、アプリケーションの参照では、ライブラリのバージョンを完全一致の形で指定する必要があります。 共有Java EEライブラリの実装バージョンは、一部制約があるものの、ライブラリのデプロイ時にコマンド・ラインでも設定できます。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。 |
マニフェスト・ファイルの属性を指定するには:
テキスト・エディタでマニフェスト・ファイルを開くか作成します。サンプルの共有Java EEライブラリの場合、次のコマンドを使用します。
cd /apps/myLibrary mkdir META-INF emacs META-INF/MANIFEST.MF
次に、オプション・パッケージのサンプルの場合、次を使用します。
cd /apps/myOptPkg mkdir META-INF emacs META-INF/MANIFEST.MF
テキスト・エディタで、共有Java EEライブラリの名前を指定する文字列値を追加します。例:
Extension-Name: myExtension
ライブラリを参照するアプリケーションは、Extension-Name値に完全一致した共有ファイルを指定する必要があります。
ベスト・プラクティスとしては、共有Java EEライブラリのバージョン情報(オプション)を入力します。例:
Extension-Name: myExtension Specification-Version: 2.0 Implementation-Version: 9.0.0
バージョン識別子に対してメジャー/マイナー・フォーマットを使用すると、別のアプリケーションからライブラリを参照する際に最も柔軟な指定が可能です(表9-2を参照)
|
注意: デプロイメント時に必要に応じてコマンド・ラインでSpecification-VersionおよびImplementation-Versionを指定できますが、これらの文字列をMANIFEST.MFファイルで指定することをお薦めします。マニフェストにバージョン文字列を指定すると、旧バージョンと並行して新しいバージョンのライブラリをデプロイできるようになります。「共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。 |
管理者によるデプロイメント用に共有Java EEライブラリまたはオプション・パッケージを配布する場合、デプロイメント・ファイルをアーカイブ・ファイル(共有Java EEライブラリの場合は.EARファイルまたはスタンドアロン・モジュール・アーカイブ・ファイル、オプション・パッケージの場合は単純な.JARファイル)にパッケージ化して配布します。「wldeployを使用したアプリケーションのデプロイメント」を参照してください。
共有Java EEライブラリは標準Java EEアプリケーションまたはスタンドアロン・モジュールとしてパッケージ化されるため、『Oracle WebLogic Serverへのアプリケーションのデプロイ』で説明されているように、ライブラリのデプロイメント構成をデプロイメント・プランにエクスポートすることもできます。オプション・パッケージ.JARファイルにはデプロイメント記述子が含まれていないため、エクスポートすることはできません。
開発目的で、展開されたアーカイブ・ディレクトリとしてライブラリをデプロイすると、更新と再デプロイメントの繰返しが簡単になります。
Java EEアプリケーションは、アプリケーションのweblogic-application.xmlデプロイメント記述子のエントリを基に、登録された共有Java EEライブラリを参照できます。表9-2では、ライブラリ参照を定義するXML要素を示します。
表9-2 weblogic-application.xmlの共有Java EEライブラリ参照用の要素
| 要素 | 説明 |
|---|---|
|
library-ref |
|
library-name |
使用する共有Java EEライブラリの名前を指定する文字列値(必須)。 |
specification-version |
共有Java EEライブラリの必要な仕様バージョンを定義する文字列値(オプション)。この要素を設定しなかった場合、アプリケーションは最新の仕様バージョンに一致するライブラリを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アプリケーションは、構成した値を下回らない最新の仕様バージョンに一致するライブラリを使用します。使用可能なすべてのライブラリが、構成された メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アプリケーションでは、ライブラリのマニフェスト・ファイルの |
implementation-version |
共有Java EEライブラリの必要な実装バージョンを指定する文字列値(オプション)。この要素を設定しなかった場合、アプリケーションは最新の実装バージョンに一致するライブラリを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アプリケーションは、構成した値を下回らない最新の実装バージョンに一致するライブラリを使用します。使用可能なすべてのライブラリが、構成された メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アプリケーションでは、ライブラリのマニフェスト・ファイルの |
exact-match |
構成された値よりも新しい仕様または実装バージョンを持つ共有Java EEライブラリがある場合、それをアプリケーションで使用するかどうかを指定するブール値(オプション)。デフォルトでは、この要素はfalseです - つまり、WebLogic Serverは、最新バージョンのライブラリがある場合は、それを使用します。この要素をtrueに設定すると、 |
context-root |
Webアプリケーション共有Java EEライブラリで使用する代替コンテキスト・ルートを指定する文字列値(オプション)。この要素は、ライブラリのコンテキスト・ルートが、参照側Java EEアプリケーションのWebアプリケーションのコンテキスト・ルートと競合する場合に指定します。 Webアプリケーション共有Java EEライブラリは特殊なライブラリの呼称であり、別のWebアプリケーションによって参照されるWebアプリケーションです。「Webアプリケーション共有Java EEライブラリの情報」を参照してください。 |
たとえば、次の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を指定します。WARライブラリ参照がweblogic-application.xmlから作成された場合、context-rootは次の参照を使用して指定できます。
<library-ref> <library-name>myLibrary</library-name> <context-root>mywebapp</context-root> </library-ref>
Java EEアプリケーションは、weblogic-application.xmlデプロイメント記述子内のエントリを使用して、参照されたEARライブラリ内のcontext-rootをオーバーライドできます。表9-3では、ライブラリ参照においてcontext-rootをオーバーライドするXML要素について説明します。
表9-3 weblogic-application.xmlの共有Java EEライブラリ・オーバーライド用の要素
| 要素 | 説明 |
|---|---|
context-root |
ライブラリで宣言されている 参照元アプリケーション(たとえば、ユーザー・アプリケーション)のみが、ライブラリで宣言されている |
override-value |
ライブラリで宣言されているcontext-root要素をオーバーライドする際の |
次の例では、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> <context-root>webapp</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つまたは複数の登録済みオプション・パッケージを参照できます。
表9-4 オプション・パッケージ参照用のマニフェスト属性
| 属性 | 説明 |
|---|---|
|
Extension-List |
オプション・パッケージの依存関係の論理名を定義する文字列値(必須)。
|
|
オプション・パッケージの依存関係の名前を識別する文字列値(必須)。この値は、オプション・パッケージのマニフェスト・ファイルで定義された 1つのアーカイブから複数のオプション・パッケージを参照する場合は、
|
|
オプション・パッケージの必要な仕様バージョンを定義する文字列値(オプション)。この要素を設定しなかった場合、アーカイブは最新の仕様バージョンに一致するパッケージを使用します。メジャー/マイナー・バージョン・フォーマットで メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アーカイブでは、パッケージのマニフェスト・ファイルの 1つのアーカイブから複数のオプション・パッケージを参照する場合は、 |
|
オプション・パッケージの必要な実装バージョンを指定する文字列値(オプション)。この要素を設定しなかった場合、アーカイブは最新の実装バージョンに一致するパッケージを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アーカイブは設定した値を下回らない最新の実装バージョンに一致するパッケージを使用します。使用可能なすべてのライブラリが、構成された メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アーカイブでは、パッケージのマニフェスト・ファイルの 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 [options] <ear, jar, war file, or directory>
有効なオプションを表9-5に示します。
表9-5 weblogic.appmergeのオプション
| オプション | 説明 |
|---|---|
-help |
標準の使用方法メッセージを出力します。 |
-version |
バージョン情報を出力します。 |
-output <file> |
代替的な出力アーカイブまたはディレクトリを指定します。これが設定されていないと、出力はソース・アーカイブまたはディレクトリに置かれます。 |
-plan <file> |
デプロイメント・プラン(オプション)を指定します。 |
-verbose |
より冗長な出力を提供します。 |
-library <file> |
ライブラリのカンマ区切りのリスト。各ライブラリは、マニフェストで設定されていない場合、その名前とバージョンを次の構文で設定できます。 <file> [@name=<string>@libspecver=<version> @libimplver=<version|string>]. |
-librarydir <dir> |
指定したディレクトリ内のすべてのファイルをライブラリとして登録します。 |
-writeInferredDescriptors |
アプリケーションまたはモジュールに、デプロイメント記述子がアノテーション情報と共に格納されることを指定します。 |
例:
$ 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インスタンスに登録する必要があります。必要なライブラリを登録していないサーバー・インスタンスに参照側アプリケーションをデプロイする場合、参照側アプリケーションのデプロイメントは失敗します。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverでのライブラリの登録に関する項を参照してください。
管理コンソールを使用して共有Java EEライブラリをインストール(デプロイ)する場合の詳細な手順については、「Java EEライブラリのインストール」を参照してください。管理コンソールを使用して、ライブラリを参照するアプリケーションのデプロイ先となるサーバーまたはクラスタにライブラリをデプロイする場合の手順については、「Java EEライブラリのサーバーまたはクラスタへの割当て」を参照してください。
繰返しの開発プロセスの一部としてwldeploy Antタスクを使用する場合は、library、libImplVer、およびlibSpecVer属性を使用して共有Java EEライブラリをデプロイします。詳細およびその他のサンプルについては、付録B「wldeploy Antタスクのリファレンス」を参照してください。
共有Java EEライブラリを登録後、そのライブラリと依存関係にあるアプリケーションおよびアーカイブをデプロイできます。依存関係にあるアプリケーションは、ターゲット・サーバーが必要なすべてのライブラリを登録していて、登録されたデプロイメントがアプリケーションまたはアーカイブのバージョン要件に従っている場合にのみデプロイできます。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のライブラリを参照するアプリケーションのデプロイに関する項を参照してください。
このトピックでは、大部分において、エンタープライズ・アプリケーションでのみ参照可能な共有Java EEライブラリについて説明しています。ただし、別のWebアプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション・ライブラリと非常に似ていますが、参照方法が多少異なります。
|
注意: わかりやすくするため、この項では、別のWebアプリケーションのみによって参照される共有Java EEライブラリの呼称として、Webアプリケーション・ライブラリという用語を使います。 |
具体的には:
Webアプリケーション・ライブラリは、別のWebアプリケーションでのみ参照可能です。
Webアプリケーションは、Webアプリケーション・ライブラリを参照する場合に、weblogic-application.xmlファイルではなくweblogic.xmlデプロイメント記述子ファイルを更新します。要素は、「エンタープライズ・アプリケーションでの共有Java EEライブラリの参照」で説明されているものとほぼ同じです。唯一の違いは、<library-ref>の<context-root>子要素がここでは無視されることです。
Webアプリケーションの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アプリケーションをwebapp-libraryとして登録することです。それには、管理コンソールまたは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種類の方法を用いることができます。
getLibraryRuntimes()は、weblogic-application.xmlファイルで参照される共有Java EEライブラリを返します。
getOptionalPackageRuntimes()は、マニフェスト・ファイルで参照されるオプション・パッケージを返します。
詳細は、Oracle WebLogic Server APIリファレンスを参照してください。
エンタープライズ・アプリケーションが1つまたは複数の共有Java EEライブラリを参照し、アプリケーションがWebLogic Serverにデプロイされている場合、サーバーは内部で参照側のエンタープライズ・アプリケーションのweblogic-application.xmlファイルの情報を参照されるライブラリのデプロイメント記述子の情報に結合します。これは、次の順序で行われます。
エンタープライズ・アプリケーションがデプロイされると、WebLogic Serverはweblogic-application.xmlデプロイメント記述子を読み込みます。
WebLogic Serverは、参照対象の任意の共有Java EEライブラリのデプロイメント記述子を読み込みます。ライブラリのタイプ(エンタープライズ・アプリケーション、EJBまたはWebアプリケーション)によって、読み込まれるファイルはweblogic-application.xml、weblogic.xml、weblogic-ejb-jar.xmlなどになります。
WebLogic Serverは、参照される共有Java EEライブラリのデプロイメント記述子を最初に(一度に参照される順番で)結合し、そのライブラリの記述子ファイルの上に参照側のエンタープライズ・アプリケーションの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ライブラリおよびオプション・パッケージを開発する際には、以下のベスト・プラクティスに留意してください。
1つまたは複数のJava EEモジュール(EJB、Webアプリケーション、エンタープライズ・アプリケーションまたはプレーンJavaファイル)を複数のエンタープライズ・アプリケーション間で共有する場合、共有Java EEライブラリを使用します。
EJB JARファイルなどのスタンドアロンJava EEモジュールを共有Java EEライブラリとしてデプロイする場合は、エンタープライズ・アプリケーション内にモジュールをパッケージ化します。これにより、スタンドアロン・モジュールのURIがデプロイメント名から派生することになるので、URIの競合を防ぐことができます。
スタンドアロンJava EEモジュールとして共有Java EEライブラリをデプロイする場合は、デプロイメント時に既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前をURIとして使用します。
複数のJava EEアーカイブ・ファイルで複数のJavaクラスを共有する場合は、オプション・パッケージを使用します。
ドメイン全体のアプリケーションで使用できるようにする必要があるクラスがあり、それらのクラスを頻繁には更新しない場合(たとえば、ドメイン内でサード・パーティのクラスを共有する必要がある場合)は、共有Java EEライブラリやオプション・パッケージではなく、ドメインの/libサブディレクトリを使用します。/libサブディレクトリ内のクラスは、ドメイン内のWebLogic Serverインスタンスで実行しているすべてのJava EEアプリケーションで(別のシステム・レベル・クラスローダー内で)使用できるようになります。
依存関係があるアプリケーションに対しては、バージョンの要件を具体的に指定する必要がない場合でも、仕様バージョンと実装バージョンを必ず指定します。共有Java EEライブラリに対してバージョンを指定すると、複数のバージョンの共有ファイルをテスト用にデプロイできます。
共有Java EEライブラリごとにExtension-Name値を必ず指定します。拡張名を指定しない場合は、ライブラリのデプロイメント名から派生した名前を使用します。デフォルトのデプロイメント名は、アーカイブ・デプロイメントと展開されたアーカイブ・デプロイメントでは異なります。デプロイメント・コマンドで任意の値に設定できます。
共有Java EEライブラリとしてデプロイメントするWebアプリケーションを開発する場合は、一意なコンテキスト・ルートを使用します。このコンテキスト・ルートが、依存関係のあるJava EEアプリケーションのコンテキスト・ルートと競合する場合、EARのweblogic-application.xmlデプロイメント記述子のcontext-root要素を使用して、ライブラリのコンテキスト・ルートをオーバーライドします。
組織の管理者またはデプロイヤに配布するために、共有Java EEライブラリをアーカイブ・ファイルとしてパッケージ化します。開発時に、展開されたアーカイブ・ディレクトリからライブラリをデプロイすると、更新および繰返しの再デプロイメントを簡単に実行できます。
依存関係があるアプリケーションとアーカイブのデプロイ先となるすべてのWebLogic Serverインスタンスに共有Java EEライブラリをデプロイします。参照側アプリケーションのデプロイ先となるサーバー・インスタンスにライブラリが登録されていない場合、参照側アプリケーションのデプロイメントは失敗します。
