10gリリース2（10.1.2）
B15630-02
 目次 |
 索引 |
| Oracle Application Server Containers for J2EE ユーザーズ・ガイド 10gリリース2（10.1.2） B15630-02 |
|
第2章「構成およびデプロイ」では、J2EEアプリケーションの基本的な構成、開発およびデプロイを説明します。この章では、グローバルなJ2EEサービス構成と高度なJ2EEアプリケーション構成の両方について説明します。
この章には、次の項目が含まれています。
J2EEサービス、J2EEアプリケーションおよびOracle Application Serverクラスタは、Enterprise Managerで構成できます。その一部はOC4Jインスタンス・レベルで構成され、インスタンス内でデプロイされたすべてのアプリケーションに対してグローバルな構成となります。その他はアプリケーション・レベルで構成されるため、このタイプの構成はローカルで、そのアプリケーションのみに適用されます。
次の項では、Enterprise ManagerでのOC4Jに対する高度な構成の概要を説明します。
OC4Jホームページから、「管理」ページにドリルダウンすることで、すべてのアプリケーションに適用されるグローバル・サービスを構成できます。「管理」ページでは、次の構成が可能です。
OC4Jプロパティを構成するには、「インスタンス・プロパティ」セクションまでスクロールして、「サーバー・プロパティ」を選択します。このページの「一般」セクションに、次のフィールドが表示されます。
デフォルトのサーバー・プロパティに関する次の情報が、ページの上半分に表示されます。
application.xmlとは別に、application.xmlというファイルが存在します。このapplication.xmlファイルは、グローバルapplication.xmlファイルと呼ばれます。このファイルは、OC4Jインスタンス内にデプロイされているすべてのアプリケーションで使用するプロパティを定義します。
このセクションで、OC4Jサーバーのデフォルトを変更できます。これらのデフォルトは次のとおりです。
global-web-application.xmlというXMLファイルで指定されています。別のXMLファイルを参照する場合は、ここでファイルの名前を変更します。ただし、そのファイルは、Oracle指定のDTDに準拠する必要があります。ディレクトリは、j2ee/home/configに対する相対ディレクトリです。 このファイルに含まれる要素を変更するには、「Webサイト・プロパティ」または「拡張プロパティ」セクションのいずれかのエントリを更新します。詳細は、「Webサイトの構成」と「デプロイ済アプリケーションEARファイルに含まれるXMLファイルの変更」を参照してください。
/applicationsディレクトリです。デフォルト・ディレクトリは、変更されたモジュール・デプロイメント・ディスクリプタが追加のデフォルトとともにOC4Jにより配置される場所です。現在、この場所は、/application-deploymentsディレクトリ下です。デフォルト・ディレクトリの場所は、このフィールドで変更できます。ディレクトリは、j2ee/home/configに対する相対ディレクトリです。 このディレクトリの使用方法は、「デプロイ時の動作」を参照してください。
次の「複数仮想マシン構成」セクションは、クラスタ構成の一部として使用されます。次に、各フィールドの意味を詳しく説明します。ただし、このセクションを使用するクラスタの構成方法のコンテキストについては、第4章「OC4Jのクラスタリング」で詳細を説明します。
コマンドライン・オプションおよびシステム・プロパティのリストは、「OC4Jのコマンドライン・オプションおよびシステム・プロパティ」を参照してください。
Webサイトを構成するには、「管理」ページの「インスタンス・プロパティ」列で「Webサイト・プロパティ」を選択します。
Webサイト・ページには、2つのセクションがあります。第1セクションには、デフォルトWebアプリケーションが表示されます。第2セクションの「WebモジュールのURLマッピング」には、各Webアプリケーションが起動時にロードされるかどうかを指定します。 これらのパラメータについては、『Oracle Application Server Containers for J2EEサーブレット開発者ガイド』で詳しく説明されています。パラメータの格納先はdefault-web-site.xmlファイルです。
グローバルJSPコンテナ・パラメータを構成できます。このOC4JインスタンスにデプロイされているすべてのJSPに適用されます。JSPコンテナ・パラメータを構成するには、「管理」ページの「インスタンス・プロパティ」列で「JSPコンテナのプロパティ」を選択します。これにより、次のページが表示されます。
ここに示したプロパティのほとんどは、『Oracle Application Server Containers for J2EE JavaServer Pages開発者ガイド』の第3章で説明されています。これらのプロパティは、<servlet>要素内のglobal-web-application.xmlファイルで指定できます。
サーブレットまたはEJBをクラスタリングする場合、レプリケーション・パラメータを構成する必要があります。 詳細は、「OC4Jインスタンスの設定」を参照してください。
OC4Jリリース1.0.2.2では、OC4Jサーバーとデプロイされているすべてのアプリケーション・パラメータをXMLファイルによって構成しました。この方法は、OC4Jサーバーが単一ノードに存在し、高可用性とクラスタ管理が必要でなかったため、うまく機能していました。しかし、OC4JとOracle Application Serverが統合され、クラスタリングと高可用性のオプションによりエンタープライズ管理機能が高まり、あらゆる構成をEnterprise Managerによって行う必要があります。
「管理」ページから「拡張プロパティ」を選択すると、OC4JサーバーのXMLファイルを変更できます。これらのファイルには、サーバーとそのサービスを構成するXMLファイルが含まれます。このグループのファイルは、server.xml、global-web-application.xml、rmi.xml、jms.xmlおよびdefault-web-site.xmlです。これらのXMLファイルは、OC4Jホームページの「拡張プロパティ」ページで変更します。
他のXML構成ファイルは、Oracle9iASコンソールの他の領域で変更できます。
application.xml、data-sources.xml、セキュリティXMLファイルおよびoc4j-connectors.xmlが該当します。これらのXMLファイルを変更するには、OC4Jホームページから「アプリケーション」を選択します。「アプリケーション」ページでデフォルトを選択します。デフォルト・アプリケーション・ページで、「管理」セクションまでスクロールして、「拡張プロパティ」を選択します。
data-sources.xml、orion-application.xmlおよびセキュリティXMLファイルがあります。これらのファイルを変更するには、「アプリケーション」ページの「デプロイ済アプリケーション」セクションから特定アプリケーションまでドリルダウンします。指定したアプリケーション画面で、「管理」セクションまでスクロールして、「拡張プロパティ」を選択します。
web.xml、orion-web.xml、ejb-jar.xmlおよびorion-ejb-jar.xmlなどのモジュール・デプロイメント・ディスクリプタを指定しています。パラメータの変更は、OC4J固有のXMLファイル（orion-xxx.xml）でのみ可能です。web.xmlまたはejb-jar.xmlなどのJ2EE XMLファイルは、変更できません。これらのXMLファイルの変更については、「デプロイ済アプリケーションEARファイルに含まれるXMLファイルの変更」を参照してください。
例として、server.xmlページを示します。XML要素は、手入力で編集できます。
OC4J XMLファイルの概要は、これらのファイルとそれぞれの関係について説明する「OC4JおよびJ2EEのXMLファイルの概要」を参照してください。各ファイル内の要素については、OC4Jドキュメントのその他のマニュアルで説明されています。
グローバルまたはローカルのデータ・ソースを構成できます。グローバル・データ・ソースは、このOC4Jインスタンスにデプロイされたすべてのアプリケーションで使用可能です。ローカル・データ・ソースは、デプロイされたアプリケーション内に構成され、そのアプリケーションでのみ使用可能です。
データ・ソースとdata-sources.xmlファイル内の要素の構成方法の詳細は、『Oracle Application Server Containers for J2EEサービス・ガイド』を参照してください。
グローバル・データ・ソースを構成するには、OC4Jホームページから次のいずれかを選択します。
data-sources.xmlファイルに直接アクセスすることで、データ・ソースを変更または追加できます。
ローカル・データ・ソースを構成するには、アプリケーション・ページから同様に選択します。このデータ・ソースが使用される特定アプリケーションにドリルダウンする必要があります。アプリケーション・ページで、「リソース」列の「データ・ソース」を選択します。 「データ・ソース・フィールド・ページ」で説明しているデータ・ソース・フィールド・ページと同じページが表示されます。
新しいデータ・ソースを構成するには、「データ・ソースの追加」をクリックします。これにより、データ・ソースに関するすべての構成の詳細を入力するページが表示されます。このページは、4つのセクションに分かれています。
図3-7は「一般」セクションです。
「一般」セクションでは、データ・ソースに関する次のパラメータを定義できます。
com.evermind.sql.DriverManagerDataSourceなどのクラス。
jdbc:oracle:thin:@my-lap:1521:<service_name>のようになります。
oracle.jdbc.driver.OracleDriverがあげられます。
図3-8はユーザー名とパスワードです。
ユーザー名/パスワード: このデータ・ソースに相当するデータベースへの認証に使用するユーザー名とパスワード。パスワードは平文で入力することも、間接的パスワードにユーザー名を指定することもできます。詳細は、『Oracle Application Server Containers for J2EEサービス・ガイド』を参照してください。
図3-9は「JNDIロケーション」セクションです。
「JNDIロケーション」セクションで、データ・ソースがバインドされるJNDIロケーションの文字列を定義できます。このJNDIロケーションは、このデータ・ソースを検索するためにJNDI参照内で使用されます。
図3-10は「接続の属性」セクションです。
このセクションでは、再試行間隔、プーリング・パラメータ、タイムアウト・パラメータ、最大試行回数パラメータなどの接続チューニング・パラメータを変更します。
図3-11はデータ・ソースの「プロパティ」セクションです。
データ・ソースがサード・パーティのデータ・ソースである場合、特定のプロパティの設定が必要になることがあります。そのプロパティは、サード・パーティのドキュメントに定義されています。さらに、2フェーズ・コミット・コーディネータのJTAトランザクションについて、プロパティを設定する必要があります。
ユーザー・マネージャでは、ユーザー名とパスワードを使用して、ユーザー・リポジトリの情報に基づきユーザーのIDを検証します。使用する認証のタイプは、ユーザー・マネージャにより定義されます。この定義には、ユーザー、グループまたはロールの定義も含まれています。デフォルトのユーザー・マネージャはJAZNUserManagerです。すべてのアプリケーションまたは特定のアプリケーション用のユーザー・マネージャを指定することができます。
ユーザー・マネージャを含めて、OC4Jセキュリティの詳細は、『Oracle Application Server Containers for J2EEセキュリティ・ガイド』を参照してください。
JMSは、JMSのセクション内で構成することも、jms.xmlファイル内で直接構成することもできます。
Oracle JMSまたはサード・パーティのJMSプロバイダを追加するには、「管理」ページの「アプリケーション・デフォルト」列で「JMSプロバイダ」を選択します。これにより、次のページが表示されます。
各JMSプロバイダを構成するために「新規JMSプロバイダの追加」ボタンをクリックすると、次のページが表示されます。
このページでは、Oracle JMSまたはサード・パーティのJMSプロバイダのいずれかを構成できます。OC4Jがインストールされていると、トピックおよびキュー以外は、常にOracleAS JMSが指定され、事前に構成されています。
JMSプロバイダのタイプを選択した場合、次の情報を指定する必要があります。
java.naming.factory.initialおよびjava.naming.provider.urlなど、このJMSプロバイダのJNDIプロパティを追加するには、「プロパティの追加」をクリックします。各JNDIプロパティの名前と値の追加用に、1行ずつ追加されます。
ここで構成されるのはプロバイダのみで、Destinationオブジェクト（トピック、キューおよびサブスクリプション）は構成されません。JMSプロバイダの詳細は、『Oracle Application Server Containers for J2EEサービス・ガイド』を参照してください。
特定のアプリケーション専用のJMSプロバイダを構成するには、「アプリケーション」ページからアプリケーションを選択して、「リソース」列までスクロールし、「JMSプロバイダ」を選択します。表示される画面は、デフォルトのJMSプロバイダの場合と同じです。
OracleAS JMS用のキューおよびトピックを追加するには、次のようにjms.xmlファイルを直接編集できます。「管理」ページの「インスタンス・プロパティ」列で「拡張サーバー・プロパティ」セクションを選択します。このセクションでjms.xmlを選択し、XMLファイルを修正します。『Oracle Application Server Containers for J2EEサービス・ガイド』で、jms.xmlファイル内の要素の説明を参照してください。
デプロイされたすべてのWebアプリケーションに適用するWebパラメータを構成するには、「管理」ページの「アプリケーション・デフォルト」列で「グローバルWebモジュール」を選択します。これにより、次のページが表示されます。
Webモジュール用に定義できるパラメータのタイプは、マッピング、フィルタリング、チェーン、環境およびセキュリティに関するものです。これらのパラメータを変更するには、「プロパティ」列と「セキュリティ」列に表示された各リンクをドリルダウンします。 これらのパラメータの詳細は、『Oracle Application Server Containers for J2EEサーブレット開発者ガイド』を参照してください。これらのパラメータは、global-web-application.xmlおよびorion-web.xmlファイルに格納されます。このマニュアルでは、これらのファイルの要素について説明します。
RMIは、XML定義内でのみ定義可能です。rmi.xmlファイルを編集するには、「管理」ページの「インスタンス・プロパティ」列で「拡張プロパティ」を選択します。このセクションでrmi.xmlを選択し、XMLファイルを修正します。『Oracle Application Server Containers for J2EEサービス・ガイド』で、rmi.xmlファイル内の要素の説明を参照してください。
EARまたはWARファイル・アーカイブ形式で存在するJ2EEアプリケーションをデプロイ、再デプロイまたはアンデプロイすることができます。アプリケーションをデプロイするには、「アプリケーション」ページの「デプロイ済アプリケーション」セクションでデプロイ用の「EARファイルのデプロイ」ボタンまたは「WARファイルのデプロイ」ボタンをクリックします。
これにより、「アプリケーションのデプロイ」で説明したデプロイ・ウィザードが起動します。EARファイルをデプロイする場合は、アプリケーション・モジュールを説明するapplication.xmlがこのファイルに含まれている必要があり、WARファイルをデプロイする場合は、application.xmlファイルが自動で作成されます。
アンデプロイするには、アプリケーションの「選択」ラジオ・ボタンを選択してから、「アンデプロイ」ボタンをクリックします。
再デプロイするには、アプリケーションの「選択」ラジオ・ボタンを選択してから、「再デプロイ」ボタンをクリックします。
アプリケーションをデプロイすると、このアプリケーションのほとんどのパラメータを変更できます。アプリケーション固有のパラメータを構成するには、次のようにします。
このページは、全般的なアプリケーション構成のみでなく、WARファイルなど、デプロイ済アプリケーションの特定の部分に固有の構成を変更するための開始ページです。
次の項では、これらの構成オプションの概要を説明します。
アプリケーションまでドリルダウンして、「プロパティ」列までスクロールし、「一般」リンクを選択すると、次のような数多くのアプリケーションの詳細を構成できます。
「データ・ソースの構成」と「セキュリティの構成」で説明されているように、データ・ソースとセキュリティは、デプロイされているすべてのアプリケーション（グローバル）または特定アプリケーション（ローカル）のいずれかに対して構成できます。アプリケーションに対してJ2EEサービスを構成する手順は、これらの項を参照してください。
デプロイ後に変更できるのは、アプリケーションのOC4J固有のXMLファイルのみです。これは、orion-ejb-jar.xml、orion-web.xmlおよびorion-application-client.xmlです。web.xml、ejb-jar.xmlおよびapplication-client.xmlなどのJ2EE XMLファイルは、変更できません。
OC4J固有のXMLファイルを変更するには、次のようにします。
この項には、次の項目が含まれています。
OC4J内の各XMLファイルは、特定の役割のために存在します。そのため、その役割が必要な場合、どのXMLファイルで変更およびメンテナンスを行うかを理解する必要があります。
図3-15は、OC4JのすべてのXMLファイルとそれぞれの役割を示しています。
これらのファイルは、OC4Jサーバーを構成し、その他の主要な構成ファイルを指します。OC4J構成ファイルの設定は、デプロイされたJ2EEアプリケーションとは直接関係なく、サーバーそのものに関係があります。
orion-という接頭辞が付けられています。また、次のファイルは、アプリケーションのあらゆるコンポーネントのためのグローバル構成ファイルです。
application.xml。
orion-application.xmlファイル。
global-web-application.xmlファイル。
oc4j-connectors.xmlファイル。
表3-1は、前の図で示した各XMLファイルの役割および機能を説明しています。
これらのXMLファイルの一部は、相互に関連性があります。つまり、一部のXMLファイルは、他のXMLファイル（OC4J構成およびJ2EEアプリケーションの両方）を参照します（図3-17を参照）。
相互関連ファイルは次のとおりです。
server.xml: 次のファイルへの参照が含まれています。
default-web-site.xmlファイルを含む、このOC4Jサーバーの各Webサイトのすべての*-web-site.xmlファイル。
application.xmlで定義されているjazn-data.xmlおよびdata-sources.xmlは除きます。図3-15にこれを示します。
application.xmlファイルの場所。
default-web-site.xml: server.xmlファイルで定義されるように、名前でアプリケーションを参照します。また、このファイルはアプリケーション固有のEARファイルを参照します。
application.xml: jazn-data.xmlおよびdata-sources.xmlファイルへの参照が含まれます。
server.xmlファイルは、OC4Jサーバーで使用されている大部分のファイルへの参照を含んでいる中核ファイルです。 図3-16に、server.xmlファイルで参照される可能性のあるXMLファイルを示します。
図3-17は、server.xmlで他のXML構成ファイルを指定する方法を示します。各XMLファイルの場所は、絶対パスまたはserver.xmlファイルが存在する場所に対する相対パスで指定します。また、XMLファイルの名前は、そのファイル内容が適切なDTDに準拠していればどのような名前でもかまいません。
<rmi-config>タグは、rmi.xmlファイルの名前と場所を示します。
<jms-config>タグは、jms.xmlファイルの名前と場所を示します。
<global-application>タグは、グローバルapplication.xmlファイルの名前と場所を示します。
<global-web-app-config>タグは、global-web-application.xmlファイルの名前と場所を示します。
<web-site>タグは、*-web-site.xmlファイルの名前と場所を示します。複数のWebサイトを使用できるため、複数の<web-site>エントリを指定できます。
OC4Jサーバー構成ファイルの指定に加えて、server.xmlファイルでは、このOC4Jサーバーにデプロイされたアプリケーションについても記述されています。デプロイされた各アプリケーションは、<application>タグで示します。
server.xmlの他のタグについては、「server.xmlファイルの要素」を参照してください。
複数のアプリケーションでライブラリを共有する場合は、次のように<library>要素をグローバルapplication.xmlファイルに追加し、ライブラリを配置するディレクトリを指定します。
Windowsの場合:
<library path="d:¥oc4j¥j2ee¥home¥applib¥"/>
UNIXの場合:
<library path="/private/oc4j/j2ee/home/applib/"/>
次のように、含めるディレクトリごとに、別々の行で別々の<library>要素を使用します。
<library path="/private/oc4j/j2ee/home/applib/"/> <library path="/private/oc4j/j2ee/home/mylibrary/"/>
デフォルトでは、<library>要素は、j2ee/home/applibディレクトリ内のグローバルapplication.xmlファイルに存在します。<library>要素を他のディレクトリが含まれるように変更するかわりに、ライブラリをapplibディレクトリに移動することもできます。ただし、このディレクトリにライブラリを追加すると、OC4Jのサイズが増加し、不明なクラスの検索時にはすべてのライブラリが検索されるために、パフォーマンスに影響が出ます。この手順を使用する場合は注意してください。
できれば、共有ライブラリは、アプリケーションとともにデプロイされるorion-application.xmlファイルにより、そのアプリケーション専用にしておくことをお薦めします。アプリケーションのorion-application.xmlファイルに<library>要素を追加することで、そのアプリケーション内でのみ使用されるライブラリの場所を指定できます。
受信クライアント・リクエストでは、AJP、HTTPまたはRMIの3つのプロトコルのいずれかが使用されます。AJPとHTTPは、HTTPリクエストに使用されます。AJPは、OHSとOC4Jコンポーネントの間で使用されます。HTTPは、OHSを通り過ぎてOC4Jに送られるHTTPリクエストに使用されます。RMIは受信EJBリクエストに使用されます。
HTTPリクエストは、OHSを経由するか、OC4Jに直接送信されるかにかかわらず、1つのOC4J Webサイトに1つのリスナーが構成されている必要があります。 OC4Jインスタンスごとに複数のWebサイトを持ち、プロトコル・タイプ別に使用できます。1つのWebサイトで両タイプのプロトコルをリスニングすることはできません。このため、OC4Jでは、次の2つのWebサイト構成ファイルを提供しています。
default-web-site.xml: これは、AJPプロトコル・リスナーであり、Oracle Application Serverを使用する大部分のHTTPリクエストのデフォルトです。インストール後に、Oracle HTTP Serverのフロントエンドが受信HTTPリクエストをAJPポート上で転送します。 OC4J Webサーバーの構成ファイル（default-web-site.xml）で、AJPリスナー・ポートが指定されます。 default-web-site.xmlファイルでは、デフォルトのAJPポートが0（ゼロ）に定義されます。これにより、OC4JおよびOracle HTTP Serverでは、起動時にポートのネゴシエーションが可能になります。 AJPポート値の範囲は、OPMN構成で構成します。 OPMNの詳細は、『Oracle Application Server管理者ガイド』の「高可用性」の章を参照してください。
デフォルトAJPリスナー用のdefault-web-site.xml内のエントリは、次のとおりです。
<web-site host="oc4j_host" port="0" protocol="ajp13"
display-name="Default OC4J WebSite">
AJPのデフォルトWebサイト・プロトコルは、OC4Jホームページの「Webサイト・プロパティ」または「拡張プロパティ」で構成できます。
http-web-site.xml: これは、HTTPプロトコル・リスナーです。 OC4Jスタンドアロン環境のように、OHSを介さずに直接OC4Jに送信する場合は、このファイルに定義されたポート番号を使用します。 AJPポートは、OC4Jの起動時に毎回無作為に選択されることに注意してください。このポート番号がこのXMLファイルにハードコードされたポート番号と同じになると、競合が発生します。 受信リクエストにこの方法を使用する場合は、選択したポート番号がAJPポート番号の範囲外であることを確認します。AJPポート番号の範囲は、OPMN構成に定義されています。
デフォルトのHTTPポートは8888です。 http-web-site.xml内のポート番号8888のHTTPリスナーのエントリは、次のとおりです。
<web-site host="oc4j_host" port="8888" protocol="http"
display-name="HTTP OC4J WebSite">
RMIプロトコル・リスナーは、RMI構成（rmi.xml）のOPMNにより設定されます。これは、Webサイト構成とは異なります。EJBクライアントおよびOC4Jツールは、構成済のRMIポートを通じてOC4Jサーバーにアクセスします。OPMNは、RMIリスナーが使用できるポートの範囲を指定します。参照内でopmn:ormi://という文字列を使用すると、クライアントは割り当てられたRMIポートを自動的に取得します。 詳細は、『Oracle Application Server Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。
OC4J 10.1.2の実装では、（Webサイトへのリクエストをログに記録するために使用する）OC4Jのアクセス・ロギングをモジュールベースで無効にする新機能が、WebサイトのXMLファイルにあります。
一般的には、（default-web-site.xmlやhttp-web-site.xmlなど）WebサイトのXMLファイルの<web-site>要素の<access-log>サブ要素を使用して、Webサイトに対するテキストベースのアクセス・ロギングが有効となります。 または、<web-site>要素の<odl-access-log>サブ要素を使用して、Webサイトに対するOracle Diagnostic Logging（ODLベースのアクセス・ロギング）が有効となります。
リリース2（10.1.2）では、特定のWebアプリケーション（モジュール）に対し、そのWebアプリケーションの<web-app>要素のaccess-log属性を使用して、テキストベースのロギングまたはODLベースのロギング（該当する場合）を無効にできます。 <web-app>要素は、<web-site>の別のサブ要素です。 Webアプリケーションに対しaccess-log="false"と設定すると、すべての<access-log>要素または<odl-access-log>要素がオーバーライドされ、そのWebアプリケーションが動作している間はロギングが無効となります。
次の例では、defaultアプリケーションのdms0モジュールのロギングは無効になりますが、admin_webモジュールのテキストベースのロギングは有効のままです。
<web-site ... > ... <web-app application="default" name="dms0" root="/dms0" access-log="false" /> <web-app application="default" name="admin_web" root="/adminoc4j" /> <access-log path="../log/http-web-access.log" /> ... </web-site>
アクセス・ロギングの関連情報は、『Oracle Application Server Containers for J2EEサーブレット開発者ガイド』を参照してください。
Oracle HTTP Serverのmod_oc4jモジュールは、j2ee/コンテキストにバインドされているアプリケーションをすべてOC4Jサーバーに送るよう、インストール時に構成されています。pubs/など、別のコンテキストを使用する場合、mod_oc4j.conf構成ファイルで、このコンテキスト用に別のマウントを追加できます。
このファイルを変更するには、「Oracle HTTP Server」ページにドリルダウンして、mod_oc4j.confを選択します。編集用のファイルが右側のフレームに表示されます。
j2ee/ディレクトリのOc4jMountディレクティブを探します。これを別の行にコピーします。マウント・ディレクティブは、次のようになります。
Oc4jMount /j2ee/* OC4Jworker
j2ee/コンテキストを、使用するコンテキストに変更します。この例の場合、pubs/マウント構成の行が追加されます。OC4Jのワーカー名がOC4Jworkerの場合、この2行は次のようになります。
Oc4jMount /j2ee/* OC4Jworker Oc4jMount /pubs/* OC4Jworker
これにより、pubs/コンテキストの受信リクエストはすべてOC4Jサーバーに送られます。デプロイ・ウィザードを使用してアプリケーションをデプロイすると、ここで説明したようにURLマッピングに対してマウント・ポイントが自動的に追加されます。
mod_oc4jモジュール構成の詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。
アプリケーションの開発時には、クラスをすばやく修正、コンパイルおよび実行する必要があります。OC4Jでは、開かれたディレクトリ形式でアプリケーションを開発しているときにアプリケーションを自動的にデプロイできます。OC4Jは、図3-18の<appname>に書かれたトップ・ディレクトリのタイムスタンプが変わると、自動的にアプリケーションをデプロイします。このディレクトリをserver.xmlがマスターの場所として認識します。
アプリケーションは、JAR、WARおよびEARファイルに必要な階層形式と同じ階層形式のマスター・ディレクトリに配置する必要があります。たとえば、<appname>がJ2EEアプリケーションの存在するディレクトリである場合、必要なディレクトリ構造は図3-18のようになります。
EJBまたは複合J2EEアプリケーションを開かれたディレクトリ形式でデプロイするには、次の手順を実行します。
j2ee/home/applications/<appname>/に配置されたアプリケーションを示しています。<appname>下のディレクトリ構造は、EARファイル内で使用されるディレクトリ構造と次のように類似しています。
<ejb_module>/、<web_module>/、<client_module>/および<connector_module>/で示します。
server.xml、application.xmlおよび*-web-site.xmlファイルを、次のように変更します。server.xmlおよび*-web-site.xmlファイルはj2ee/home/configディレクトリに置かれ、application.xmlはj2ee/home/applications/<appname>/META-INFディレクトリに置かれます。これらのファイルを次のように変更します。
server.xmlで、各J2EEアプリケーションに対し、<application name=... path=... auto-start="true" />要素を新しく追加するか、または既存の要素を変更します。パスは、マスターのアプリケーション・ディレクトリを指します。 図3-18では、j2ee/home/applications/<appname>/に該当します。パスは、次のいずれかの方法で指定します。
図3-18の例では、<appname>が"myapp"の場合、絶対パスは次のようになります。
<application_name="myapp" path="/private/j2ee/home/applications/myapp" auto-start="true" />
server.xmlファイルの相対的な場所を示します。図3-18の例では、<appname>が"myapp"の場合、相対パスは次のようになります。
<application_name="myapp" path="../applications/myapp" auto-start="true" />
application.xmlで、<module>要素に、JARまたはWARファイルではなく、各モジュールのディレクトリ名を指定します。application.xmlファイルの<web-uri>、<ejb>および<client>要素は、これらのモジュールが存在するディレクトリを指定するように変更する必要があります。これらの要素に含まれるパスは、マスターのディレクトリの相対パスであり、これらの各アプリケーション・タイプのWEB-INFまたはMETA-INFディレクトリの親ディレクトリである必要があります。 たとえば、図3-18の<web_module>/ディレクトリがmyapp-web/の場合、次の例では、これを<web-uri>要素内でWebモジュール・ディレクトリとして指定しています。
<module> <web> <web-uri>myapp-web</web-uri> </web> </module>
*-web-site.xmlファイルで各Webアプリケーションに対し、<web-app...>要素を追加します。これによってWebアプリケーションがWebサイトにバインドされるため、この手順は重要です。アプリケーションの属性値は、server.xmlファイルの値と同じである必要があります。name属性は、Webアプリケーションのディレクトリにする必要があります。name要素内のディレクトリ・パスは、application.xmlファイル内の<web-uri>要素のパスの場合と同じ規則に従う必要があります。Webアプリケーション"myapp"をバインドするには、次のパスを追加します。
<web-app application="myapp" name="myapp-web" root="/myapp" />
mod_oc4j.conf構成ファイルにWebアプリケーションのマウント・ポイントを追加します。この例のroot="/myapp"に基づき、次の行が含まれるようにmod_oc4j.confを更新する必要があります。
Oc4jMount /myapp home Oc4jMount /myapp/* home
OC4Jの初期化後またはOC4Jの終了前にコールされるクラスを開発できます。起動クラスは、OC4Jの初期化後にサービスを起動して機能を実行し、停止クラスは、OC4Jの終了前にこれらのサービスを終了して機能を実行します。これらのクラスをコンパイルする場合、oc4j.jarがJavaのCLASSPATHに含まれている必要があります。
OC4Jは、server.xmlファイル内のこれらのクラスの構成に基づいて、OC4J起動クラスおよび停止クラスをデプロイおよび実行します。
起動クラスは、OC4Jの初期化後に1回のみ実行されます。 server.xmlファイルが読み込まれるたびに再実行されるわけではありません。起動クラスは、preDeployおよびpostDeployという2つのメソッドを含むcom.evermind.server.OC4JStartupインタフェースを実装します。ここには、サービスの開始およびその他の初期化ルーチンを実行するコードを実装できます。
各メソッドは2つの引数を必要とします。Hashtableは構成から移入され、JNDI Contextでは、Context内に含まれるプロセス値をバインドできます。両方のメソッドが文字列を返しますが、現在のところは無視されます。
起動クラスを作成した場合、server.xmlファイルの<startup-classes>要素内で構成する必要があります。このファイルにアクセスするには、OC4Jホームページの「拡張プロパティ」を選択します。各OC4JStartupクラスは、<startup-classes>要素内の1つの<startup-class>要素に定義されます。各<startup-class>では次のものを定義します。
com.evermind.server.OC4JStartupインタフェースを実装するクラスの名前。
String型のキーと値のペアを含む初期化パラメータ。入力されたHashtable引数の中で指定されます。JNDIを使用して各値をその名前とバインドするため、キーと値のペアの名前は一意である必要があります。
server.xmlファイルの<init-library path="../[xxx]" />エレメントで、起動クラスを配置するディレクトリを構成するか、またはクラスがアーカイブされるディレクトリとJARファイル名を構成します。path属性には絶対パス、またはj2ee/home/configの相対パスを指定できます。
TestStartupクラスの構成は、server.xmlファイルの<startup-class>要素に含まれています。構成では次のように定義します。
failure-is-fatal属性をtrueに設定し、例外によりOC4Jが終了するようにします。
execution-orderを0（ゼロ）に設定し、これが実行される最初の起動クラスであることを示します。
Stringタイプの2つの初期化キーと値のペアを定義します。これは、次のHashtableに移入されます。
"oracle.test.startup" "true" "startup.oracle.year" "2002"
このため、server.xmlファイルに次のように構成してTestStartupクラスを定義します。
<startup-classes> <startup-class classname="TestStartup" failure-is-fatal="true"> <execution-order>0</execution-order> <init-param> <param-name>oracle.test.startup</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>startup.oracle.year</param-name> <param-value>2002</param-value> </init-param> </startup-class> </startup-classes>
コンテナは、入力したHashtableパラメータ内で、起動クラスに2つの初期化キーと値のペアを提供します。
次の例は、com.evermind.server.OC4JStartupインタフェースを実装するTestStartupを示しています。preDeployメソッドはHashtableからキーと値のペアを取得して出力します。postDeployメソッドはNULLのメソッドです。これらのクラスをコンパイルする場合、oc4j.jarがJavaのCLASSPATHに含まれている必要があります。
import com.evermind.server.OC4JStartup; import javax.naming.*; import java.util.*; public class TestStartup implements OC4JStartup { public String preDeploy(Hashtable args, Context context) throws Exception { // bind each argument using its name Enumeration keys = args.keys(); while(keys.hasMoreElements()) { String key = (String)keys.nextElement(); String value = (String)args.get(key); System.out.println("prop: " + key + " value: " + args.get(key)); context.bind(key, value); } return "ok"; } public String postDeploy(Hashtable args, Context context) throws Exception { return null; } }
TestStartupクラスが"../app1/startup.jar"にアーカイブされているものと仮定し、server.xmlファイルの<init-library>要素を次のように変更します。
<init-library path="../app1/startup.jar" />
OC4Jを起動すると、すべてのアプリケーションの初期化前にpreDeployメソッドが実行されます。OC4JはHashtableからの値を使用してJNDIコンテキストを移入します。TestStartupが例外をスローすると、failure-is-fatal属性がTRUEに設定されているため、OC4Jは終了します。
停止クラスはOC4Jの終了前に実行されます。停止クラスでは、preUndeployおよびpostUndeployという2つのメソッドを含むcom.evermind.server.OC4JShutdownインタフェースを実装します。ここには、サービスの停止およびその他の終了ルーチンを実行するコードを実装できます。
各メソッドは2つの引数を必要とします。Hashtableは構成から移入され、JNDI Contextでは、Context内に含まれるプロセス値をバインドできます。
実装と構成は、「OC4J起動クラス」で説明した停止クラスと同じですが、<shutdown-classes>および<shutdown-class>要素内に構成が定義されることと、failure-is-fatal属性がないことが異なります。このため、TestShutdownクラスの構成は次のようになります。
<shutdown-classes> <shutdown-class classname="TestShutdown"> <execution-order>0</execution-order> <init-param> <param-name>oracle.test.shutdown</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>shutdown.oracle.year</param-name> <param-value>2002</param-value> </init-param> </shutdown-class> </shutdown-classes>
TestShutdownクラスが"../app1/shutdown.jar"にアーカイブされているものと仮定し、server.xmlファイルの<init-library>要素を次のようにもう1つ追加します。
<init-library path="../app1/shutdown.jar" />
起動クラスと停止クラスの開発時には、次の問題に注意してください。
パフォーマンスの設定の多くは『Oracle Application Serverパフォーマンス・ガイド』に記載されています。
OC4Jコマンドライン・オプションを使用するか、該当するXMLファイル要素を編集して、ユーザー自身でこれらのパフォーマンス設定を管理できます。
dedicated.rmicontextオプションを除き、各-Dコマンドライン・オプションでは、推奨設定値がデフォルトになります。しかし、OC4Jオプションとして各-Dコマンドライン・オプションを指定することにより、これらのオプションを変更できます。この例は、「OC4Jのコマンドライン・オプションおよびシステム・プロパティ」を参照してください。
dedicated.rmicontext=true/false。デフォルト値はfalseです。これにより、すでに使用されなくなったdedicated.connection設定が置き換えられます。同一プロセス内の複数のクライアントがInitialContextを取り出すと、OC4Jはキャッシュされているコンテキストを返します。したがって、各クライアントは、そのプロセスに割り当てられている同じInitialContextを受け取ります。結果的にサーバーのロード・バランシングにつながるサーバー参照は、クライアントが独自のInitialContextを取り出すときにのみ発生します。dedicated.rmicontext=trueを設定すると、各クライアントは共有コンテキストではなくそのクライアント独自のInitialContextを受け取ります。各クライアントに独自のInitialContextがある場合、クライアントのロード・バランシングが可能です。 このパラメータはクライアント用です。JNDIプロパティで設定することもできます。
oracle.dms.sensors=[none, normal, heavy, all]。Oracle9iAS組込みのパフォーマンス・メトリックの値を、none（オフ）、normal（中程度のメトリック）、heavy（大きなメトリック）またはall（可能なすべてのメトリック）に設定できます。デフォルトはnormalです。このパラメータはOC4Jサーバーで設定する必要があります。これらのパフォーマンス・メトリックを有効にするための以前のメソッドであるoracle.dms.gate=true/falseは、oracle.dms.sensors変数で置き換えられました。ただし、oracle.dms.gateを使用している場合、この変数をfalseに設定すると、oracle.dms.sensors=noneの設定と同じ意味になります。
DefineColumnType=true/false。デフォルトはfalseです。9.2より前のOracle JDBCドライバを使用している場合は、trueに設定してください。これらのドライバの場合、この変数をtrueに設定することにより、Oracle JDBCドライバに対してSelectを実行する場合のラウンドトリップを回避できます。このパラメータはOC4Jサーバーで設定する必要があります。 このオプションの値を変更してOC4Jを再起動すると、この変更の後にデプロイされるアプリケーションに対してのみ有効になります。変更前にデプロイされたアプリケーションには影響はありません。
trueに設定すると、DefineColumnType拡張により、通常は表の記述に必要なデータベース・ラウンドトリップが節約されます。Oracle JDBCドライバで問合せを実行した場合、結果セットの列で使用する型を判別するために、最初にデータベースへのラウンドトリップを使用します。次に、JDBCは問合せからのデータを受け取ると、データを必要に応じて変換し、結果セットに移入します。DefineColumnType拡張をtrueに設定して問合せの列の型を指定すると、Oracleデータベースへの最初のラウンドトリップが回避されます。そのように最適化されているサーバーは、必要な型変換を実行します。
スレッド・プールは、OC4Jプロセスで使用するためのスレッドのキューを作成およびメンテナンスします。要求に応じて新規スレッドを作成するのではなく、既存のスレッドを再利用することで、パフォーマンスが高まり、JVMおよび基礎となるオペレーティング・システムに対する負荷を軽減します。
デフォルトでは、OC4Jの起動時に1つのスレッド・プールが作成されます。必要に応じて新しいスレッドが作成され、プールに追加されます。各スレッドは解放されるとプールに返され、新しいリクエストで必要となるまで待機します。
プール内のスレッドは、非アクティブ状態が10分経過すると自動的に破棄されます。この構成内で作成可能なスレッド数に制限はありません。
デフォルト構成で、OC4Jによって使用されるほとんどの場合に十分対応できます。ただし、デフォルトで作成された単一のスレッド・プールは、server.xmlファイル内の<global-thread-pool>要素のmin、max、queueおよびkeepAlive属性により変更できます。
または、<global-thread-pool>を使用してスレッド・プールを2つ作成し、これらのプールで異なるタイプのスレッドを振り分けることができます。
2つのプールを作成する場合、ワーカー・スレッド・プールにはmin、max、queueおよびkeepAlive属性を、接続スレッド・プールにはcx-min、cx-max、cx-queueおよびcx-keepAlive属性を構成する必要があります。これらの属性はすべてプール作成の場合に構成する必要があり、構成しないと、次のエラー・メッセージが表示されます。
Error initializing server: Invalid Thread Pool parameter: null
<global-thread-pool>の属性の説明は、表3-2を参照してください。
次の例では、OC4Jプロセスの2つのスレッド・プールを初期化します。各プールは最小10、最大100のスレッドを含みます。各キューに保持可能な未処理リクエストは200です。また、アイドル・スレッドは700秒間キープ・アライブとします。スレッド・プール情報を起動時に出力します。
<application-server ...> ... <global-thread-pool min="10" max="100" queue="200" keepAlive="700000" cx-min="10" cx-max="100" cx-queue="200" cx-keepAlive="700000" debug="true"/> ... </application-server>
表3-2では、<global-thread-pool>要素の属性について説明しています。この要素は、デフォルトではserver.xmlに含まれていないので注意してください。
スレッド・プール構成に関するその他の注意は次のとおりです。
queue属性は、スレッドの最大数の少なくとも2倍のサイズに設定してください。
cx-min属性およびcx-max属性は、任意の時点での物理接続数に関連しています。cx-queueは接続通信量の急増に対応します。
データベース文のキャッシングにより、カーソル作成の反復、および文の解析と作成の反復によるオーバーヘッドを避けることができます。DataSource構成でJDBC文のキャッシングを有効にすると、反復的に使用される実行可能文がキャッシングされます。JDBC文のキャッシュは、特定の物理接続と関連します。 文のキャッシングの詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』を参照してください。
接続オブジェクトのsetStmtCacheSize()メソッドを使用するか、DataSource構成内のstmt-cache-size XML属性を使用して、文のキャッシングをプログラムで動的に有効または無効にできます。キャッシュのサイズの整数値が必要です。指定したキャッシュ・サイズが、キャッシュ内の文の最大数になります。アプリケーションからデータベースに対して発行される個別の文の数を判断してください。そしてキャッシュのサイズをこの数に設定します。
この属性を指定しないか、ゼロに設定すると、キャッシュは無効になります。
次のXMLは、文のキャッシュ・サイズを200に設定します。
<data-source> ... stmt-cache-size="200" </data-source>
タスク・マネージャは、クリーンアップを実行するバックグラウンド・プロセスです。ただし、タスク・マネージャを使用すると負荷が大きくなる可能性があります。server.xml内のtaskmanager-granularity属性を使用して、タスク・マネージャの作業のタイミングを管理できます。この属性は、クリーンアップのためにタスク・マネージャを起動する頻度を示します。値はミリ秒単位です。デフォルトは1000ミリ秒です。
<application-server ... taskmanager-granularity="60000" ...>
OC4Jはメッセージを標準エラー、標準出力の両方、およびOC4Jのサービスおよびデプロイ済アプリケーションの複数のログ・ファイルに記録します。
Oracle9iAS環境内の各OC4Jプロセスには、表3-3のようなログ・ファイルのセットがあります。1つのOC4Jインスタンスに対して複数のプロセスが実行されている場合は、複数セットのログ・ファイルがあります。
ログ・ファイルには2つのタイプがあります。
各ODLログ・エントリは、それぞれのログ・ファイルにXML形式で書き込まれます。XMLメッセージは、Enterprise Manager GUIまたはXMLリーダーで読み取ることができます。ODLロギングの利点は、ログ・ファイルとディレクトリに最大値の制限があることです。制限に達すると、ログ・ファイルは上書きされます。
ODLロギングを有効にすると、新規のメッセージはlog.xmlという現行ログ・ファイルに記録されます。ログ・ファイルが満杯になる、つまりログ・ファイルの最大サイズに達すると、logN.xmlというアーカイブ・ログ・ファイルにコピーされます。このNは1から始まる数字です。最後のログ・ファイルが満杯になると、次のようになります。
log.xmlファイルは最新のlogN.xmlファイルに書き込まれます。このNは、最新のログ・ファイルに1を加えた数字になります。
このように、ログ・ファイルは常にロールオーバーするため、ディスク領域を侵害することはありません。
表3-3に示したそれぞれのXMLファイルで、次のように既存のODL構成行を非コメント化するか、XMLファイルにODL構成行を追加することにより、OCLロギングを有効にします。
default-web-site.xmlファイルを除き、表3-3に示したすべてのXMLファイルの<log>要素内で、<odl>要素を追加するか非コメント化します。
default-web-site.xmlファイルに<odl-access-log>要素を追加します。
次の属性を構成できます。
path: この領域のログ・フォルダのパスとフォルダ名。絶対パスか、または構成XMLファイルがある場所（通常は、j2ee/home/configディレクトリ）に対する相対パスを使用できます。これは、XML構成ファイルが関係する機能に対して、そのログ・ファイルが置かれる場所を示します。たとえば、server.xmlファイルのこの要素を変更して、サーバー・ログ・ファイルが書き込まれる場所を示します。
max-file-size: 各ログ・ファイルの最大サイズ（KB単位）。
max-directory-size: ディレクトリの最大サイズ（KB単位）。
ディレクトリの最大サイズに達するまで、ディレクトリ内に新規ファイルが作成されます。各ログ・ファイルは、属性で指定された最大値以下になります。
server.xmlファイルで、ORACLE_HOME/j2ee/log/serverディレクトリ内のログ・ファイルを1000KB、ディレクトリの最大値を10,000KBに指定するには、次のように構成します。
<log> <odl path="../log/server/" max-file-size="1000" max-directory-size="10000" /> </log>
OC4Jの実行中、サーバー宛てのすべてのログ・メッセージはORACLE_HOME/j2ee/log/serverディレクトリに記録されます。
記録されるXMLメッセージの形式は次のようになります。
<MESSAGE> <HEADER> <TSTZ_ORIGINATING>2002-11-12T15:02:07.051-08:00</TSTZ_ORIGINATING> <COMPONENT_ID>oc4j</COMPONENT_ID> <MSG_TYPE TYPE="ERROR"></MSG_TYPE> <MSG_LEVEL>1</MSG_LEVEL> <HOST_ID>myhost</HOST_ID> <HOST_NWADDR>001.11.22.33</HOST_NWADDR> <PROCESS_ID>null-Thread[Orion Launcher,5,main]</PROCESS_ID> <USER_ID>dpda</USER_ID> </HEADER> <PAYLOAD> <MSG_TEXT>java.lang.NullPointerException at com.evermind.server.ApplicationServer.setConfig(ApplicationServer.java:1070) at com.evermind.server.ApplicationServerLauncher.run (ApplicationServerLauncher.java:93) at java.lang.Thread.run(Unknown Source) </MSG_TEXT> </PAYLOAD> </MESSAGE/>
ODLロギングとテキスト・ロギングの両方を有効にできます。ディスク領域を節約するために、これらのオプションのうち1つは無効にしてください。ODLロギングを有効にする場合は、default-web-site.xmlファイルを除き、すべてのXMLファイルの<log>要素の<file>副要素をコメント化して、テキスト・ロギング機能を無効にします。default-web-site.xmlファイルについては、<access-log>要素をコメント化してテキスト・ロギングを無効にします。
ODLログ・ファイルを表示するには次のようにします。
OC4Jでは完全なテキスト・ロギングも使用できます。OC4Jスタンドアロンの場合は、主にテキスト・ロギングを使用してください。XML形式ではないため、エディタで簡単に読み取ることができます。
テキスト・ロギング機能は、XMLファイルにあわせてメッセージを振り分けます。ただし、同一サイズの複数のログ・ファイルに書き込むのではなく、そのコンポーネントのすべてのメッセージを単一のファイルに書き込みます。テキスト・ロギングには制限値やログのロールオーバーはありません。ユーザーがOC4Jを停止し、ファイルを削除し、OC4Jを再起動してログ・ファイルを新しく開始しないかぎり、ログ・ファイルのサイズは増大し続けます。ログ・ファイルを監視しないと、ディスク領域のオーバーランが発生する可能性があります。これはスタンドアロンの開発環境でのみ使用可能です。
テキスト・メッセージングはデフォルトであり、表3-3で示したODLロギングと同じXMLファイルに構成されます。テキスト・メッセージングは、default-web-site.xmlファイルを除き、XMLファイルの<log>要素の<file>副要素により有効になります。default-web-site.xmlファイルについては、<access-log>要素を使用してテキスト・メッセージングを有効にします。テキスト・メッセージングを無効にするには、<file>または<access-log>要素を除去するか、コメント化します。この行を削除しないでODLロギングを有効にすると、両方のロギング機能が有効になります。 表3-4に示すように、テキスト・メッセージングの場所とファイル名にはデフォルトはありませんが、<log>または<access-log>要素のpath属性で場所とファイル名を指定できます。
次の表は、OC4Jプロセスのテキスト・メッセージング・ログ・ファイルのデフォルトの場所のディレクトリを示しています。
前述のログ・ファイルの場所は、web-access.logファイルを除いて、すべて各構成ファイルの<log>要素を使用して指定できます。絶対パス、またはj2ee/home/configディレクトリの相対パスを指定できます。たとえば、server.xml構成ファイルでサーバー・ログ・ファイルを次のように指定します。
<log> <file path="../log/my-server.log" /> </log>
ログ・ファイルの場所は、次のように絶対パスで指定することもできます。
<log> <file path="d:¥log-files¥my-server.log" /> </log>
Oracle Application Server環境では、OC4Jの標準出力および標準エラーはOC4JインスタンスのOPMNログに送られます。たとえば、OC4J_DemosというOC4Jインスタンスに、default_islandというアイランドがあり、このアイランドにプロセスが1つしかない場合、STDOUTおよびSTDERRストリームを含むファイルは、$ORACLE_HOME/opmn/logs/OC4J_Demos.default_island.1となります。
図3-20は、OC4Jコマンドライン・オプションでOC4Jインスタンスに-outおよび-errパラメータを指定する方法を示しています。特定のディレクトリを指定しないでこれらのパラメータを指定すると、ログ・ファイルは$J2EE_HOME/<OC4JInstanceName>_<IslandName>_<Process#>ファイル内に作成されます。たとえば、OC4J_Demosというインスタンスにdefault_islandというアイランドがある場合、ログ・ファイルは$J2EE_HOME/OC4J_Demos_default_island_1内に作成されます。
Application Server Controlで、「管理」ページの「サーバー・プロパティ」を選択すると、図3-20の画面が表示されます。
OC4Jのプロパティは、コマンドラインで設定可能な構成スイッチです。 図3-20に示すように、「Javaオプション」行でプロパティの先頭に-Dが付いています。OC4Jは、OC4Jの各種のサブシステムで実行される操作に関する追加情報を生成するために、いくつかのデバッグ・プロパティを提供しています。OC4Jの起動時に特定のサブシステムに対してこれらのデバッグ・プロパティを設定できます。
OC4JはOPMNにより起動および管理されます。図3-20に示すように、Enterprise Managerを使用して、OC4JインスタンスのJavaシステム・プロパティを指定する必要があります。指定されたプロパティはOPMN構成ファイルに保存されます。ユーザーがOC4Jインスタンスを停止して再起動すると、OPMNは指定されたこれらのプロパティを使用してOC4Jを起動します。 OC4Jの一般プロパティの詳細は、「OC4Jのコマンドライン・オプションおよびシステム・プロパティ」を参照してください。
デフォルトでは、デバッグ情報は$ORACLE_HOME/opmn/logs/ディレクトリ内のOC4JインスタンスのOPMNログ・ファイルに書き込まれます。たとえば、OC4J_DEMOSというOC4Jインスタンスにアイランドが1つしかなく、このアイランドにこのOC4Jインスタンスのプロセスが1つしかない場合、デバッグ情報は$ORACLE_HOME/opmn/logs/OC4J_Demos.default_island.1に記録されます。ただし、OC4Jで-outおよび-errコマンドライン・オプションが指定されている場合、デバッグ情報は該当するファイルにリダイレクトされます。
次の表は、OC4Jで使用可能な便利なデバッグ・オプションを示しています。これらのデバッグ・オプションには、trueまたはfalseという2つの状態があります。デフォルトではfalseに設定されます。 デバッグ・プロパティの全リストは、「OC4Jのコマンドライン・オプションおよびシステム・プロパティ」を参照してください。
| JDBCデバッグ | オプションの説明 |
|---|---|
datasource.verbose |
プールに対して解放されたデータ・ソースと接続を使用したデータ・ソースおよび接続の作成などに関する詳細情報を提供します。 |
jdbc.debug |
JDBCコールの際に非常に詳細な情報を提供します。 |
| EJBデバッグ | オプションの説明 |
|---|---|
ejb.cluster.debug |
EJBクラスタリング・デバッグ・メッセージを有効にします。 |
| RMIデバッグ | オプションの説明 |
|---|---|
rmi.debug |
RMIデバッグ情報を出力します。 |
rmi.verbose |
RMIコールに関する非常に詳細な情報を提供します。 |
| Webサービス・デバッグ | オプションの説明 |
|---|---|
ws.debug |
Webサービスのデバッグを有効にします。 |
特定のサブシステム・スイッチに加えて、指定の詳細レベルでOC4Jを起動できます。 詳細レベルは1〜10の整数で、詳細レベルが高くなるほど、コンソールに表示される情報量は多くなります。詳細レベルは、OC4Jコマンドライン・オプション・セクションでEnterprise Managerの-verbosity OC4Jオプションを使用して指定します。次の例は、詳細情報を含む場合と含まない場合の出力を示しています。
D:¥oc4j903¥j2ee¥home>java -jar oc4j.jar Oracle Application Server Containers for J2EE initialized
D:¥oc4j903¥j2ee¥home>java -jar oc4j.jar -verbosity 10 Application default (default) initialized... Binding EJB work.ejb.WorkHours to work.ejb.WorkHours... Application work (work) initialized... Application serv23 (Servlet 2.3 New Features Demo) initialized... Web-App default:defaultWebApp (0.0.0.0/0.0.0.0:8888) started... Oracle Application Server Containers for J2EE initialized
サーブレットに問題のあるWebアプリケーションをOC4Jにデプロイしました。事前構成したデータ・ソースを使用してデータベース接続を行うと、クライアント・セッションが切断されます。サーブレットがデータ・ソースにアクセスするときにOC4Jで何が行われているかを知る必要があります。HTTPセッションおよびデータ・ソースの使用に関してデバッグ情報を生成するために、- http.session.debugおよびdatasource.verboseという2つのデバッグ・オプションをtrueに設定する必要があります。
次のタスクを実行します。
-Dhttp.session.debug=trueおよび-Ddatasource.verbose=trueのように入力します。
OC4Jインスタンスの再起動後にサーブレットを再実行すると、OC4Jインスタンスの標準出力に次のタイプのデバッグ情報が表示されます。
DataSource logwriter activated... jdbc:oracle:thin:@localhost:1521/DEBU: Started jdbc:oracle:thin:@localhost:1521/DEBU: Started Oracle Application Server Containers for J2EE initialized Created session with id '4fa5eb1b9a564869a426e8544963754f' at Tue APR 23 16:22:56 PDT 2002, secure-only: false Created new physical connection: XA XA Orion Pooled jdbc:oracle:thin:@localhost:1521/DEBU null: Connection XA XA Orion Pooled jdbc:oracle:thin:@localhost:1521/DEBU allocated (Pool size: 0) jdbc:oracle:thin:@localhost:1521/DEBU: Opened connection Created new physical connection: Pooled oracle.jdbc.driver.OracleConnection@5f18 Pooled jdbc:oracle:thin:@localhost:1521/DEBU: Connection Pooled oracle.jdbc.driver.OracleConnection@5f1832 allocated (Pool size: 0) Pooled jdbc:oracle:thin:@localhost:1521/DEBU: Releasing connection Pooled oracle.jdbc.driver.OracleConnection@5f1832 to pool (Pool size: 1) null: Releasing connection XA XA Orion Pooled jdbc:oracle:thin:@localhost:1521/DEBU to pool (Pool size: 1) Orion Pooled jdbc:oracle:thin:@localhost:1521/DEBU: Cache timeout, closing connection (Pool size: 0) com.evermind.sql.OrionCMTDataSource/default/jdbc/OracleDS: Cache timeout, closing connection (Pool size: 0)
JPDA（Java Platform Debugging Architecture）をサポートする任意のJavaデバッグ機能を使用して、OC4Jにデプロイしたアプリケーションをリモートでデバッグできます。OC4JはOracle JDeveloper IDE内に直接埋め込まれているため、ローカルにデプロイした場合も、リモートのJ2EEアプリケーションの場合も簡単にデバッグできます。 詳細は、Oracle JDeveloperのマニュアルを参照するか、OTNで公開されているリモート・デバッグに関するHow Toドキュメントを参照してください。
|
 Copyright © 2002, 2005 Oracle. All Rights Reserved. |
|