| Oracle Containers for J2EE開発者ガイド 10g（10.1.3.5.0） B56031-01 |
|
 戻る |
 次へ |
この章では、Oracle Containers for J2EE（OC4J）にデプロイされているアプリケーションに対してクラス・ロードおよび共有ライブラリを使用する方法について説明します。OC4Jクラス・ロード・フレームワークを使用するためのガイドライン、一般的なクラス・ローダー問題を回避するための推奨策、およびピークOC4Jランタイム・インスペクタ（ピーク）のクラス・ロード機能に関する情報を示します。
次の項目が含まれています。
この項には、次の内容が含まれています。
クラスのロードという用語は、特定のクラス名に対するバイトを探し、それをJavaクラスのインスタンスに変換する処理のことを示します。Java Virtual Machine（JVM）内のすべてのクラス・インスタンスは、バイトの配列として開始され、JVM仕様で定義されているクラス・ファイル形式で構成されています。
クラスのロードは、起動プロセスの間はJVMによって実行され、それ以降は、java.lang.ClassLoaderクラスのサブクラスであるクラス・ローダーが実行時にクラス・ファイルを検出してロードします。クラス・ローダーが提供する抽象化により、ローカルやリモートの記憶域だけでなく動的なクラスの生成について、クラス・バイトの検出先が不明でもJVMでクラスをロードできます。
クラス・ローダーは、1つ以上のコード・ソースを処理します。コード・ソースは、クラス・ローダーがクラスを検索するルートとなる場所です。コード・ソースは、バイナリ・クラス・ファイルの物理記憶域、最初にコンパイルする必要のあるJavaソースを示すように、または実行中に生成されるクラスを示すようにも定義できます。
標準のクラス・ローダーは、親子の階層として相互にリンクされており、各クラス・ローダーには親のクラス・ローダーが関連付けられています。この階層は、単純なチェーンや複数に枝分かれしたツリーなど、様々なツリーになります。
このような階層において、子のクラス・ローダーは、親のローダーからクラス・ローダーのセットをインポートします。OC4Jのコンテキストでは、OC4Jインスタンス内で実行するすべてのJ2EEアプリケーションは、systemアプリケーションの子です。結果として、アプリケーション・レベルで作成されるクラス・ローダーは、system.rootクラス・ローダーから一連のクラス・ローダーをインポートします。
図3-1は、ピークを使用してOC4Jインスタンスを実行するためのクラス・ローダー階層を示しています。この画面は、ピークの表示メニューから「ローダー」を選択すると表示されます。ピーク・ユーティリティの詳細は、「クラス・ローダーをデバッグするためのピーク・ユーティリティ」を参照してください。
ピークOC4Jランタイム・インスペクタを使用すると、共有ライブラリとコード・ソースの検索、OC4Jクラス・ローダー・ツリーの表示、およびOC4Jランタイムの様々な局面の検証を行うことができます。ピークはOC4Jインスタンスのdefault Webアプリケーションに組み込まれており、次のURIからアクセス可能です。
OC4Jスタンドアロン（oc4j_extended.zip）:
http://localhost:8888/peek/
Oracle Application Server
http://localhost:instance_port/j2ee/peek
Oracle Application ServerでのOC4Jの詳細は、『Oracle Containers for J2EE構成および管理ガイド』のOracle Application Server構成でのOC4Jに関する項を参照してください。
ピークにログオンするには、OC4Jの最初の初期化時に設定したoc4jadminユーザー名およびパスワードを使用します。
ピーク・ユーティリティを使用すると、次のタスクを実行できます。
コード・ソース（JAR、ZIPまたはディレクトリ）を名前またはパス・コンポーネントで検索できます。検索文字列には、ワイルドカード文字および正規表現を含めることができます。テキスト・フィールドに名前を入力して「実行」をクリックするだけです。
図3-2は、oc4j.jarコード・ソースを検索した結果の出力を示しています。
すべてのコード・ソースの内容からクラスまたはリソース名を検索できます。検索文字列には、ワイルドカード文字および正規表現を含めることができます。テキスト・フィールドに完全修飾名を入力して「実行」をクリックするだけです。
図3-3は、java.lang.Stringリソースを検索した結果の出力を示しています。この出力は、リソースが検出されたコード・ソースとクラス・ローダーを示しています。
図3-1のようなクラス・ローダー・ツリーを表示し、その内容を参照できます。
各ローダー名およびカテゴリ、共有ライブラリの場合は説明と連絡先情報（使用可能な場合）
コード・ソース
ロードされたクラス
すべてのクラス（ハイパーリンク付き）
すべてのテキスト・ベース・リソース
事前定義済の問合せを実行して、OC4Jランタイムの様々な局面を検証できます。
たとえば、loadClass問合せを使用して、指定したクラス・ローダーからのクラスのロードを試行できます。また、AuditLoader問合せを使用して、クラス・ローダー（共有ライブラリ）を検証することもできます。
すべての操作はURLを介して行われるため、いずれの問合せ実行にもリンクまたはブックマークを設定できます。
たとえば、次のようにURLにブックマークを設定して、OC4Jインスタンスにロードされた重複しているクラスを一覧表示できます。
http://localhost:8888/query?q=DuplicateClasses
クラス・ローダーの階層では、OC4JインスタンスにデプロイされたJ2EEアプリケーションは、デフォルトでdefaultアプリケーションから一連のライブラリを継承することが保証されます。このアプリケーションにバインドされたWebモジュールは、アプリケーションから一連のクラスを継承し、さらにOC4Jのアプリケーション階層のルートにあるsystemアプリケーションから継承されたクラスも継承します。
ただし、デフォルト以外のバージョンのライブラリやクラスがアプリケーションまたはモジュールで必要な場合は、このような継承モデルが望ましくない場合もあります。OC4Jのクラス・ロード・インフラストラクチャでは、この問題に対処するために、アプリケーションまたはモジュールに対して作成されたクラス・ローダーが、親クラス・ローダーがインポートしたデフォルト・バージョンとは異なるバージョンの共有ライブラリをインポートできるようになっています。アプリケーションまたはローダーは、継承したクラス・ローダーのセット全体から特定のクラス・ローダーを削除することもできます。
図3-4は、OC4Jにおけるクラス・ローダーのツリー構造を示しています。
jre.bootstrapローダーは、JVMに組み込まれているネイティブ・ブートストラップ・ローダーに対するプロキシです。ネイティブ・ブートストラップ・ローダー自体が実行時に直接参照されることはありません。
jre.extensionローダーは、JREが提供する拡張ローダーのかわりとなるカスタム・ローダーです。
apiローダーには、すべてのアプリケーションおよびすべてのOC4J内部クラスから参照できる必要があるJ2EEクラスとOC4J APIクラスが含まれます。
oc4jローダーには、OC4Jのシステム・クラスが含まれます。
system.rootローダーは、OC4Jのsystemアプリケーション用に作成されます。
systemはアプリケーション階層のルートにあるので、このローダーのクラスは、OC4Jインスタンスにデプロイされる他のすべてのアプリケーションにデフォルトで継承されます。
global.rootは、defaultアプリケーションに対して作成されるクラス・ローダーです。これは、OC4JインスタンスにデプロイされるすべてのJ2EEアプリケーションのデフォルトの親です。
app-name.rootは、デプロイされるアプリケーションに対するルート・ローダーです。
app-name.web.web-mod-nameクラス・ローダーは、それぞれがWARファイルにパッケージされているクラスであるWebモジュールを含みます。
app-name.jsp.jsp nameは、コンパイル済のJSP実装クラスをロードします。
OC4Jの共有クラス・ローダーであるoracle.jdbc:10.1.0_2、oracle.jdbc:9.2.0_5、oracle:xml:10_1_02およびxerces:xml:2.6.2は、OC4Jインスタンスで宣言されている共有ライブラリを表します。各共有ライブラリの定義は、次の項目で構成されます。
共有ライブラリ名（xerces.xmlなど）
通常は共有ライブラリの実装バージョンを表すバージョン番号（2.6.2など）
ライブラリを構成するクラスを含む1つ以上のコード・ソース（JARファイルまたはZIPファイル）
クラス・ローダーは、OC4Jインスタンス内の共有ライブラリ定義に基づいて実行時に作成されます。クラス・ローダーは、共有ライブラリ名とバージョン番号を連結したものを使用して登録されます（xerces.xml:2.6.2など）。
共有ライブラリの作成とインストールの方法の詳細は、「OC4Jでの共有ライブラリのインストールと公開」を参照してください。
デプロイされている3つのアプリケーションが、JDBCドライバ・クラスとXMLパーサー・クラスをロードする方法は次のとおりです。アプリケーション1は、デフォルトの動作に従って、共有ローダーoracle.jdbc:10_1_02とoracle:xml:10_1_02に含まれるクラスを親から継承しています。一方、アプリケーション2とアプリケーション3は、それぞれが使用する代替ドライバ・クラス・ローダーと代替パーサー・クラス・ローダーをインポートしています。
デフォルトでは、アプリケーションは、systemアプリケーションから継承されたライブラリも含めて、親アプリケーションに存在する同じ一連の共有ライブラリを継承します。つまり、たとえば、アプリケーションはデフォルトでOracle JDBCドライバとOracle XMLパーサーを使用します。これはsystemアプリケーションから継承されるものです。
一方、OC4Jのクラス・バージョニング機能を使用すると、継承されるライブラリを別のバージョンでオーバーライドしたり、ともに継承されるライブラリのリストから、あるライブラリを削除したりできます。
OC4Jインスタンス内のすべてのアプリケーション・クラス・ローダーによってインポートされる共有ライブラリのデフォルトのセットは、ORACLE_HOME/j2ee/instance/system-application.xmlの<imported-shared-libraries>要素で指定されています。これはsystemアプリケーション用の構成ファイルで、アプリケーション階層のルートにあるOracle Containers for J2EEの内部コンポーネントであり、クラスとOC4Jの起動に必要な構成を提供します。ピークを使用してインポート済共有ライブラリを表示するには、次のURLを使用します。
http://localhost:8888/peek/loader/system.root:0.0.0
デフォルトでは、OC4Jインスタンスにデプロイされたアプリケーションは、次のOracle共有ライブラリを継承します。
oracle.dms:3.0
oracle.jdbc:10.1.0_2
oracle.gdk:10.1.0_2
oracle.xml:10.1.0_2
oracle.xml.security:10.1.3
oracle.toplink:10.1.3
oracle.persistence:1.0
oracle.ws.jaxrpc:1.1
oracle.ws.client:10.1.3
oracle.cache:10.1.3
soap:10.1.3
oracle.sqlj:10.1.3
oracle.jwsdl:10.1.3
global.libraries:1.0
global.tag.libraries:1.0
oracle.http.client:10.1.3
org.jgroups:2.3
system-application.xmlで宣言されている共有ライブラリと同じ名前の共有ライブラリを作成し、異なるバージョン番号を割り当てることで、system-application.xmlで宣言されているものとは異なるバージョンの共有ライブラリをアプリケーションで強制的にインポートできます。その場合、この共有ライブラリをインポートするようにアプリケーションを構成します。
詳細は次の項を参照してください。
エンドツーエンドの例については「例: 旧バージョンのOracle JDBCドライバのインポート」
もう1つの完全な例については「例: DataDirect JDBCドライバを使用するアプリケーションの構成」
共有ライブラリを作成するためのその他のオプションについては「OC4Jでの共有ライブラリのインストールと公開」
特定の共有ライブラリをインポートするようにアプリケーションを構成するための追加オプションについては「共有ライブラリをインポートするためのアプリケーションの構成」
次の例では、OC4J 10g（10.1.3.5.0）にパッケージされているバージョンよりも前のバージョンのOracle JDBCドライバであるOracle 9.2.0_5 JDBCドライバを使用するように、アプリケーションを構成する方法を示します。この例は、このシンJDBCドライバのみに適用され、Oracle Call Interface（OCI）ドライバには適用されません。
手順1: OC4Jで共有ライブラリを作成する
「共有ライブラリをインストールおよび公開するためのオプション」で説明されているいずれかのメカニズムを使用して、9.2.x JDBCドライバ用の共有ライブラリをインストールできます。この例は、Application Server Controlでこのタスクを行う方法を示しています。
|
注意: OC4JにパッケージされていないJDBCドライバを使用するには、アプリケーションで特に使用するためのマネージド・データソースを作成した後、それを使用するようにアプリケーションを構成する必要があります。アプリケーションで使用するデフォルトのJDBCドライバとデータソースはグローバル アプリケーション固有のマネージド・データソースを作成して使用する方法の詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。 |
「管理」→「共有ライブラリ」の順にクリックします。デフォルトのJDBCドライバ共有ライブラリoracle.jdbc:10.1.0_2を確認します。
「作成」をクリックします。
共有ライブラリの名前を入力します。この場合は、既存のライブラリと同じ名前のoracle.jdbcを入力します。
共有ライブラリのバージョンとして、この場合は9.2.0_5と入力します。
「追加」をクリックして、ライブラリのJARファイルをOC4Jインスタンスにアップロードします。次の共有ライブラリ宣言がORACLE_HOME/j2ee/instance/server.xmlファイルに追加されます。
<shared-library name="oracle.jdbc" version="9.2.0_5">
<code-source path="ojdbc14.jar"/>
</shared-library>
手順2: 共有ライブラリを使用するようにアプリケーションを構成する
共有ライブラリをOC4Jに作成すると、OC4Jとともにインストールされるデフォルトの共有ライブラリのかわりにそれを使用するように、アプリケーションを構成できます。
次の例では、アプリケーションのデプロイ時に、Application Server Controlを使用してこれを行う方法を示します。
「アプリケーション」→「デプロイ」をクリックして、Application Server Controlのデプロイ・ウィザードを起動します。
ウィザードの最初のページで、アプリケーションへのパスを指定します。
2番目のページでは、アプリケーションの名前とコンテキストURIマッピングを指定します。
ウィザードの3ページ目（「デプロイ: デプロイ設定」）では、「クラスのロードの構成」をクリックします。
oracle.jdbc共有ライブラリの両方のバージョンが「共有ライブラリのインポート」に表示されます。
「使用する最高バージョン」列で、使用するバージョン番号（9.2.0_5）を指定します。
アプリケーションをデプロイします。
アプリケーションをデプロイすると、アプリケーションのorion-application.xmlデプロイメント・ディスクリプタに次のエントリが含まれます。
<imported-shared-libraries> <import-shared-library name="oracle.jdbc" max-version="9.2.0_05"/> </imported-shared-libraries>
Oracle Application Serverディストリビューションには、Oracle以外のデータベースに接続するためのJDBCドライバがいくつか含まれています。次の例では、DataDirect Sybaseドライバを使用してSybaseデータベースに接続するようにアプリケーションを構成する方法を示します。
手順1: OC4Jで共有ライブラリを作成する
「共有ライブラリをインストールおよび公開するためのオプション」で説明されているいずれかのメカニズムを使用して、ドライバ用の共有ライブラリをインストールできます。この例では、Application Server Controlでこのタスクを行う方法を示します。
「管理」→「共有ライブラリ」の順にクリックします。
「作成」をクリックします。
共有ライブラリの名前（たとえばsybase.jdbc）を入力します。
共有ライブラリのバージョン番号（1.0など）を入力します。
「追加」をクリックして、ライブラリのJARファイルをOC4Jインスタンスにアップロードします。Oracle Application Serverで提供されているいずれかのDataDirectドライバを使用するには、YMbase.jarファイルとYMutil.jarファイルが必要であることに注意してください。
YMsybase.jar
YMbase.jar
YMutil.jar
次の共有ライブラリ宣言がORACLE_HOME/j2ee/instance/server.xmlファイルに追加されます。
<shared-library name="sybase.jdbc" version="1.0">
<code-source path="YMbase.jar"/>
<code-source path="YMutil.jar"/>
<code-source path="YMsybase.jar"/>
</shared-library>
手順2: 共有ライブラリを使用するようにアプリケーションを構成する
共有ライブラリをOC4Jに作成すると、OC4Jとともにインストールされるデフォルトの共有ライブラリのかわりにそれを使用するように、アプリケーションを構成できます。
次の例では、アプリケーションのデプロイ時に、Application Server Controlを使用してこのタスクを行う方法を示します。
「アプリケーション」→「デプロイ」をクリックして、Application Server Controlのデプロイ・ウィザードを起動します。
ウィザードの最初のページで、アプリケーションへのパスを指定します。
2番目のページでは、アプリケーションの名前とコンテキストURIマッピングを指定します。
ウィザードの3ページ目（「デプロイ: デプロイ設定」）では、「クラスのロードの構成」をクリックします。
sybase.jdbc共有ライブラリの「インポート」チェック・ボックスを選択します。必要であれば、使用する最高バージョンとして1.0を指定します。
アプリケーションをデプロイします。
アプリケーションをデプロイすると、アプリケーションのorion-application.xmlデプロイメント・ディスクリプタに次のエントリが含まれます。
<imported-shared-libraries> <import-shared-library name="sybase.jdbc" max-version="1.0"/> </imported-shared-libraries>
共有ライブラリ・フレームワークでは、アプリケーションが親から継承した共有ライブラリのセットから、特定の共有ライブラリを削除できます。また、必要に応じて、かわりに別の共有ライブラリをインポートすることもできます。
アプリケーションがデフォルトで継承した共有ライブラリは、アプリケーションのorion-application.xmlデプロイメント・ディスクリプタの<imported-shared-libraries>内にある<remove-inherited>サブ要素を使用して削除できます。削除するライブラリの名前は、name属性の値として指定します。
たとえば、orion-application.xmlで次のエントリを指定すると、Oracle TopLink共有ライブラリがアプリケーションにインポートされません。
<orion-application>
<imported-shared-libraries>
<remove-inherited name="oracle.toplink"/>
</imported-shared-libraries>
</orion-application>
詳細な例については次の各項を参照してください。
次の例では、Application Server Controlを使用して、systemアプリケーションから継承されたデフォルトの共有ライブラリ・セットからOracle XMLパーサーを削除する方法を示します。また、アプリケーションがそのかわりにXerces XMLパーサーを使用するように設定します。
手順1: OC4Jで共有ライブラリを作成する
「共有ライブラリをインストールおよび公開するためのオプション」で説明されているいずれかのメカニズムを使用して、Xercesパーサー用の共有ライブラリをインストールできます。この例は、Application Server Controlでこのタスクを行う方法を示しています。
「管理」→「共有ライブラリ」の順にクリックします。
「作成」をクリックします。
共有ライブラリの名前を入力します。この例では、xerces.xmlと入力します。
共有ライブラリのバージョンとして、この場合は2.5.0と入力します。
「追加」をクリックして、ライブラリのJARファイルをOC4Jインスタンスにアップロードします。次のApacheライブラリをアップロードします。
xercesImpl.jar
xml-apis.jar
次の共有ライブラリ宣言がORACLE_HOME/j2ee/instance/server.xmlファイルに追加されます。
<shared-library name="xerces.mxl" version="2.5.0">
<code-source path="xercesImpl.jar"/>
<code-source path="xml-apis.jar"/>
</shared-library>
手順2: 共有ライブラリを使用するようにアプリケーションを構成する
共有ライブラリをOC4Jに作成すると、OC4JとともにインストールされるデフォルトのパーサーのかわりにXercesパーサーを使用するように、アプリケーションを構成できます。
次の例では、アプリケーションのデプロイ時に、Application Server Controlを使用してこれを行う方法を示します。
「アプリケーション」→「デプロイ」をクリックして、Application Server Controlのデプロイ・ウィザードを起動します。
ウィザードの最初のページで、アプリケーションへのパスを指定します。
2番目のページでは、アプリケーションの名前とコンテキストURIマッピングを指定します。
ウィザードの3ページ目（「デプロイ: デプロイ設定」）では、「クラスのロードの構成」をクリックします。
xerces.xml共有ライブラリの「インポート」チェック・ボックスを選択します。必要であれば、使用する最高バージョンとして2.5.0を指定します。
Oracleパーサーを明示的に削除するには、oracle.xml共有ライブラリに対する「インポート」チェック・ボックスの選択を解除して、アプリケーションが継承する共有ライブラリのリストから削除します。
必要であれば、「デプロイ・プランの保存」ボタンをクリックして、再利用できるようにプランを保存します。
アプリケーションをデプロイします。アプリケーションをデプロイしたら、アプリケーションのorion-application.xmlファイルに次のエントリがあることを確認します。
<orion-application>
<imported-shared-libraries>
<remove-inherited name="oracle.xml"/>
<import-shared-library name="xerces.xml" max-version="2.5.0"/>
</imported-shared-libraries>
</orion-application>
次の例では、Application Server Controlを使用して、アプリケーションのデプロイ時に、Oracle TopLink共有ライブラリを削除する方法を示します。
「アプリケーション」→「デプロイ」をクリックして、Application Server Controlのデプロイ・ウィザードを起動します。
ウィザードの最初のページで、アプリケーションへのパスを指定します。
2番目のページでは、アプリケーションの名前とコンテキストURIマッピングを指定します。
ウィザードの3ページ目（「デプロイ: デプロイ設定」）では、「クラスのロードの構成」をクリックします。
oracle.toplink共有ライブラリに対する「インポート」チェック・ボックスの選択を解除して、アプリケーションが継承する共有ライブラリのリストから削除します。
必要であれば、「デプロイ・プランの保存」ボタンをクリックして、再利用できるようにプランを保存します。
アプリケーションをデプロイします。アプリケーションをデプロイしたら、アプリケーションのorion-application.xmlファイルに次のエントリがあることを確認します。
<orion-application>
<imported-shared-libraries>
<remove-inherited name="oracle.toplink"/>
</imported-shared-libraries>
</orion-application>
クラス・ロード・インフラストラクチャでは、XMLパーサーまたはJDBCドライバをJARとしてアプリケーションにパッケージし、OC4JでインストールされるOracle XMLパーサーまたはJDBCドライバのかわりにそれを使用するように設定できます。JARをOC4J内の共有ライブラリとして宣言する必要はありません。
この場合、デフォルトで継承されるOracleライブラリをorion-application.xmlの<remove-inherited>タグに指定します。orion-application.xmlは、JARとともにアプリケーションのEARファイルにパッケージされます。OC4Jにデプロイされた後、アプリケーションはOC4Jでインストールされるデフォルトのライブラリをインポートせず、かわりにアプリケーションのクラス・ローダーがパッケージされたライブラリを検出してロードします。
orion-application.xmlで次のように記述すると、アプリケーションのクラス・ローダーはOracle XMLパーサーをインポートしません。
<imported-shared-libraries> <remove-inherited name="oracle.xml"/> </imported-shared-libraries>
Webアプリケーションの場合は、アプリケーションのorion-web.xmlディスクリプタ・ファイルでの記述を通して、アプリケーションのWARファイルにバンドルされているクラスを使用するように指定できます。
まず、このファイルに<web-app-class-loader>要素を追加するか、またはこの要素のコメントを外します。次に、この要素のsearch-local-classes-first属性をtrueに設定すると、クラス・ローダーはWARにパッケージされているライブラリを検索してロードし、OC4Jでパッケージされている対応するライブラリではなく、このライブラリを使用します。
Application Server Controlでデプロイ時に行う方法の詳細は、「デプロイ時のsearch-local-classes-firstの指定」を参照してください。
orion-web.xmlのエントリは次のようになります。
<orion-web-app ...> ... <web-app-class-loader search-local-classes-first="true" include-war-manifest-class-path="true" /> ... </orion-web-app>
この方法は保証されたソリューションではありません。階層のさらに上位のアプリケーションが同じクラスを含む共有ライブラリをインポートした場合は、衝突が発生する可能性があります。このような衝突はデバッグすることが困難です。可能なかぎり、この章で解説されている共有ライブラリ・メカニズムを使用し、Webアプリケーションが正しいライブラリを使用するようにする必要があります。
次の例では、デプロイ時にWebモジュールに対して生成されるorion-web.xmlファイルでsearch-local-classes-first属性を、Application Server Controlを使用して設定する方法を示します。
「アプリケーション」→「デプロイ」をクリックして、Application Server Controlのデプロイ・ウィザードを起動します。
ウィザードの最初のページで、アプリケーションへのパスを指定します。
2番目のページでは、アプリケーションの名前とコンテキストURIマッピングを指定します。
ウィザードの3ページ目（「デプロイ: デプロイ設定」）では、「クラスのロードの構成」をクリックします。
「Webモジュールのクラス・ローダーの構成」で、使用するローカルJARファイルを含むWebモジュールの名前の隣の「最初にローカル・クラスを検索」チェック・ボックスを選択します。
必要であれば、「デプロイ・プランの保存」ボタンをクリックして、再利用できるようにプランを保存します。
OC4Jインスタンスでの共有ライブラリの作成は、基本的に2つの手順から成る処理です。最初に、共有ライブラリを構成するバイナリを、OC4J内の適切なディレクトリにインストールする必要があります。その後、OC4Jサーバー構成ファイル（server.xml）で共有ライブラリを宣言する必要があり、共有ライブラリは原則的にOC4Jインスタンス内に公開されます。
この項には、次の内容が含まれています。
通常、OC4Jにデプロイされるアプリケーションは、OC4Jにパッケージされた共有ライブラリのセットを使用します。これは、systemアプリケーションから継承されます。ただし、アプリケーションの親から継承したライブラリの置換または削除が必要になる場合があります。たとえば次のような場合です。
OC4Jにパッケージされているバージョンとは異なるバージョンのOracle JDBCドライバを使用する場合
OC4JにパッケージされているOracle XMLパーサーをアプリケーションで使用する別のパーサーに置き換える場合
すべてのアプリケーションではなく、1つまたは複数の特定のアプリケーションで固有のクラスを共有する場合
StrutsやSpring Frameworkなどのオープン・ソース・ライブラリを、複数のWebアプリケーションで利用できるようにする場合
OC4Jでは、1つまたは複数のOC4Jインスタンスに共有ライブラリをインストールして公開するためのオプションがいくつか用意されています。これらのメカニズムはいずれも、共有ライブラリをORACLE_HOME/j2ee/instance/shared-libディレクトリにインストールし、server.xmlに必要なエントリを作成します。
Oracle Enterprise Manager 10g Application Server Control
このオプションを使用すると、「管理」→「管理タスク」→「共有ライブラリ」から、特定のOC4Jインスタンスに共有ライブラリをインストールできます。
publishSharedLibrary Antタスク
このオプションを使用すると、スタンドアロンOC4Jサーバー、またはOracle Process Manager and Notification Server（OPMN）によって管理されているOracle Application Server環境の単一のOC4Jインスタンスに共有ライブラリをインストールできます。
admin_client.jarの-publishSharedLibraryコマンド
このオプションでも、OPMNで管理される単一のOC4JインスタンスまたはスタンドアロンOC4Jサーバーに共有ライブラリをインストールできます。
また、次の「OC4Jインスタンス内で共有ライブラリをインストールして公開する方法」で解説されている手順に従って、手動でOC4Jインスタンス内に共有ライブラリをインストールして公開することもできます。
|
注意: JDK 1.4を使用している場合は、Oracle Application Server 10.1.3は共有ライブラリとしてJDKに搭載されているXalanライブラリの使用をサポートしません。Xalanライブラリを使用するには、次の2つの選択肢があります。
|
共有ライブラリは、OC4JのORACLE_HOME/j2ee/instance/shared-libディレクトリにインストールされます。この処理では、このディレクトリ内に正しいディレクトリ構造が作成された後、ライブラリを構成するJARまたはZIPファイルがそこにコピーされます。
OC4Jでは、この処理を自動化するツールがいくつか提供されています。概要については、「共有ライブラリのインストールと公開のオプション」を参照してください。
共有ライブラリを手動でインストールするには、次のようにします。
ピークを使用してクラスを検索することにより、OC4Jインスタンスにクラスがまだ存在していないことを確認します（「クラス・ローダーをデバッグするためのピーク・ユーティリティ」を参照）。
図3-5は、ピークで実行中のOC4Jインスタンスからパス名に*acme*が含まれるクラスを検索した結果を示しています。
次のようなディレクトリ構造を作成します。
ORACLE_HOME/j2ee/instance/shared-lib /library_name /version filename.jar filename.zip ...
ディレクトリ構造内の変数には次の値があります。
instanceはOC4Jインスタンスの名前で、Oracle Application Server環境ではデフォルトでhome、スタンドアロンOC4Jサーバーでは常にhomeです。
library_nameは、共有ライブラリの名前が付けられたディレクトリです（acme.commonなど）。
共通のAPIが複数のベンダーによって実装される場合は、ベンダー名とテクノロジの名称がディレクトリの名前に含まれている必要があります（たとえば、oracle.jdbcやxerces.xml）。テクノロジが単独のベンダーによって実装される場合は、テクノロジの名称のみで十分です。
versionは、共有ライブラリのバージョン番号を名前とするサブディレクトリです（たとえば2.5）。可能であれば、この値はコードの実装バージョンを反映している必要があります。
共有ライブラリを構成するクラスを含むJARファイルまたはZIPファイルそれぞれを、versionサブディレクトリにコピーします。たとえば、サンプルのライブラリがacme-apis.jarとacmeImpl.jarで構成されているものとします。前述の例を使用すると、OC4Jサーバー内に作成されるディレクトリ構造は次のようになります。
ORACLE_HOME/j2ee/instance/shared-lib
/acme.common
/2.5
acme-apis.jar
acmeImpl.jar
複数のバージョンの共有ライブラリを作成するには、次の例に示すように、各バージョンのアーカイブ・ファイルをversionサブディレクトリにインストールします。
ORACLE_HOME/j2ee/instance/shared-lib /acme.common /2.5 acme-apis.jar acmeImpl.jar /3.0 acme-apis.jar acmeImpl.jar
コード・ソースがインストールされると、ORACLE_HOME/j2ee/instance/server.xmlファイルに追加される<shared-library>要素内で共有ライブラリが定義されます。このファイルには、OC4Jインスタンスの構成データが含まれます。<shared-library>要素には次の属性とサブ要素が含まれます。
必須のname属性。この属性の値は、/shared-libディレクトリ内に作成されている共有ライブラリ・ディレクトリの名前と一致する必要があります。
必須のversion属性。この属性の値は、/shared-lib/library_nameディレクトリ内にある共有ライブラリのアーカイブ・ファイルを含むサブディレクトリの名前として使用されているバージョン番号と一致する必要があります。
1つ以上の<code-source>サブ要素。それぞれがライブラリに属するJARファイルまたはZIPファイルへのパスを定義するpath属性を含みます。
/shared-libディレクトリの外部の場合は、パスは絶対指定にします。それ以外の場合は、/shared-lib/library_nameディレクトリ内のJARファイルまたはZIPファイルを含むサブディレクトリに対する相対パスを指定できます。相対パスの場合は、pathの値としてアーカイブ・ファイル名のみを指定する必要があります。
次に、前述の例の共有ライブラリに対するserver.xml構成ファイルでの共有ライブラリ定義の例を示します。コード・ソースのパスは、/shared-lib/acme.commonディレクトリ内のJARまたはZIPファイルを含むサブディレクトリに対する相対指定です。したがって、アーカイブ・ファイル名のみがpathの値として指定されています。
<shared-library name="acme.common" version="2.5"> <code-source path="acme-apis.jar"> <code-source path="acmeImpl.jar"/> </shared-library>
path="*"と設定することで、サブディレクトリ内のすべてのアーカイブを使用するようにOC4Jに強制することができます。次に例を示します。
<shared-library name="acme.common" version="2.5"> <code-source path="*" /> </shared-library>
さらに、1つ以上の他の共有ライブラリをインポートするように、共有ライブラリを構成できます。<shared-library>要素では、1つ以上の<import-shared-library>要素を指定できます。この要素では、構成している共有ライブラリがインポートする共有ライブラリを指定します。インポート対象の共有ライブラリも、OC4Jホスト上にインストールされ、公開されている必要があります。
次のサンプル・コードでは、acme.common共有ライブラリがxyz.log共有ライブラリをインポートします。
<shared-library name="acme.common" version="2.5">
<import-shared-library name="xyz.log"/>
<code-source path="acme-apis.jar"/>
<code-source path="acmeImpl.jar"/>
</shared-library>
実行時に相対指定されたコード・ソースのパスが検出されると、共有ライブラリ・ディレクトリ（/shared-lib）、共有ライブラリ名およびバージョン番号が連結されて絶対パスが作成されます。たとえば、前述のサンプル・エントリは、これらのパスに対し次のように解決されます。
ORACLE_HOME/j2ee/instance/shared-lib/acme.common/2.5/acme-apis.jar ORACLE_HOME/j2ee/instance/shared-lib/acme.common/2.5/acmeImpl.jar
共有ライブラリをインストールすると、次のいずれかのオプションを使用して、共有ライブラリをインポートするようにアプリケーションを構成できます。
アプリケーションのOC4J固有のorion-application.xmlデプロイメント・ディスクリプタで、依存性を宣言します。
詳細は、「アプリケーションのOC4Jデプロイメント・ディスクリプタでの依存性の宣言」を参照してください。
アプリケーションのMANIFEST.MFファイルを使用して、依存性を宣言します。
これは、インストールされているライブラリに対する依存性を宣言するための、J2EEの標準的なメカニズムです。詳細は、「アプリケーションのマニフェスト・ファイルでの依存性の宣言」を参照してください。
defaultアプリケーションの構成ファイルであるapplication.xmlで依存性を宣言することで、OC4Jインスタンスにデプロイされているすべてのアプリケーションに、共有ライブラリの使用を強制します。defaultはインスタンスにデプロイされている他のすべてのアプリケーションの親であるため、共有ライブラリはこれらのアプリケーションにインポートされます。
詳細は、「すべてのデプロイ済アプリケーションで特定の共有ライブラリをインポートするための構成」を参照してください。
Application Server Controlで提供されているデプロイ・タスクを使用して、デプロイ時にアプリケーションが共有ライブラリをインポートするように構成します。この項で説明するように、デプロイ・タスク・メカニズムは、アプリケーションのorion-application.xmlファイルを更新します。
この機能を使用する方法の詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
|
注意: ここで示したいずれかのオプションを使用して依存性を宣言すると、その共有ライブラリはアプリケーションにとって必須になります。共有ライブラリがまだインストールされておらず、OC4Jインスタンス内で公開されていないと、エラーが発生します。 |
依存性は、依存するアプリケーションのorion-application.xmlデプロイメント・ディスクリプタに記述を追加することで宣言できます。
依存性を宣言するには、アプリケーション固有のorion-application.xml構成ファイルに<imported-shared-libraries>要素を追加します。この要素は1つ以上の<import-shared-library>サブ要素を取り、それぞれでインポートする共有ライブラリを指定します。
<import-shared-library>要素には次の属性があります。
name: 共有ライブラリの名前です。
min-versionおよびmax-version: 省略可能な属性で、ライブラリの最低バージョンと最高バージョンを指定できます。インストールされている最新のバージョンのライブラリを使用する場合は、バージョン番号を指定しません。
orion-application.xmlの次のエントリによって、アプリケーションで使用するacme.common:2.5共有ライブラリがインポートされます。
<imported-shared-libraries> <import-shared-library name="acme.common" max-version="2.6"/> </imported-shared-libraries>
オプション・パッケージとも呼ばれるJavaの標準拡張メカニズムを利用すると、共有ライブラリ内のJARまたはZIPファイルに対するアプリケーションの依存性を宣言できます。これは、インストールされているライブラリに対する依存性を宣言するための、J2EEの標準的なメカニズムです。
このメカニズムを使用するには、そのMANIFEST.MFファイルの中で、依存するJARまたはZIPファイルを名前付き拡張として宣言する必要があります。この名前はExtension-Name属性の値として指定します。たとえば、次に示すマニフェストのエントリでは、拡張としてacme.commonが定義されています。
Extension-Name: acme.common Specification-Vendor: Acme, Inc Specification-Version: 2.5 Implementation-Vendor-Id: com.acme Implementation-Vendor: Acme, Inc Implementation-Version: 2.5
次に、マニフェスト・ファイルの中で、共有ライブラリに依存するアプリケーションの依存性を宣言します。次に示すマニフェストの属性によって、アプリケーションはacme.common:2.5共有ライブラリをインポートします。name-Extension-Nameの値は、JARまたはZIPファイルのマニフェストで指定されているExtension-Nameの値と正確に一致します。
Extension-List: acme acme-Extension-Name: acme.common acme-Implementation-Version: 2.5
MANIFEST.MFファイルのSpecification-Version属性およびImplementation-Version属性のバージョン番号には、次のように最大8つの要素を含めることができます。
n1.n2.n3.n4.n5.n6.n7.n8
各要素に使用できる最大値は99999999です。
マニフェスト・ファイルを使用して依存性を宣言する方法の詳細は、次のWebサイトを参照してください。
http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html
OC4Jインスタンスにデプロイされているすべてのアプリケーションで、確実に同じバージョンの共有ライブラリを使用するには、その共有ライブラリをインポートするようにデフォルト・アプリケーションを構成します。defaultはOC4Jにデプロイされているすべてのアプリケーションの親であるため、defaultがインポートする共有ライブラリもこれらのアプリケーションにインポートされます。
構成を管理するには、「アプリケーションのOC4Jデプロイメント・ディスクリプタでの依存性の宣言」で示されているXMLの記述を、defaultアプリケーションの構成ファイルであるORACLE_HOME/j2ee/instance/application.xmlファイルに追加します。
application.xmlの次のエントリによって、デプロイされているすべてのアプリケーションで、確実にacme.common共有ライブラリのバージョン2.0が使用されます。
<imported-shared-libraries> <import-shared-library name="acme.common" max-version="2.0"/> </imported-shared-libraries>
アプリケーションに独自のバージョンの共有ライブラリが含まれていたとしても、アプリケーションはdefaultアプリケーションからインポートされるバージョンの共有ライブラリを使用することに注意してください。それが望ましくない場合は、「デフォルトでインポートされるOracle共有ライブラリの削除または置換」で説明されている処理を使用して、defaultからインポートされるバージョンを削除できます。
OC4J内のアプリケーション間でライブラリを共有するレガシー・メカニズムでは、共有されるJARまたZIPファイルはORACLE_HOME/j2ee/instance/applibディレクトリにインストールされますが、このメカニズムは現在のリリースのOC4Jでもまだサポートされています。このディレクトリ内のすべてのJARおよびZIPファイルは、global.libraries共有ライブラリに組み込まれて、OC4Jインスタンスのすべてのアプリケーションで利用できるようになります。
このレガシー機能のサポートは、今後のOC4Jのリリースで削除されます。できるだけこの章で説明されている新しい共有ライブラリ・メカニズムを使用することを、強くお薦めします。
application.xmlファイルの<library-directory>要素は、このOC4Jインスタンスに対してライブラリ・パスとして追加する、ディレクトリ、JARアーカイブまたはZIPアーカイブに対する、相対パス、絶対パスまたはURLを指定します。OC4Jの起動時に、アーカイブを含めるためにディレクトリがスキャンされます。
アプリケーション用のapplication.xmファイルがversion="5"属性セット（Java EE 5アプリケーション）を持っている場合、EARファイルのデプロイメント・ディスクリプタの<library-directory>要素は、アプリケーション・コンポーネントでライブラリを共有できるようにするためのライブラリ・ディレクトリの名前を含むことができます。
<application version="5">
<library-directory>app2lib</library-directory>
<module>
<ejb>ejb.jar</ejb>
</module></application>
<library-directory>要素が指定されていない場合、またはEARファイルがデプロイメント・ディスクリプタを含まない場合、libというディレクトリが使用されます。
ライブラリ・ディレクトリがないことを指定するために、空の<library-directory>要素を使用することができます。次に例を示します。
<application version="5">
<library-directory></library-directory>
<module>
<ejb>ejb.jar</ejb>
</module></application>
<library-directory>要素は、Java EE 5仕様で定義されているクラスパスの依存性を定義するための標準のメカニズムを提供します。OC4J 10g（10.1.3.5.0）では、ライブラリ・ディレクトリ内にある.jar拡張子の付いたすべてのファイル（サブディレクトリ内は除く）は、アプリケーション・クライアントを除くEARファイルに含まれたすべてのコンポーネントに対して使用できます。これらのJARファイル内にあるライブラリは、アプリケーションにバンドルされているか個別にインストールされたかにかかわらず、他のライブラリを参照することができます。
また、OC4J 10g（10.1.3.5.0）は、J2EE 1.4アプリケーション内の<library-directory>要素をサポートしますが、次の注意事項があります。
既存のアプリケーションに対する動作の予期せぬ変更を回避するための1.4アプリーケーション用のデフォルトlibディレクトリはありません。ユーザーは、このサポートを有効にするために<library-directory>要素をapplication.xmlファイルへ明示的に追加する必要があります。
1.4スキーマを使用している場合、<library-directory>要素を追加するJ2EE 1.4アプリケーションでは、XML検証を有効化できません。
orion-application.xmlファイルにある固有の<library>要素は、<library-directory>と同じ機能を提供します。
<library-directory>要素を使用するアプリケーションまたは空の<library-directory>要素を使用しないJava EE 5アプリケーションは、ライブラリ・ディレクトリ内でファイルを反復してこれらをクラスパスへ追加する、追加のデプロイ・ステップを持ちます。
この項では、クラスのロードに関する問題を回避するためのガイドラインについて説明します。
クラスの依存性を宣言する
アプリケーションのMANIFEST.MFファイルまたはorion-application.xmlファイルで、依存性を明示的に宣言します。参照されていない依存性または不明な依存性は、アプリケーションを別の環境に移動する際に放置されます。
依存性をグループ化する
すべての依存性が同じレベルまたはそれより上位のレベルで参照されるようにします。ライブラリを移動する必要がある場合は、すべての依存性が引き続き参照されていることを確認します。アプリケーション・リソース、依存するサード・パーティ製ライブラリおよび他のエンタープライズ・モジュールが、自己完結方式でパッケージされていることを確認します。
ライブラリを複製するのではなく共有する
ライブラリの複製は行わないようにします。複製すると、ディスクとメモリーの使用量が増え、バージョンの問題が発生する可能性があります。
ライブラリの可視性を最小限にする
依存ライブラリは、すべての依存性を満たす最も低い可視性レベルに置く必要があります。
構成の移植性を維持する
構成オプションを次の順序で選択します。
標準J2EEオプション
EARファイル内で表すことのできるオプション
サーバー・レベルのオプション
J2SE拡張オプション
正しいクラス・ローダーを確実に使用する
Class.forName()を呼び出すことでリフレクションを使用する場合は、Thread.currentThread().getContextClassLoaderによって返されるクラス・ローダーを常に明示的に渡します。プロパティ・ファイルをロードする場合、次のコードを使用します。
Thread.currentThread().getContextClassLoader().getResourceAsStream()
Class.forName()の呼出しのほうが、パフォーマンスがわずかに高いことと、キャッシュ・エントリが正確であることから、ClassLoader.loadClass()よりも推奨されます。
Class.forName()の呼出し中にstaticイニシャライザを実行する場合は、例3-1に示すように、ブール型フラグとしてtrueを使用します。パフォーマンスまたはセキュリティ上の理由からClass.forName()の呼出し中にstaticイニシャライザを実行しない場合は、メソッド・シグネチャ内にfalseを使用します。
OC4Jでは、クラス・ロード問題のトラブルシューティングおよび解決に役立つ構成オプションと組込み問合せが提供されています。
Javaでのクラス・ロード・エラーのほとんどは可視性に関するもので、原因は可視性の不足か、またはごくまれに可視性の過剰です。この場合の可視性とは、クラスパスで利用可能なクラスとリソースのセットのことです。クラスパスとは、一連のローダーとそれに含まれるコード・ソース（JARファイル、ZIPファイルおよびディレクトリなど）に対する検索パスです。
Java SEでのクラスパスは、通常、コマンドラインまたはメインJARのマニフェスト・ファイルで指定されているコード・ソースのリストと考えられています。これらのコード・ソースはすべて、一般にシステム・ローダーと呼ばれる単一のローダーでデプロイされます。このローダーは、JRE拡張ローダー（通常は、jre/lib/extディレクトリ内のJARファイル用）およびJREブートストラップ・ローダー（rt.jarなどを含む）という2つのローダーに結び付けられています。
1つのクラスパスが存在するという考え方は、誤解を招くことがよくあります。クラスの参照のたびに、検索は特定のローダーから開始して、（通常は）クラス・ローダー階層内のそのクラスより上のローダーのみを参照できます。つまり、拡張ローダーから開始する検索のクラスパスは、システム・ローダーから開始する場合のクラスパスと大きく異なることになります。
Java EEでは、単一のシステム・ローダーのかわりに複数のクラス・ローダーが必要であるため、状況はさらに複雑になります。デプロイされた各アプリケーションには、他のすべてのアプリケーションとは異なるローダーが少なくとも1つあるため、アプリケーションごとに個別のクラスパスが存在します。各Webモジュールは異なるローダーでデプロイされるため、たとえ単一のアプリケーションの中でも、異なるクラスパスが存在することがよくあります。
このことは、異なるモジュール内から次の呼出しを行うと簡単にわかります。
System.getProperty("java.class.path");
OC4Jでは、呼出し側モジュールに対して確実に正確なクラス・パスが返されます。
アプリケーションに対するクラスの可視性に影響を与える構成オプションがいくつもあります。表3-1は、OC4Jの最も一般的なオプションの一覧です。JavaEE環境において可能性のあるローダーとコード・ソースの組合せを考えると、可視性エラーがどのように発生するのかが簡単にわかります。多くの場合で、問題を除去するために必要なことは簡単な構成の変更のみですが、変更する内容を理解することが面倒な場合があります。
表3-1 クラスの可視性に影響を与える構成オプション
| クラス・ローダー | 構成オプション |
|---|---|
|
構成される共有ライブラリ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RARファイル: ルートにあるすべてのJARファイルおよびZIPファイル |
|
|
RARファイル: |
|
|
JARファイルおよびZIPファイルの上位のマニフェスト・クラスパス |
|
|
|
WARファイル: マニフェスト・クラスパス |
|
WARファイル: |
|
|
WARファイル: |
|
|
|
|
|
JARファイルの上位のマニフェスト・クラスパス |
|
|
|
|
|
共有ライブラリはアプリケーション・ルートから継承 |
OC4Jで提供されているいくつかの組込み問合せを実行して、クラス・ロードの問題のトラブルシューティングを行うことができます。図3-6は、ピークでのこれらの問合せのリストを示しています。
トラブルシューティングのための組込み問合せを指定するには、次のツールを使用できます。
ピーク
実行時のOC4Jインスタンスの情報を取得するには、ピーク・コマンドライン・ウィンドウで問合せを指定できます。詳細は、「ピークでの問合せの指定」を参照してください。
起動プロパティ
OC4Jの起動時に問合せが実行されるようにするには、スタンドアロンOC4JまたはOC4Jインスタンスのoc4j.start.queryシステム・プロパティ内でそのように指定する必要があります。コマンドラインからこのシステム・プロパティを設定する方法の詳細は、「起動プロパティでの問合せの指定」を参照してください。Application Server Controlを使用してOC4Jインスタンスに対してこのシステム・プロパティを設定する方法の詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
ClassLoading MBean
問合せは、ClassLoading MBeanを使用してプログラムにより指定することも、Application Server ControlのシステムMBeanブラウザを使用して指定することもできます。プログラムによりMBeansを使用する方法の詳細は、「クライアント・アプリケーションからMBeanへのアクセス」を参照してください。Application Server ControlでMBeansを使用する方法の詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
ピーク・コマンドライン・ウィンドウで、実行中のOC4Jインスタンスの情報を取得するための問合せや、問合せの引数を表示するための問合せを入力することができます。
ピークで問合せを指定するには、ピーク・コマンドライン・ウィンドウで問合せ名と引数を入力します。
図3-7は、ascontrol.web.ascontrol.jsp33119438:0.0.0ローダーに対する問合せを示しています。返されるリストが大きいため、図は切り捨てられています。
また、問合せのリストで問合せ名をクリックすると、その問合せの引数を表示できます（図3-6）。
問合せをoc4j.start.queryシステム・プロパティ内に指定できます。このプロパティは、OC4Jインスタンスの場合はasctlコマンドラインで、スタンドアロンOC4Jの場合はoc4j.jarコマンドラインで設定できます。
問合せの結果は、class.load.log.fileプロパティの値として指定したファイルに、またはファイルを指定しない場合はコンソール（System.out）に出力されます。OC4Jの次回の起動時または再起動時に問合せが実行されます。
class.load.log.fileプロパティの詳細は、「クラス・ローダーのログ・レベルの設定」を参照してください。
スタンドアロンOC4Jに対して起動プロパティ内に問合せを指定するには、次のようにします。
oc4j.start.queryシステム・プロパティ内に、接頭辞"-D"を付けて問合せ名を指定します。
システム・プロパティごとにコマンドラインで文字"-D"を接頭辞として入力する必要があります。oc4j.jarコマンドラインで問合せを指定するための構文は次のとおりです。
java -Doc4j.start.query=queryName(arg0[,arg1] . . .) -jar oc4j.jar
問合せに引数を渡すには、問合せ名に(arg0[,arg1] . . .)を追加します。引数はカッコで囲み、複数の引数はカンマを使用して区切ります。
|
注意: 一部のLinuxまたはUNIXシェルでは、プロパティの値の文字列（=記号より後にあるすべて）を引用符で囲む必要があります。 |
たとえば、DuplicateCodeSources問合せを-digest引数を指定して呼び出すには、次のように指定します。
java -Doc4j.start.query=DuplicateCodeSources(-digest) -jar oc4j.jar
起動パラメータ内に複数の問合せを指定するには、+文字で問合せを区切ります。
-Doc4j.start.query=DuplicateCodeSources(-digest)+UnusedCodeSources
ClassLoading MBeanでexecuteQuery操作を呼び出すことにより、稼働しているOC4Jインスタンスで問合せを実行できます。
このMBeanは、WebベースのApplication Server Controlインタフェースを介してアクセスできます。OC4JにパッケージされているMBeanのアクセスと使用の詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
ClassLoading MBeanを介して実行時に問合せを指定するには、次のようにします。
Application Server Controlで「管理」リンクをクリックします。
「システムMBeanブラウザ」をクリックします。
ナビゲーション・ペインでClassLoadingノードを展開し、singleton MBeanインスタンスを選択します。
右側のペインで「操作」タブをクリックし、executeQuery操作をクリックします。
|
注意: 2つのバージョンのexecuteQuery操作が公開されています。2つのパラメータを受け取るバージョンをクリックしてください。（queryClassDataパラメータは、システムMBeanブラウザからは設定できません。） |
queryClassNameに対する値として、実行する問合せの名前を入力します。たとえば、LoaderTreeなどと入力します。
「queryArguments」アイコンをクリックし、指定する引数ごとに新しい行を追加します。引数は括弧で囲まないでください。括弧は、操作が呼び出されるときに自動的に追加されます。引数の指定が終了したら、「OK」をクリックします。
「起動」ボタンをクリックして、操作を呼び出します。
AuditLoader問合せを使用して、OC4Jインスタンスで使用可能な1つ以上のクラス・ローダーを、その内容の診断を実行することによって監査できます。この問合せでは、監査出力のレベルを指定し、監査にJREクラスを含めることができます。
AuditLoaderの出力には、エラーに関する情報が含まれます。新規の共有ライブラリを追加する場合は、新規のライブラリに対してレポートされたすべてのエラーを削除する必要があります。
ピークでは、コマンドライン・ウィンドウでAuditLoaderを入力してクラス・ローダーを指定（オプションでその後に追加の引数を指定）することにより、クラス・ローダーを監査できます。表3-2は引数の説明です。
ピークを使用してクラス・ローダーを監査するには、次のようにします。
ピークの初期画面に表示される問合せリストから、「AuditLoader」をクリックします。
問合せ名がコマンドライン・ウィンドウに挿入され、問合せの引数が表示されます。
監査対象となる1つ以上のクラス・ローダーを指定する場合は、-- loaderName --という名前のリストから各クラス・ローダーを選択します。
選択した名前がそれぞれ、コマンドラインのAuditLoaderの後に挿入されます。
また、各クラス・ローダーを空白で区切ってクラス・ローダーのリストを入力することもできます。
OC4Jインスタンスで使用可能なすべてのクラス・ローダーを監査する場合は、AuditLoaderの後に*を入力します。
AuditLoader問合せの直後に再びAuditLoader *を指定すると、前の問合せの引数が使用されます。
「実行」をクリックするか、[Enter]キーを押します。
問合せの結果が表示されます。
同じ問合せを後で実行する場合は、再利用できるようにURLを保存します。
新規の共有ライブラリを追加する場合は、そのライブラリに対してAuditLoader結果にレポートされたすべてのエラーを削除してから、問合せを再実行してそれらのエラーが削除されていることを確認してください。
たとえば、詳細な出力を指定してoracle.jdbcローダーを監査するには、次のように問合せを指定します。
AuditLoader oracle.jdbc:10.1.0_2 -verbose
図3-8は、この問合せの実行結果の出力の一部を示しています。返されるリストが大きいため、図は切り捨てられています。
|
注意: すべてのローダーを監査することもできますが、ユーザーがすべてのローダーを監査しようとすると、システムのメモリーが不足する可能性があります。すべての共有ローダーを監査するには、*を指定します（-XX:MaxPermSize=512mを試行してください）。 |
AuditLoader問合せの出力には、各クラス・ローダーに対する次の診断情報を含めることができます。
監査対象のクラス・ローダーをインポートするクラス・ローダー
デフォルトのインポートが存在するかどうか
インポート済のクラス・ローダー
メンバー・クラス
メンバー・パッケージ
外部クラス依存性
外部パッケージ依存性
外部ローダー依存性
クラス・ローダーに関する注意（使用される他のクラス・ローダーなど）
警告
重複しているクラス
エラー
警告およびエラーを解決するための推奨事項
AuditLoader問合せの引数は次のとおりです。
loaderName [loaderName] . . . | * [-verbose] [-includeJREClasses]
表3-2は、これらの引数の説明です。
Callers問合せでは、指定したメソッドを呼び出すすべてのクラスがレポートされます。クラス・ローダーの名前を指定することによって、問合せを制限できます。
たとえば、System.currentTimeMillis()を呼び出すすべてのクラスを検索するには、次の問合せを実行します。
-Doc4j.start.query=Callers(java.lang.System.currentTimeMillis()long)
次の例は、MyApp.rootクラス・ローダーから見ることのできる複数のクラス中の同じメソッドを検索します。
-Doc4j.start.query=Callers(-MyApp.root,java.lang.System.currentTimeMillis()long)
オーバーロードされたClass.forName()メソッドのいずれかのバージョンに対する呼出しを検索するには、両方のメソッドのシグネチャを引数として渡します。
-Doc4j.start.query=Callers(java.lang.Class.forName(java.lang. String)java.lang.Class,java.lang.Class.forName(java.lang.String;boolean;java.lang. ClassLoader)java.lang.Class)
signature引数にinitを含めることで、コンストラクタを指定できます。
-Doc4j.start.query=Callers(java.util.Date.init())
Callers問合せの引数は次のとおりです。
[-loaderName,]signature . . .
表3-3は、これらの引数の説明です。
表3-3 Callers問合せの引数
| 引数 | 説明 |
|---|---|
|
|
オプション。指定すると、指定したクラス・ローダーから見えるすべてのクラスで、指定したメソッドがチェックされます。 指定しないと、すべてのアプリケーション固有のクラス・ローダーのデフォルトの親である |
|
|
チェックするメソッドです。 複数のメソッドは、それぞれ個別の引数として指定できます。 構文は次のとおりです。
複数のパラメータ・タイプはセミコロン（ |
ClassLoadMetrics問合せでは、指定した1つ以上のクラス・ローダー（何も指定しない場合はすべてのクラス・ローダー）のメトリックがレポートされます。
次に例を示します。
-Doc4j.start.query=ClassLoadMetrics(MyApp.root,MyOtherApp.root)
ClassLoadMetrics問合せの引数は次のとおりです。
[-verbose] [loaderName] ...
|
注意: OC4Jでは、PolicyClassLoader.toString()メソッドの詳細（複数行）出力はデフォルトでオフになっています。ローダー名およびバージョンのみが戻されます。
次のいずれかのシステム・プロパティを設定することで、詳細出力を有効化できます。
|
表3-4は、これらの引数の説明です。
ClassPath問合せでは、使用中のコード・ソースが一覧表示されます。
ClassPath問合せの引数は次のとおりです。
[-list] [loaderName]
表3-5は、これらの引数の説明です。
Dependencies問合せでは、指定したクラスのすべての依存性がレポートされます。
Dependencies問合せの引数は次のとおりです。
className [loaderName] [-r]
表3-6は、これらの引数の説明です。
Depends問合せでは、指定したクラスに依存するすべてのクラスがレポートされます。
Depends問合せの引数は次のとおりです。
[-loaderName] className
表3-7は、これらの引数の説明です。
DuplicateClasses問合せでは、異なるコード・ソース内に同じ名前のクラスおよびリソースが存在するかどうかがレポートされます。
DuplicateClasses問合せの引数は次のとおりです。
[[-loaderName] [-systemCodeSources]
表3-8は、これらの引数の説明です。
DuplicateCodeSources問合せでは、同じ名前を持つコード・ソースまたは複数のサブスクライバを持つコード・ソースがレポートされます。
DuplicateCodeSources問合せの引数は次のとおりです。
[-digest]
表3-9は、この引数の説明です。
Exit問合せでは、プロセスが終了し、（実行中の）OC4Jは停止します。この問合せは、OC4Jサーバーを稼働したままにせず、問合せのみを実行する場合に便利です。次に例を示します。
-Doc4j.start.query=LoaderTree+Exit
Exit問合せの引数は次のとおりです。
[-force]
表3-10は、この引数の説明です。
FindResource問合せでは、指定したリソースが含まれるコード・ソースがレポートされます。コード・ソースは、クラス名またはリソース・パスで識別されます。
単純なワイルドカード検索では、先頭または末尾にアスタリスク（*）を使用できます。
引数が正規表現として扱われるように指定するには、先頭にチルダ（~）を使用できます。
パッケージのないクラスを検索するには、resourcePath引数を渡す必要があります。たとえば、クラスfooを検索するには、次のような問合せを使用します。
-Doc4j.start.query=FindResource(Foo.class)
パッケージ（/）のないリソース（リソース名にピリオド（.）が付きます）を検索するには、先頭にアスタリスクを使用する必要があります。たとえば、コード・ソースのルートにあるmyconfig.xmlファイルを検索するには、次の問合せを使用します。
-Doc4j.start.query=FindResource(*myconfig.xml)
FindResource問合せの引数は次のとおりです。
[[-list] resourcePath|className
表3-11は、これらの引数の説明です。
GetResource問合せでは、指定したローダーに対してgetResource()またはgetResources()が呼び出され、結果がレポートされます。
GetResource問合せの引数は次のとおりです。
resourcePath [loaderName] [-all]
表3-12は、これらの引数の説明です。
HttpSessions問合せでは、デプロイされたアプリケーションのアクティブなHTTPセッションの概要がレポートされます。
HttpSessions問合せの引数は次のとおりです。
[details]
表3-13は、この引数の説明です。
LeakedLoaders問合せでは、クラス・ローダーのリーク検出が制御され、結果が一覧表示されます。
LeakedLoaders問合せの引数は次のとおりです。
[activate|list|deactivate]
表3-14は、これらの引数の説明です。
ListClasses問合せでは、特定のクラス・ローダーから使用可能なすべてのクラスが一覧表示されます。
次のように、1つのOC4Jインスタンスに対するpcscomponent.xmlファイル内に起動オプションとしてListClasses問合せを使用することも、コマンドラインで問合せを使用してスタンドアロンOC4Jを起動することもできます。
java -Doc4j.start.query=ListClasses:loaderName -jar oc4j.jar
OC4J起動オプションの使用方法の詳細は、『Oracle Containers for J2EE構成および管理ガイド』のOC4Jインスタンスの起動、再起動および停止に関する項を参照してください。
例3-2では、apache.commons.logging:1.0.4ローダー内のクラスを一覧表示しています。
例3-2 ListClasses問合せの出力
ListClasses apache.commons.logging:1.0.4 org.apache.commons.logging.Log org.apache.commons.logging.LogConfigurationException org.apache.commons.logging.LogFactory org.apache.commons.logging.LogFactory$1 org.apache.commons.logging.LogFactory$2 org.apache.commons.logging.LogFactory$3 org.apache.commons.logging.LogSource org.apache.commons.logging.impl.AvalonLogger org.apache.commons.logging.impl.Jdk14Logger org.apache.commons.logging.impl.Log4JCategoryLog org.apache.commons.logging.impl.Log4JLogger org.apache.commons.logging.impl.Log4jFactory org.apache.commons.logging.impl.LogFactoryImpl org.apache.commons.logging.impl.LogFactoryImpl$1 org.apache.commons.logging.impl.LogKitLogger org.apache.commons.logging.impl.NoOpLog org.apache.commons.logging.impl.SimpleLog org.apache.commons.logging.impl.SimpleLog$1
ListQueries問合せでは、OC4Jのサブクラス名oracle.oc4j.query.Queryで使用可能なすべての問合せが一覧表示されます。
次のように、1つのOC4Jインスタンスに対するpcscomponent.xmlファイル内に起動オプションとしてListQueries問合せを使用することも、コマンドラインで問合せを使用してスタンドアロンOC4Jを起動することもできます。
java -Dstart.query="ListQueries(-l)" -jar oc4j.jar
OC4J起動オプションの使用方法の詳細は、『Oracle Containers for J2EE構成および管理ガイド』のOC4Jインスタンスの起動、再起動および停止に関する項を参照してください。
loadClass問合せを使用して、クラス・ロードのテスト実行を行うことができます。この問合せでは、指定したクラス・ローダーを使用して、またはクラス・ローダーを指定しない場合は内部のクラス・ローダーを使用して、指定したクラスのロードが試行され、結果がレポートされます。
loadClass問合せは、ClassNotFoundExceptionエラーのトラブルシューティングを行う場合に便利です。この問合せを使用すると、異なる初期ローダーからクラスをロードし、結果についてのレポートを取得できます。
ピークでは、loadClass問合せを使用して、クラスをOC4Jインスタンスにロードし、結果についてのレポートを表示できます。
ピークでloadClass問合せを使用するには、次のようにします。
Webブラウザで、/peek/コンテキスト・ルートに移動します。
http://localhost:8888/peek/
loadClass問合せと、ロードするクラスの名前およびオプションのパラメータ（表3-17を参照）を入力します。
「実行」をクリックするか、[Enter]を押します。
ピークによって、指定したクラスがロードされ、クラス名、定義側のクラス・ローダー、およびクラスがロードされた元のコード・ソースとともにレポートが表示されます。図3-10は、loadClassレポートを示しています。
loadClass問合せの引数は次のとおりです。
[className [ loaderName] [-forName] [-depends] [-r] [-sort]
表3-17は、これらの引数の説明です。
表3-17 LoadClass問合せの引数
| 引数 | 説明 |
|---|---|
|
|
必須。レポートするクラスの完全修飾名です。 |
|
|
オプション。指定すると、このクラス・ローダーを使用したクラスのロード試行がレポートされます。指定しないと、内部クラス・ローダーがデフォルトで使用されます。 |
|
|
オプション。試行を記録するクラス・ローダーのメソッドです。指定しないと、 |
|
|
オプション。指定すると、指定したクラスのすべての依存性のロードとレポートをクラス・ローダーに強制します。 |
|
|
オプション。指定すると、すべての依存性が再帰的にロードされます。再帰には |
|
|
オプション。指定すると、依存クラスのリストがクラス名ごとに並べ替えられます。 |
LoadedClasses問合せでは、OC4Jインスタンスにロードされたすべてのクラス（使用可能な場合）の名前が一覧表示されます。
ピークでは、コマンドライン・ウィンドウでLoadedClasses問合せを指定して、ロード済のクラスを一覧表示できます。
ピークでLoadedClasses問合せを使用するには、次のようにします。
図3-11は、LoadedClasses問合せの出力を示しています。
LoaderTree問合せでは、指定したルート・クラス・ローダーについて、または何も指定しない場合はJREブートストラップ・クラス・ローダーについて、クラス・ローダー・ツリーの内容がレポートされます。デフォルトでは、ツリー内のクラス・ローダーの名前のみがレポートされます。
特定のアプリケーションのルートから下位など、クラス・ローダー・ツリーの特定の部分に注目する場合、この問合せが役に立ちます。また、ピークを使用して、クラス・ローダー・ツリーの内容を一覧表示することもできます。この項で後述する「ピークを使用したクラス・ローダー・ツリーの表示」を参照してください。
次に例を示します。
-Doc4j.start.query=LoaderTree(MyApp.root)
クラス・ローダー・ツリー全体を取得する場合は、ルート・クラス・ローダー名を指定しません。
-Doc4j.start.query=LoaderTree
ピークを使用して、クラス・ローダー・ツリーの内容をレポートできます。また、ピークを使用すると、コード・ソース内の特定のクラスにドリルダウンしたり、クラスの逆コンパイル済スタブを表示することができます。次の例で、ピークを使用してクラス・ローダーを表示する方法と、特定のクラスのスタブを表示する方法を示します。
ピークを使用してクラス・ローダー・ツリーを問い合せるには、次のようにします。
ピーク・ツールから、「表示」にマウスを置いて「ローダー」を選択します。次に示すようなクラス・ローダー・ツリーが表示されます。返されるリストが大きいため、図は切り捨てられています。
ツリーから、「oc4j:10.1.3」クラス・ローダー・リンクを選択します。次に示すように、このクラス・ローダーのすべてのインポート済共有ライブラリ、コード・ソースおよびクラスのレポートが表示されます。返されるリストが大きいため、図は切り捨てられています。
レポートから「${oracle.home}/j2ee/home/oc4j.jar」コード・ソース・リンクをクリックして、JAR内のすべてのクラスを表示します。次に示すように、すべてのクラスのレポートが表示されます。
レポートからクラス・リンクをクリックして、そのクラスの逆コンパイル済スタブを表示します。たとえば、「oracle/oc4j/loader/boot/BootStrap.class」リンクをクリックすると、次のスタブが表示されます。
Packages問合せでは、1つ以上のコード・ソースに含まれるパッケージ名が一覧表示されます。
Packages問合せの引数は次のとおりです。
[loaderName | codeSourcePath]
表3-19は、これらの引数の説明です。
SessionReplicationStats問合せでは、指定したアプリケーションに対してレプリケートされたHTTPおよびEJBセッションの統計が取得されます。
SessionReplicationStats問合せの引数は次のとおりです。
[application name]
表3-20は、この引数の説明です。
SharedLibraries問合せでは、インストールされているすべての共有ライブラリとライブラリをインポートするクラス・ローダーが一覧表示されます。
SharedLibraries問合せの引数は次のとおりです。
[loaderName]
表3-21は、この引数の説明です。
SystemProperties問合せでは、システム・プロパティが一覧表示または設定されます。
SystemProperties問合せの引数は次のとおりです。
[key=value] ...
表3-22は、この引数の説明です。
表3-22 SystemProperties問合せの引数
| 引数 | 説明 |
|---|---|
|
|
オプション。システム・プロパティの名前および値です。指定すると、システム・プロパティの値を設定します。キー/値ペアを指定しないと、システム・プロパティの現在値が表示されます。 |
図3-12は、現在設定されているすべてのシステム・プロパティを返すピーク問合せを示しています。返されるリストが大きいため、図は切り捨てられています。
ThreadPools問合せでは、現在のJVMのスレッド・プールの情報が一覧表示されます。
ThreadPools問合せの引数は次のとおりです。
(list [sys|req|cx]|pool [sys|req|cx]|state [sys|req|cx][id])
表3-23は、これらの引数の説明です。
Threads問合せでは、現在のJVMのスレッド情報が一覧表示されます。JDK 1.5では、スレッド・デッドロックがチェックされるか、現在のJVMのスレッド・メモリー使用量が取得されます。
Threads問合せの引数は次のとおりです。
[list|groups|deadlock|memory]
表3-24は、これらの引数の説明です。
UnusedCodeSources問合せでは、まったくデータを返していないコード・ソースがレポートされます。
UnusedCodeSources問合せに引数はありません。
J2EEにおけるほとんどのクラス・ロード・エラーは、普通、小さな例外セットの1つとして表面化します。OC4Jクラス・ロード・インフラストラクチャは、次の標準クラス・ロード構成の例外それぞれに対して、注釈付きサブクラスを提供します。
これらのサブクラスは、構成を理解して修正するために役立つ情報で、getMessage()、printStackTrace()、toString()の各メソッドの出力を拡張します。通常は、問題を修正するにはこの追加情報のみで十分ですが、十分でないときは、ログ、トレースおよび問合せの機能を使用してさらに調査できます。
各エラーについて、診断検索を実行して追加情報を利用できます。この検索は、標準的なローダーの可視性による制約は受けず、システムが認識するすべてのローダーやコード・ソースを参照できます。結果は、エラー・メッセージの一部として報告されます。
状況によっては、ローダーのランタイムが結果に基づいてリカバリ（たとえば、不足しているクラスを自動的に検索してロードする）を試行できます。ただし、これによってさらに問題が発生し、診断がいっそう困難になる可能性があります。
この例外は、Class.forName()やClassLoader.loadClass()などのように、名前でクラスを明示的にロードするメソッドを使用して動的なロードを行っている間に発生する可能性があります。開始しているクラス・ローダーから必要なクラスが見えないことを示しています。
トラブルシューティングと解決の方法
ClassNotFoundExceptionはNoClassDefFoundErrorとほとんど同じです。1つの重要な違いは、初期ローダーの選択をJVMではなく呼出し元のコードで行うことができることで、比較的間違えやすい点です。
Class.forName(String)メソッドを使用している場合は、JREのコードが初期ローダーを選択し、常に呼出し元のローダーを選択します。これは多くの場合に正しくありません。たいていはスレッド・コンテキスト・ローダーを明示的に渡すのがよい方法です。
Thread thread = Thread.currentThread(); ClassLoader loader = thread.getContextClassLoader(); Class cls = loader.loadClass(name);
ローダーを直接呼び出す方が、Class.forName()の形式を使用するより適しています。
Class cls = Class.forName(name, true, loader);
これら2つの呼出しはどちらも指定したローダーからロードしようとしていますが、わかりやすいのは直接的な呼出しの方です。また、トレースが意図したとおりに動作することも保証されます。これは、VMによるforName()の実装によっては、ローダーを省略する場合があるためです（クラスがまだキャッシュされていない場合にのみローダーを呼び出します。ローダーは常にキャッシュ自体を調べるので、ローダーを直接呼び出す方が安全で効率的です）。
異なる初期ローダーからのクラスのロードを実験するには、LoadClassの問合せが便利です。
正しい初期ローダーが使用されていた場合は、コード・ソースが検索パスに存在しない可能性があります。詳細は、「NoClassDefFoundError」を参照してください。
この例外は、あるクラスから別のクラスへの静的な依存性をVMが解決しようとしたときに発生する可能性があります。一種のLinkageErrorであり、開始しているローダーから必要なクラスが見えないことを示しています。静的な依存性の解決は最初の使用まで延期されることが多いため、このエラーは予期せず発生する場合があります。
エラー・メッセージの例
Missing class: acme.Dynamite
Dependent class: acme.RoadRunner
Loader: acme.root:0.0.0
Code-Source: /myapps/acme/acme.jar
Configuration: <ejb> in /myapps/acme/application.xml
The missing class is available from the following locations:
1. Code-Source: /shared/bang/0.0.0/bang.jar (from <code-source>
in j2ee/home/server.xml)
This code-source is available in loader bang:0.0.0. This
shared-library can be imported by the "acme" application.
トラブルシューティングと解決の方法
エラー・メッセージを調べます。最初の行に、見つからないクラスの名前があります。次の4つの行では、依存性を持つクラスの名前、クラスを定義しているローダー（VMによって選択された開始ローダーでもあります）、基になっているコード・ソース、およびそのローダーにコード・ソースが追加される原因となった構成オプションが示されています。次の行には診断検索の結果が示されており、問題を解決するための十分な詳細が提供されていると考えられます。
次に示すのは、診断検索によって報告されるいくつかの一般的な状態と、それを解決するための具体的な指摘です。
見つからないクラスが、システムから見ることのできるどのコード・ソースにも存在しません。
これは、多くの場合、単に別のコード・ソースを追加する必要があることを示します（さらに他のコード・ソースが必要になる可能性があります）。依存クラスの情報を使用して、構成を追加する適切なレベルを選択した後、適当なオプションを選択します（表3-1「クラスの可視性に影響を与える構成オプション」を参照）。他のアプリケーションも同じクラスを必要とする可能性がある場合は、新しい共有ライブラリの作成を検討します。作成したら、新しい共有ライブラリもインポートする必要があります。
この結果は、既存のコード・ソースの宣言が無効であることを意味する場合もあります。有効なファイルまたはディレクトリをポイントしていないパスが検出されると、この事実がログに記録されますが、そのレベルは通常マスクされています。すべてのメッセージを見るには、次のように設定してシステムを起動します。
-Dclass.load.log.level=finest
存在しないコード・ソースに関するメッセージを探し、関連するメッセージを見つけたら、構成を修正します。通常はメッセージが多いので、より簡単に検索できるファイル（たとえばloader.log）に出力を送ると便利です。
-Dclass.load.log.file=loader.log
見つからないクラスは共有ライブラリに存在していますが、共有ライブラリがインポートされていません。
Application Server Controlを使用するか、<import-shared-library>要素をアプリケーションのorion-application.xmlデプロイメント・ディスクリプタに追加して、共有ライブラリをインポートします。
見つからないクラスは存在しますが、それを使用するように構成されているローダーが開始ローダーの子です。
この問題が最もよく発生するのは、アプリケーション・ルート・ローダー（たとえばEJBモジュール）にデプロイされたクラスが、Webモジュールにデプロイされたクラスに対して依存性を持っている場合です。解決するには、リファクタを行って依存性を除去するか、またはクラスを同じローダーに移動する必要があります。多くの場合、最も簡単な解決方法は、このようなクラスをWebモジュールからアプリケーション・ルートに移動することですが、反対方向の移動が可能な場合もあります。ルートにコード・ソースを追加するオプションは、表3-1を参照してください。
このようなクラスを移動するのではなくコピーすると、Webモジュールでsearch-local-classes-firstが有効になっている場合にはClassCastExceptionが発生する可能性があります。
見つからないクラスは存在しますが、それを使用するように構成されているローダーが関係のないアプリケーションにあります。
この場合の理想的な解決方法は、関連するコード・ソースを既存のアプリケーションから新しい共有ライブラリに移動し、この共有ライブラリをインポートするように両方のアプリケーションを再構成することです。この方法が実際的でない場合は、コード・ソースを現在のアプリケーションにコピーしてもかまいません。構成を使用して他のアプリケーションにあるコード・ソースを直接指し示すことも可能ですが、そのアプリケーションがデプロイされない場合には障害が発生します。
特定のローダーからのコード・ソースの検索順序を調べるには、ClassPath問合せが役に立つ場合があります。
-Doc4j.start.query="ClassPath(acme.root)+Exit"
SharedLibraries問合せを使用して、すべての共有ライブラリとそれをインポートするローダーの一覧を作成することもできます。
このエラーは、クラスが初めてロードされるとき（定義中）に発生する可能性があります。一種のLinkageErrorで、多くの場合、クラスが異なるバージョンのJVMに対してコンパイルされていることを示しています。
トラブルシューティングと解決の方法
エラー・メッセージでは、クラスがコンパイルされたバージョンと、現在のランタイムがサポートしているバージョンが示されています。
問題を解決するには、正しいバージョンのJVMに切り替えるか、または現在のバージョンでクラスを再コンパイルします。
このエラーは、クラスが初めてロードされるとき（定義中）に発生する可能性があります。一般的なLinkageErrorのサブタイプは、OC4Jクラス・ロード・フレームワークによって特別なケースとして処理されます（「NoClassDefFoundError」および「ClassFormatError」を参照）。それ以外のケースは、通常、次のいずれかの問題を示しています。
コンパイル時に使用されたクラスのバージョンと、実行時に検出されたバージョンが一致しない。
必要なネイティブ・ライブラリが見つからない。
エラー・メッセージでは、実際の障害が示され、さらに、定義中に障害が発生したクラスおよびその定義が発生する原因となった依存性を持つクラスの、名前、定義しているローダー、コード・ソースおよび構成が提供されます。
メッセージがなんらかの種類のバージョン不一致（NoSuchMethodErrorなど）を示している場合、障害を解決するには、ソース・レベルの変更と再コンパイルが必要です。多くの場合、不一致はスーパークラスまたはインタフェースとサブクラスの間で発生し、比較的簡単に識別できます。
UnsatisfiedLinkErrorは、ネイティブ・ライブラリが見つからないことを意味します。通常、OC4JはRARモジュール内のネイティブ・ライブラリの構成のみをサポートします（表3-1「クラスの可視性に影響を与える構成オプション」を参照）。ライブラリがRAR内で指定されている場合、それが無効なパスである可能性があります。class.load.log.levelプロパティを使用してこのケースを検出する方法については、「NoClassDefFoundError」を参照してください。
通常、この例外は次のような明らかな理由で発生します。
Object source = new Integer(0); String target = (String) source; // Exception
ただし、この例外はクラス・ロードに関係している場合もあります。残念ながら、VMによって作成されるエラー・メッセージは通常は空で、この例外がロードに関係するものであっても、解釈して注釈を付けることができません。
複数のローダーが同じ名前でクラスを定義していると、2つの型の間のキャストがClassCastExceptionで失敗します。
import com.acme.Foo;
...
// Get the loader that resolves our static dependency
// on class Foo
ClassLoader expected = Foo.class.getClassLoader();
// Dynamically load Foo from another loader and
// create an instance
Class fooClass = aLoader.loadClass("com.acme.Foo");
Object source = fooClass.newInstance();
ClassLoader actual = fooClass.getClassLoader();
// Compare and cast
System.out.println(actual == expected); // "false"
Foo target = (Foo) source; // Exception
この場合、ローダーのインスタンスが異なるため、JVMでは2つのクラスが無関係と判断されます。
この問題の比較的よくある例は、単一のアプリケーションにおいて、EJBモジュールとEJBモジュールを使用するWebモジュールの両方でEJBインタフェースがパッケージされている場合に発生します。Webモジュールでsearch-local-classes-firstオプションが有効になっていると、EJBクラスが2回ロードされます。
まず、スタック・トレースの先頭に記述されているコードを見て、キャストのターゲットの型を確認します。キャストがプリミティブ型（intやlongなど）またはJREによって定義されているクラス（String、HashMap、他のjava.クラスなど）に対するものである場合は、クラス・ロードに関係するものではないことがほぼ確実であり、通常は単なる開発者のエラーです。
次に、トレースを使用してターゲット・クラスの定義を確認します。たとえば、キャストのターゲットがcom.acme.Fooである場合は、次のような記述を使用します。
-Dclass.load.log=class-defined:com.acme.Foo
出力では、ローダーとクラスの定義の基になっているコード・ソースが示されています。1つしかない場合、問題はクラス・ロードには関係ないと考えられます（ただし、カスタム・クラス・ローダーが使用されている場合はトレースに含まれないため、依然として問題である可能性があります）。
ターゲット・グラスの定義が2つ以上ある場合は、これらのアクセスにより例外が発生している可能性が高いです。トレース・メッセージで両方の定義に対して同じコード・ソースがリストされている場合は、ローダー間で共有されているため簡単に再調整できます。
一方、これよりさらによくあるのが、おそらく利便性のため（ほとんどの場合よくない考えです）にクラスが再パッケージされているため、またはバージョン違いのために、コード・ソースが異なる場合です。ローダーの1つがWebモジュールのものである場合は、search-local-classes-firstを無効にすれば十分である可能性があります。
コードのインスツルメントが可能な場合は、キャストのすぐ前に次のコードを追加することで、重複を確認できます（objはキャストされているオブジェクト）。
ClassLoader expected = Foo.class.getClassLoader();
System.out.println("Expected: " + expected);
ClassLoader actual = obj.getClass().getClassLoader();
System.out.println(" Actual: " + actual);
出力は、トレース・メッセージで名前が示されているローダーと一致する必要があります。objが予想される型のサブクラスである場合は、Class.getSupertype()で階層を移動することが必要になる場合があります。
重複が原因であると確認された場合は、重複しているすべてのクラスを除去する必要があります。そのためには、クラスが共有されるように調整します。クラスを、2つのローダーの共通の親、または共有ライブラリに移動します。クラスを引き続きロードするローダーを決定する際の参考として、各クラス定義の時点でのコール・スタックを見ると役に立つ場合があります。
-Dclass.load.log=class-defined:com.acme.Foo+stack
LoaderTree問合せを使用してローダー間の関係を見ることも、役に立つ場合があります。
-Doc4j.start.query=LoaderTree
問合せは、Application Server ControlのシステムMBeanブラウザを使用して、実行中のインスタンスに対して実行することもできます。この問合せで-verboseオプションを使用すると、詳細を見ることができます。
-Doc4j.start.query="LoaderTree(-verbose)+Exit"
DuplicateClasses問合せを使用して、潜在的な重複（異なるコード・ソース中の同じクラス名）を検索することもできます。
OC4Jで提供されているclass.load.logシステム・プロパティを設定すると、クラスのロード、クラス・ローダーのライフ・サイクルおよびコード・ソースのライフ・サイクルのイベントをトレースできます。生成されるトレース出力は、クラスのロードに関する問題のトラブルシューティングに非常に役立ちます。
|
注意: この機能は、OC4Jの今後のリリースで変更される場合があります。 |
class.load.logプロパティは、OC4Jの起動時に設定されます。構文は次のとおりです。
class.load.log=<event>[[:<string-filter>[,<string-filter>]] | [~<pattern-filter>]]
<event>はトレースするイベントです。有効な値については、表3-26を参照してください。
+文字を使用すると、複数のイベント値を連結できます。
-Dclass.load.log=class+loader
<string-filter>は、トレースの出力を制御するために適用するフィルタです。最初のフィルタとイベントをコロン（:）で区切ることに注意してください。トレース出力を制御するために適用できるフィルタの種類の詳細は、「トレース出力を制御するためのフィルタの使用」を参照してください。
フィルタが複数ある場合はカンマで区切ります。
-Dclass.load.log=class:com.acme.Foo,com.acme.Bar
<pattern-filter>は、正規表現として解釈される単一のフィルタです。フィルタの前に文字~を付けることに注意してください。
|
注意:
|
トレースの出力は、デフォルトではコンソールに表示されますが、class.load.log.fileシステム・プロパティを使用して、指定したファイルに書き込むこともできます。次に例を示します。
java -Dclass.load.log.file=C:\logs\logfile.txt -jar oc4j.jar
表3-26 class.load.logシステム・プロパティの値
| 値 | 説明 |
|---|---|
|
|
すべてのトレース・モードをアクティブ化します。この値を設定すると、出力の量が増えるためにOC4Jのパフォーマンスに若干影響が出る可能性があることに注意してください。 |
|
|
すべてのトレース・モードを無効にします。 |
|
|
すべてのクラス・ロード検索イベントをトレースします。 |
|
|
指定したクラスがクラス・ローダーによって最初にロードされるすべてのイベントをトレースします。その後、オブジェクトは以降のクラス・ローダーによる使用のためにキャッシュされます。 |
|
|
指定したクラスが検出されたすべての検索イベントをトレースします。 |
|
|
指定したクラスが検出されなかったすべての検索イベントをトレースします。 |
|
|
すべてのコード・ソース・ライフ・サイクル・イベントをトレースします。 |
|
|
コード・ソース・オブジェクトが最初に初期化されたイベントをトレースします。メモリー内に作成されるコード・ソースのインスタンスは1つのみです。その後、このオブジェクトは、必要とするすべてのクラス・ローダーによって共有されます。 |
|
|
すべてのコード・ソースについて、アーカイブ内にパッケージされている |
|
|
すべてのコード・ソースについて、アーカイブ内にパッケージされている |
|
|
すべてのコード・ソースについて、アーカイブ内にパッケージされている |
|
|
すべてのコード・ソースについて、 |
|
|
次の2つのコード・ソース状態に対するイベントをトレースします。
|
|
|
コード・ソース・オブジェクトが破棄されているイベントをトレースします。 |
|
|
すべてのクラス・ローダー・ライフ・サイクル・イベントをトレースします。 |
|
|
クラス・ローダー・オブジェクトのインスタンス化イベントをトレースします。 |
|
|
クラス・ローダー・オブジェクトが作成され、コード・ソースからクラスを移入されたイベントをトレースします。 |
|
|
クラス・ローダー・オブジェクトに対して |
|
|
クラス・ローダー・オブジェクトがJVMによるガベージ・コレクションの処理中であるイベントをトレースします。 |
|
|
クラス・ローダー・オブジェクトが破棄されているイベントをトレースします。 |
|
|
すべてのリソース検索イベントをトレースします。 |
|
|
リソースが検出されたすべてのリソース検索イベントをトレースします。 |
|
|
リソースが検出されなかったすべてのリソース検索イベントをトレースします。 |
|
|
すべてのイベントにスタック・トレースを追加します。 |
|
|
ヘルプ・テキストをコンソールに表示します。 |
class.load.logシステム・プロパティは、イベント・トレースの出力をより制御しやすくするためのフィルタの使用をサポートします。構文は次のとおりです。最初のフィルタとトレース対象のイベントをコロン（:）で区切ることに注意してください。
<event>[[:<string-filter>[,<string-filter>]] | [~<pattern-filter>]]
表3-27は、サポートされるイベント・フィルタの種類についての説明です。
表3-27 サポートされるトレース出力フィルタ
| イベント | サポートされるフィルタ |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
デフォルトでは、クラス・ローダーのログ出力メッセージは、CONFIGのJavaログ・レベルでフィルタされます。必要であれば、class.load.log.levelシステム・プロパティを使用してログ・レベルを変更できます。表3-28は、このプロパティで設定できる値の一覧です。
たとえば、ログ・レベルをSEVEREに設定するには次のように指定します。
-Dclass.load.log.level=severe
トレース関連のメッセージはINFOのログ・レベルで作成されることに注意してください。したがって、これらのメッセージがログ出力からフィルタで除外されるのを防ぐため、INFOより上のログ・レベル（たとえばWARNING）には設定しないでください。
表3-28 class.load.log.levelシステム・プロパティの値
| 値 | 説明 |
|---|---|
|
|
すべてのログ・メッセージを出力します。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
すべてのログ・メッセージを抑止します。 |
