13 共有Java EEライブラリおよびオプション・パッケージの作成
この章の内容は次のとおりです。
- 共有Java EEライブラリおよびオプション・パッケージの概要
WebLogic Serverの共有Java EEライブラリ機能では、複数のエンタープライズ・アプリケーション間で、1つまたは複数の種類のJava EEモジュールを簡単に共有できます。共有Java EEライブラリはエンタープライズ・アプリケーションから参照することが可能ですが、別のWebアプリケーションでのみ参照可能なライブラリを作成することもできます。 - 共有Java EEライブラリの作成
EJB、Webアプリケーション、エンタープライズ・アプリケーション、プレーンJavaクラスなどのJava EEモジュールを共有Java EEライブラリとしてデプロイできます。これらのモジュールは、WebLogic Serverで複数のエンタープライズ・アプリケーション間で共有することができます。 - エンタープライズ・アプリケーションでの共有Java EEライブラリの参照
Java EEアプリケーションは、アプリケーションのweblogic-application.xml
デプロイメント記述子のエントリを基に、登録された共有Java EEライブラリを参照できます。 - Java EEアプリケーションまたはモジュールからのオプション・パッケージの参照
Java EEアーカイブ(JAR、WAR、RAR、EAR)は、アーカイブのマニフェスト・ファイルの属性を使用して1つまたは複数の登録済みオプション・パッケージを参照できます。 - weblogic.appmergeを使用したライブラリの結合
weblogic.appmerge
を使用し、ディスクに書き込んだ結合されたアプリケーションを調べることで、ライブラリの結合を理解することもできます。 - 分割開発ディレクトリ環境への共有Java EEライブラリの統合
基本的なbuild.xmlファイルを共有Java EEライブラリ・ディレクトリ内に生成した後、分割開発ディレクトリでアプリケーションを構築することができます。 - 共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ
共有Java EEライブラリを1つまたは複数のWebLogic Serverインスタンスに登録するには、ターゲット・サーバーにライブラリをデプロイし、デプロイメントが共有されるように指定します。共有Java EEライブラリは、ライブラリを参照するアプリケーションのデプロイ先と同じWebLogic Serverインスタンスに登録する必要があります。 - Webアプリケーション共有Java EEライブラリの情報
一部の共有Java EEライブラリはエンタープライズ・アプリケーションでのみ参照可能です。ただし、別のWebアプリケーションでのみ参照可能なライブラリを作成することもできます。このライブラリの機能はアプリケーション・ライブラリと非常に似ていますが、参照方法が多少異なります。 - WebアプリケーションにおけるWebアプリケーション・ライブラリの使用
標準の共有Java EEアプリケーションをapplication-libraries
としてWebLogic Serverにデプロイできるのと同様に、標準のWebアプリケーションをwebapp-library
としてWebLogic Serverにデプロイし、他のWebアプリケーションがこれらのライブラリを参照できるようにすることが可能です。 - LibraryRuntimeMBeanに登録された共有Java EEライブラリ情報へのアクセス
様々なMBeanを使用して共有Java EEライブラリに関する情報を取得したり、アプリケーションで使用されるライブラリにアクセスしたりできます。 - 共有Java EEライブラリの参照時のモジュールの優先順位
エンタープライズ・アプリケーションが1つまたは複数の共有Java EEライブラリを参照し、アプリケーションがWebLogic Serverにデプロイされている場合、サーバーは内部で参照側のエンタープライズ・アプリケーションのweblogic-application.xml
ファイルの情報を参照されるライブラリのデプロイメント記述子の情報に結合します。 - 共有Java EEライブラリを使用する場合のベスト・プラクティス
共有Java EEライブラリおよびオプション・パッケージの概要
WebLogic Serverの共有Java EEライブラリ機能では、複数のエンタープライズ・アプリケーション間で、1つまたは複数の種類のJava EEモジュールを簡単に共有できます。共有Java EEライブラリはエンタープライズ・アプリケーションから参照することが可能ですが、別のWebアプリケーションでのみ参照可能なライブラリを作成することもできます。
共有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は、https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/extensions.html
に記載(バージョニングについては、オプション・パッケージのバージョニング(https://docs.oracle.com/javase/8/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ライブラリのバージョニングを、https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/versioning.html
のオプション・パッケージのバージョニングのドキュメントで説明されている2種類のレベルでサポートしています。
-
仕様バージョン - 共有Java EEライブラリまたはオプション・パッケージが従う仕様のバージョン番号(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 WebLogic Serverへのアプリケーションのデプロイ』の共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイに関する項を参照してください。
共有Java EEライブラリの作成
EJB、Webアプリケーション、エンタープライズ・アプリケーション、プレーンJavaクラスなどのJava EEモジュールを共有Java EEライブラリとしてデプロイできます。これらのモジュールは、WebLogic Serverで複数のエンタープライズ・アプリケーション間で共有することができます。
新しい共有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として使用します。
親トピック: 共有Java EEライブラリの作成
オプション・パッケージ・クラス・ファイルの作成
任意のクラスのセットをオプション・パッケージ・ファイルにまとめることができます。共有クラスのコレクションは、最終的に標準JARアーカイブにパッケージ化されます。ただし、JARのマニフェスト・ファイルを編集する必要があるので、最初にすべてのクラス・ファイルを作業ディレクトリに作成します。
親トピック: 共有Java EEライブラリの作成
共有Java EEライブラリのマニフェスト属性の編集
共有Java EEライブラリの名前とバージョン情報は、META-INF/MANIFEST.MF
ファイルで指定します。表13-1で、有効な共有Java EEライブラリ・マニフェストの属性を示します。
表13-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ライブラリの作成
配布およびデプロイメント用共有Java EEライブラリのパッケージ化
管理者によるデプロイメント用に共有Java EEライブラリまたはオプション・パッケージを配布する場合、デプロイメント・ファイルをアーカイブ・ファイル(共有Java EEライブラリの場合は.EAR
ファイルまたはスタンドアロン・モジュール・アーカイブ・ファイル、オプション・パッケージの場合は単純な.JAR
ファイル)にパッケージ化して配布します。「wldeployを使用したアプリケーションのデプロイメント」を参照してください。
共有Java EEライブラリは標準Java EEアプリケーションまたはスタンドアロン・モジュールとしてパッケージ化されるため、『Oracle WebLogic Serverへのアプリケーションのデプロイ』で説明されているように、ライブラリのデプロイメント構成をデプロイメント・プランにエクスポートすることもできます。オプション・パッケージ.JAR
ファイルにはデプロイメント記述子が含まれていないため、エクスポートすることはできません。
開発目的で、展開されたアーカイブ・ディレクトリとしてライブラリをデプロイすると、更新と再デプロイメントの繰返しが簡単になります。
親トピック: 共有Java EEライブラリの作成
エンタープライズ・アプリケーションでの共有Java EEライブラリの参照
Java EEアプリケーションは、アプリケーションのweblogic-application.xml
デプロイメント記述子のエントリを基に、登録された共有Java EEライブラリを参照できます。
表13-2では、ライブラリ参照を定義するXML要素を示します。
表13-2 weblogic-application.xmlの共有Java EEライブラリ参照用の要素
要素 | 説明 |
---|---|
|
|
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>
参照されたエンタープライズ・ライブラリ内のcontext-rootのオーバーライド
Java EEアプリケーションは、weblogic-application.xml
デプロイメント記述子内のエントリを使用して、参照されたEARライブラリ内のcontext-root
をオーバーライドできます。表13-3では、ライブラリ参照においてcontext-root
をオーバーライドするXML要素について説明します。
表13-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
を宣言することです。
スタンドアロン・モジュールとしてデプロイされた共有Java EEライブラリのURI
スタンドアロン・モジュール(EJBまたはWebアプリケーション)としてデプロイされた共有Java EEライブラリのURIを参照する場合、モジュールURIは、共有Java EEライブラリのデプロイメント名に対応している必要があります。これは、デプロイメント時に手動で割り当てた名前でも、デプロイされたアーカイブ・ファイルの名前でも、デプロイされた展開アーカイブ・ディレクトリの名前でもよいです。同じモジュールを異なるファイル名で、または別の場所から再デプロイする場合、デフォルト・デプロイメント名も変わるため、適切なURIを使用するように参照側アプリケーションを更新する必要があります。
この問題を避けるには、すべての共有Java EEライブラリを、スタンドアロン・モジュールではなく、エンタープライズ・アプリケーションとしてデプロイします。スタンドアロンJava EEモジュールとしてライブラリをデプロイする場合は、既知のデプロイメント名を必ず指定し、参照側アプリケーションでその名前をURIとして使用します。
Java EEアプリケーションまたはモジュールからのオプション・パッケージの参照
Java EEアーカイブ(JAR、WAR、RAR、EAR)は、アーカイブのマニフェスト・ファイルの属性を使用して1つまたは複数の登録済みオプション・パッケージを参照できます。
表13-4 オプション・パッケージ参照用のマニフェスト属性
属性 | 説明 |
---|---|
|
オプション・パッケージの依存関係の論理名を定義する文字列値(必須)。 Extension-List: dependency1 dependency2 |
[ logical_name-]Extension-Name |
オプション・パッケージの依存関係の名前を識別する文字列値(必須)。この値は、オプション・パッケージのマニフェスト・ファイルで定義された 1つのアーカイブから複数のオプション・パッケージを参照する場合は、
|
[ logical_name-]Specification-Version |
オプション・パッケージの必要な仕様バージョンを定義する文字列値(オプション)。この要素を設定しなかった場合、アーカイブは最新の仕様バージョンに一致するパッケージを使用します。メジャー/マイナー・バージョン・フォーマットで メジャー/マイナー・バージョニング規約に従っていない文字列値(9.2BETAなど)を指定した場合、アーカイブでは、パッケージのマニフェスト・ファイルの 1つのアーカイブから複数のオプション・パッケージを参照する場合は、 |
[ logical_name-]Implementation-Version |
オプション・パッケージの必要な実装バージョンを指定する文字列値(オプション)。この要素を設定しなかった場合、アーカイブは最新の実装バージョンに一致するパッケージを使用します。メジャー/マイナー・バージョン・フォーマットで文字列値を指定した場合、アーカイブは設定した値を下回らない最新の実装バージョンに一致するパッケージを使用します。使用可能なすべてのライブラリが、構成された メジャー/マイナー・バージョニング規約に従っていない文字列値(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を使用したライブラリの結合
weblogic.appmerge
を使用し、ディスクに書き込んだ結合されたアプリケーションを調べることで、ライブラリの結合を理解することもできます。
weblogic.appmerge
はライブラリを1つのアプリケーションに結合するために使用するツールです(コンテンツと記述子がそれぞれ結合されます)。結合されたアプリケーションをディスクに書き込む機能もあります。
CLIからのweblogic.appmergeの使用
次の構文を使用してweblogic.appmerge
を呼び出します。
java weblogic.appmerge [options] <ear, jar, war file, or directory>
有効なオプションを表13-5に示します。
表13-5 weblogic.appmergeのオプション
オプション | 説明 |
---|---|
-help |
標準の使用方法メッセージを出力します。 |
-version |
バージョン情報を出力します。 |
-output <file> |
代替的な出力アーカイブまたはディレクトリを指定します。これが設定されていないと、出力はソース・アーカイブまたはディレクトリに置かれます。 |
-plan <file> |
デプロイメント・プラン(オプション)を指定します。 |
-verbose |
より冗長な出力を提供します。 |
-library <file> |
ライブラリのカンマ区切りのリスト。各ライブラリは、マニフェストで設定されていない場合、その名前とバージョンを次の構文で設定できます。
|
-librarydir <dir> |
指定したディレクトリ内のすべてのファイルをライブラリとして登録します。 |
-writeInferredDescriptors |
アプリケーションまたはモジュールに、デプロイメント記述子がアノテーション情報と共に格納されることを指定します。 |
例:
$ java weblogic.appmerge -output CompleteSportsApp.ear -library Weather.war,Calendar.ear SportsApp.ear
Antタスクとしてのweblogic.appmergeの使用
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>
分割開発ディレクトリ環境への共有Java EEライブラリの統合
基本的なbuild.xmlファイルを共有Java EEライブラリ・ディレクトリ内に生成した後、分割開発ディレクトリでアプリケーションを構築することができます。
BuildXMLGen
には、1つまたは複数の共有Java EEライブラリ・ディレクトリを含むビルド・ターゲットを生成するための-librarydir
オプションがあります。「weblogic.BuildXMLGenを使用した基本的なbuild.xmlファイルの生成」を参照してください。
wlcompile
およびwlappc
Antタスクには、アプリケーション・ビルドのクラスパスに含める1つまたは複数の共有Java EEライブラリを指定するためのlibrarydir
属性とlibrary
要素があります。「分割開発ディレクトリでのアプリケーションのビルド」を参照してください。
共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ
共有Java EEライブラリを1つまたは複数のWebLogic Serverインスタンスに登録するには、ターゲット・サーバーにライブラリをデプロイし、デプロイメントが共有されるように指定します。共有Java EEライブラリは、ライブラリを参照するアプリケーションのデプロイ先と同じWebLogic Serverインスタンスに登録する必要があります。
必要なライブラリを登録していないサーバー・インスタンスに参照側アプリケーションをデプロイする場合、参照側アプリケーションのデプロイメントは失敗します。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverでのライブラリの登録に関する項を参照してください。
WebLogic Server管理コンソールを使用して共有Java EEライブラリをインストール(デプロイ)する場合の詳細な手順については、「Java EEライブラリのインストール」 を参照してください。WebLogic Server管理コンソールを使用して、ライブラリを参照するアプリケーションのデプロイ先となるサーバーまたはクラスタにライブラリをデプロイする場合の手順については、「Java EEライブラリのサーバーまたはクラスタへの割当て」 を参照してください。
繰返しの開発プロセスの一部としてwldeploy
Antタスクを使用する場合は、library
、libImplVer
、およびlibSpecVer
属性を使用して共有Java EEライブラリをデプロイします。詳細およびその他のサンプルについては、wldeploy Antタスクのリファレンスを参照してください。
共有Java EEライブラリを登録後、そのライブラリと依存関係にあるアプリケーションおよびアーカイブをデプロイできます。依存関係にあるアプリケーションは、ターゲット・サーバーが必要なすべてのライブラリを登録していて、登録されたデプロイメントがアプリケーションまたはアーカイブのバージョン要件に従っている場合にのみデプロイできます。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のライブラリを参照するアプリケーションのデプロイに関する項 を参照してください。
Webアプリケーション共有Java EEライブラリの情報
一部の共有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ライブラリの場合と同じです。
WebアプリケーションにおけるWebアプリケーション・ライブラリの使用
標準の共有Java EEアプリケーションをアプリケーション・ライブラリとしてWebLogic Serverにデプロイできるのと同様に、標準のWebアプリケーションをWebアプリケーション・ライブラリとしてWebLogic Serverにデプロイし、他のWebアプリケーションがこれらのライブラリを参照できるようにすることが可能です。
Webアプリケーション・ライブラリを使用するとコードとリソースの再利用が容易になります。また、Webアプリケーションが使用する可能性のあるサード・パーティのWebアプリケーションまたはフレームワークを分離するのにも役立ちます。さらに、共通のリソースをライブラリとして個別にパッケージ化し、様々なWebアプリケーションで参照されるようにすることもできます。こうすると、そのリソースを各Webアプリケーションにバンドルする必要がなくなります。WebアプリケーションにWebアプリケーション・ライブラリを含める場合、コンテナはデプロイメント時に、すべての静的リソース、クラス、およびJAR
ファイルをWebアプリケーションに結合します。
Webアプリケーション・ライブラリを使用する最初のステップは、Webアプリケーションをwebapp-library
として登録することです。それには、WebLogic Server管理コンソールまたは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
要素が出現する順序に従います。
LibraryRuntimeMBeanに登録された共有Java EEライブラリ情報へのアクセス
様々なMBeanを使用して共有Java EEライブラリに関する情報を取得したり、アプリケーションで使用されるライブラリにアクセスしたりできます。
デプロイされた各共有Java EEライブラリは、LibraryRuntimeMBean
で表されます。このMBeanを使用すると、名前やバージョンなど、ライブラリ自体の情報を取得できます。また、デプロイされたアプリケーションに関連付けられたApplicationRuntimeMBean
を取得することもできます。ApplicationRuntimeMBean
では、アプリケーションが使用するライブラリにアクセスする際に、次の2種類の方法を用いることができます。
-
getLibraryRuntimes()
は、weblogic-application.xml
ファイルで参照される共有Java EEライブラリを返します。 -
getOptionalPackageRuntimes()
は、マニフェスト・ファイルで参照されるオプション・パッケージを返します。
『Oracle WebLogic Server Java APIリファレンス』を参照してください。
共有Java EEライブラリの参照時のモジュールの優先順位
エンタープライズ・アプリケーションが1つまたは複数の共有Java EEライブラリを参照し、アプリケーションがWebLogic Serverにデプロイされている場合、サーバーは内部で参照側のエンタープライズ・アプリケーションのweblogic-application.xml
ファイルの情報を参照されるライブラリのデプロイメント記述子の情報に結合します。
WebLogic Serverが内部で情報を結合する順序は次のとおりです。
-
エンタープライズ・アプリケーションがデプロイされると、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ライブラリを使用する場合のベスト・プラクティス
共有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ライブラリをデプロイします。参照側アプリケーションのデプロイ先となるサーバー・インスタンスにライブラリが登録されていない場合、参照側アプリケーションのデプロイメントは失敗します。