| Oracle® Fusion Middleware Oracle WebLogic Server アプリケーションの開発 11g リリース 1 (10.3.1) B55515-01 |
|
 戻る |
 次へ |
以下の節では、共有 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 ファイルを追加するという簡単な方法も利用できます。「システム クラスパスへの JAR の追加」を参照してください。 |
WebLogic Server は、J2EE 5.0 仕様の節 8.2 Optional Package Support に記載のとおり、オプション パッケージをサポートしています。バージョニングについては、Optional Package Versioning で説明しています (http://java.sun.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://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html の Optional Package Versioning で説明されている 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 ライブラリ、オプション パッケージ、および参照側アプリケーションのデプロイおよび管理の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「共有 J2EE ライブラリおよびそれに依存するアプリケーションのデプロイ」を参照してください。
複数のアプリケーションで共有可能な新しい共有 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 Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』を参照してください。
共有 Java EE ライブラリを、スタンドアロン Java EE モジュールではなく、エンタープライズ アプリケーションとしてパッケージ化することをお勧めします。これは、スタンドアロン モジュールの URI がデプロイメント名から派生しており、モジュールがどのようにデプロイされたかによって変わる可能性があるためです。デフォルトでは、WebLogic Server はデプロイメント アーカイブ ファイル名または展開されたアーカイブ ディレクトリ名をデプロイメント名として使用します。別のファイルまたは場所からスタンドアロン共有 Java EE ライブラリを再デプロイする場合、デプロイメント名と URI も変わり、誤った URI を使用している参照側アプリケーションは、デプロイされたライブラリにアクセスできません。
スタンドアロン Java EE モジュールとして共有 Java EE ライブラリをデプロイする場合は、デプロイメント時に既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前を URI として使用します。
任意のクラスのセットをオプション パッケージ ファイルにまとめることができます。共有クラスのコレクションは、最終的に標準 JAR アーカイブにパッケージ化されます。ただし、JAR のマニフェスト ファイルを編集する必要があるので、最初にすべてのクラス ファイルを作業ディレクトリに作成します。
新しいオプション パッケージ用の作業ディレクトリを作成します。次に例を示します。
prompt> java weblogic.DDConverter [options] archive_file_or_directory
必要に応じて適切なパッケージ サブディレクトリを作成して、コンパイルしたクラス ファイルを作業ディレクトリにコピーします。次に例を示します。
prompt> java weblogic.DDConverter [options] archive_file_or_directory
オプション パッケージとして使用する JAR ファイルがすでにある場合、その内容を作業ディレクトリに展開して、マニフェスト ファイルを編集できるようにします。
prompt> java weblogic.DDConverter [options] archive_file_or_directory
共有 Java EE ライブラリの名前とバージョン情報は、META-INF/MANIFEST.MF ファイルで指定します。表 9-2 で、有効な共有 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 ライブラリの場合、次のコマンドを使用します。
prompt> java weblogic.DDConverter [options] archive_file_or_directory
次に、オプション パッケージの場合の例を示します。
prompt> java weblogic.DDConverter [options] archive_file_or_directory
テキスト エディタで、共有 Java EE ライブラリの名前を指定する文字列値を追加します。次に例を示します。
prompt> java weblogic.DDConverter [options] archive_file_or_directory
ライブラリを参照するアプリケーションは、Extension-Name 値に完全一致した共有ファイルを指定する必要があります。
ベスト プラクティスとして、共有 Java EE ライブラリのバージョン情報 (省略可能) を入力します。次に例を示します。
prompt> java weblogic.DDConverter [options] archive_file_or_directory
バージョン識別子に対してメジャー/マイナー フォーマットを使用すると、別のアプリケーションからライブラリを参照する際に最も柔軟な指定が可能です (表 9-2 を参照。)
prompt> java weblogic.DDConverter [options] archive_file_or_directory
管理者によるデプロイメント用に共有 Java EE ライブラリまたはオプション パッケージを配布する場合、デプロイメント ファイルをアーカイブ ファイル (共有 Java EE ライブラリの場合は .EAR ファイルまたはスタンドアロン モジュール アーカイブ ファイル、オプション パッケージの場合は単純な .JAR ファイル) にパッケージ化して配布します。「wldeploy を使用したアプリケーションのデプロイメント」を参照してください。
共有 Java EE ライブラリは標準 Java EE アプリケーションまたはスタンドアロン モジュールとしてパッケージ化されるので、『Oracle Fusion Middleware 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-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-2 では、ライブラリ参照において context-root をオーバーライドする XML 要素について説明します。
表 9-3 weblogic-application.xml の共有 Java EE ライブラリ オーバーライド用の要素
| 要素 | 説明 |
|---|---|
library-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> <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 つまたは複数の登録済みオプション パッケージを参照できます。
表 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 [オプション] <ear、jar、war ファイル、またはディレクトリ>
有効なオプションを 表 9-2 に示します:
表 9-5 weblogic.appmerge のオプション
| オプション | 説明 |
|---|---|
-ヘルプ |
標準の使い方メッセージを出力する。 |
-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 Fusion Middleware Oracle 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 ライブラリを登録後、そのライブラリと依存関係にあるアプリケーションおよびアーカイブをデプロイできます。依存関係のあるアプリケーションは、対象サーバが必要なライブラリを登録しており、登録されたデプロイメントがアプリケーションまたはアーカイブのバージョン要件に従っている場合にのみデプロイできます。詳細については、『Oracle Fusion Middleware 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 アプリケーションを 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 種類の方法を用いることができます。
getLibraryRuntimes() は、weblogic-application.xml ファイルで参照される共有 Java EE ライブラリを返す。
getOptionalPackageRuntimes() は、マニフェスト ファイルで参照されるオプション パッケージを返す。
詳細については、『Oracle Fusion Middleware 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 サブディレクトリ内のクラスは、サーバの起動時にシステム クラスパスに追加されます。
依存関係があるアプリケーションに対しては、バージョンの要件を具体的に指定する必要がない場合でも、仕様バージョンと実装バージョンを必ず指定する。共有 Java EE ライブラリに対してバージョンを指定すると、複数のバージョンの共有ファイルをテスト用にデプロイできます。
共有 Java EE ライブラリごとに Extension-Name 値を必ず指定する。拡張名を指定しない場合は、ライブラリのデプロイメント名から派生した名前を使用します。デフォルトのデプロイメント名は、アーカイブ デプロイメントと展開されたアーカイブ デプロイメントでは異なります。デプロイメント コマンドで任意の値に設定できます。
共有 Java EE ライブラリとしてデプロイする Web アプリケーションを開発する場合は、ユニークなコンテキスト ルートを使用する。このコンテキスト ルートが、依存関係のある Java EE アプリケーションのコンテキスト ルートと衝突する場合、EAR の weblogic-application.xml デプロイメント記述子の context-root 要素を使用して、ライブラリのコンテキスト ルートをオーバーライドします。
組織の管理者またはデプロイ担当者に配布するために、共有 Java EE ライブラリをアーカイブ ファイルとしてパッケージ化する。開発時に、展開されたアーカイブ ディレクトリからライブラリをデプロイすると、更新および繰り返しの再デプロイメントを簡単に実行できます。
依存関係があるアプリケーションとアーカイブのデプロイ先となるすべての WebLogic Server インスタンスに共有 Java EE ライブラリをデプロイする。参照側アプリケーションのデプロイ先となるサーバ インスタンスにライブラリが登録されていない場合、参照側アプリケーションのデプロイメントは失敗します。
