| Oracle Application Serverリリース・ノート 10gリリース2（10.1.2）for Linux on POWER E05281-02 |
|
 戻る |
 次へ |
この章では、Oracle Application Server Containers for J2EE（OC4J）に関する問題について説明します。この章の内容は次のとおりです。
10.1.2.0.2では、次のOC4J関連のバグが修正されました。
Bug 4373794 - OC4J 10.1.2 - FATAL ERROR CODE ENHANCEMENT: 修正内容については、このドキュメントの「致命的なエラー・コードの拡張」で説明しています。
Bug 4226465 - MULTIPLE CONNECTION POOLS EXIST FOR SAME DATA SOURCE: コードのBug 4226465とドキュメントのBug 4373802が修正されました。修正内容については、このドキュメントの「修正された接続プールの問題」で説明しています。
この項では、Oracle Application Server Containers for J2EE（OC4J）の構成に関する問題と対処方法について説明します。この項の内容は次のとおりです。
OC4Jには、デフォルトでTomcatサンプルが同梱されています。Tomcatサンプルの多くは、Oracle Secure Coding Standardsに準拠していません。デモ環境とテスト環境で使用する場合以外は、Tomcatサンプルを削除することをお薦めします。
クライアント・ライブラリの互換性の制約により、任意のOracle JDBC-OCIドライバ・バージョンにアップグレードすることはできません。Oracle Application Server 10g（10.1.2）内にインストールされたOracleクライアント・ライブラリに対応するOCIドライバ・バージョンへのアップグレードのみがサポートされています。たとえば、Oracle JDBC 10.1.xドライバはサポートされていますが、Oracle JDBC 9.2.xドライバはサポートされていません。
Oracle Application Server内でJDBC-OCIを使用できる場合は、各OC4Jインスタンスのopmn.xmlエントリが、適切なORACLE_HOMEとライブラリ・パスの値をその起動環境に伝播することも必要になります。
環境変数ORACLE_HOMEはすべてのプラットフォームに共通ですが、ライブラリ・パスを指定する環境変数の名前はオペレーティング・システムによって異なります。
LD_LIBRARY_PATH（SolarisとLinuxの場合）
LIBPATH（AIXの場合）
SHLIB_PATH（HP-UX、HP ItaniumおよびHP Tru64 UNIXの場合）
PATH（Windowsの場合）
ライブラリ・パスをopmn.xmlで指定する一般的な構文は次のとおりです。
<variable_id="LIB_PATH_VARIABLE" value="LIB_PATH_VARIABLE_VALUE"/>
LIB_PATH_VARIABLEは、ライブラリ・パスを指定するプラットフォーム固有の適切な変数名と置き換えてください。また、
LIB_PATH_VARIABLE_VALUE
を、その変数の値と置き換えてください。
次に、Solarisオペレーティング・システムの場合の例を示します。
<process-type id="OC4J_SECURITY" module-id="OC4J">
<environment>
<variable id="ORACLE_HOME"
value="/u01/app/oracle/product/inf10120"/>
<variable
id="LD_LIBRARY_PATH"
value="/u01/app/oracle/product/inf10120/lib"
/>
</environment>
...
デプロイするアプリケーションに対してOC4JのデフォルトのJVMヒープ・サイズが小さすぎる場合、OC4Jプロセスでメモリー不足エラーが発生することがあります。ディレクトリ$ORACLE_HOME/opmn/logsにあるOC4Jインスタンスのログ・ファイルを確認すると、次のようなエラーが含まれる場合があります。
java.lang.OutOfMemoryError
この問題を回避するには、OC4JインスタンスのJavaコマンドライン・オプションを変更し、指定されているヒープ・メモリーを増やします。
Application Server Controlコンソールを使用して、OC4Jインスタンスのホーム・ページを開き、次の手順を実行します。
OC4Jインスタンスを停止します。
「サーバー・プロパティ」ページにドリルダウンします。
「サーバー・プロパティ」ページの「コマンドライン・オプション」で、「複数仮想マシン構成」ヘッダーの下にある「Javaオプション」を設定します。
たとえば、JVMヒープ・サイズを512MBに設定するには、次のように入力します。
-Xmx512m
「適用」ボタンを使用して変更を適用します。
OC4Jインスタンスを起動します。
詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。
OC4J 10.1.2に同梱されていないJDK 1.3を使用するには、JDK 1.3を次の手順に従って変更します。
http://java.sun.com/javase/technologies/security/からJAAS1.0_01をダウンロードし、インストールします。
JAAS1.0_01ディストリビューションから、jaas.jarをjre/lib/extに追加します。
jre/lib/security/java.securityに次の行を追加します。
#These two lines are Oracle-specific definitions # auth.policy.provider=oracle.security.jazn.spi.PolicyProvider @ login.configuration.provider=oracle.security.jazn.spi.LoginConfigProvider
スタンドアロンOC4Jで、最大接続数を構成するには、server.xmlファイルの<application-server>の<max-http-connections>サブ要素を使用します（詳細は、『Oracle Application Server Containers for J2EEユーザーズ・ガイド』を参照）。
<application-server>の<max-ajp-connections>サブ要素を使用して、Oracle HTTP Serverの最大接続数も構成できます。次に例を示します。
<application-server>
...
<max-ajp-connections value="10000" max-connections-queue-timeout="10"
close-idle-connection="allow">
http://optional.redirect.url/page.jsp
</max-ajp-connections>
...
<application-server>
要素の（任意の）値は、「redirect-URL」を示します。その使用方法を次に説明します。
<max-ajp-connections>の属性
value: 最大接続数。デフォルト値は、制限のない場合、-1です（0は予約値）。
max-connections-queue-timeout: 接続数が最大接続数未満に減少するまでの待ち時間（秒単位）。接続が試行されたときに、最大接続数に達しており、タイムアウト値を経過しても利用できる接続がない場合は、他の設定に応じて適切なアクションが実行されます。デフォルト値は0秒です。
close-idle-connection: allow（デフォルト値）を指定すると、最大接続数に達し、queue-timeout値を経過した場合に、最低使用頻度（LRU）の空き接続が切断され、新しい接続を使用できるようになります。LRUの空き接続が切断されないようにするには、denyを指定します。
socket-backlog: ソケット・レベルで接続が拒否されるまで、待機できる接続数。デフォルト値は30です。これは、<max-http-connections>機能から継承された値ですが、他の<max-ajp-connections>属性で設定する以外の用途はありません。つまり、デフォルト以外の値を使用する理由はありません。
接続が試行されたときに、最大接続数に達してタイムアウト値が経過していた場合は、次の3つのレスポンスを指定できます。
close-idle-connection="allow"を指定した場合は、接続リスナーがクライアント・ソケットを切断して（稼動中のスレッドはタスクが完了した後で）、最も古い空き接続を切断します。これにより、接続試行は受け入れられます。
close-idle-connection="deny"を指定し、前述の<max-ajp-connections>要素値でredirect-URLを指定している場合、接続リスナーは、HTTPレスポンス302「Moved Temporarily」によって接続試行を拒否します（クライアント・システムは、ただちに別のURLへの接続を再試行する）。その後、接続試行のクライアント・ソケットは切断されます。
close-idle-connection="deny"を指定し、redirect-URLを指定していない場合は、接続リスナーは接続試行を拒否し、HTTPレスポンス503「Service Unavailable」を送信します。その後、接続試行のクライアント・ソケットは切断されます。
OC4Jへのアプリケーションのデプロイ時に、コンテキスト・ルートに対する「/」の指定がサポートされるようになりました。これには、Application Server Controlおよびadmin_client.jarによるサポートが含まれます。
背景: リリース10.1.3.1の『Oracle Containers for J2EE構成および管理ガイド』に、次のような記載があります。「root設定に「/」を指定すると、OC4JのデフォルトのWebアプリケーションが上書きされます。この設定またはNULL設定は、WebアプリケーションをWebサイトにバインドする場合、admin_client.jarユーティリティで許可されません」。
しかし、現在では、root設定への「/」の指定が許可されています。アプリケーションのデプロイ時には、この設定をコンテキスト・ルートとして使用できます。次の例では、admin_client.jarを使用して、WARファイルをデプロイしてから「/」にバインドしています。
% java -jar admin_client.jar deployer:oc4j:localhost oc4jadmin welcome1 \ -deploy -file d:how-to-rolling-upgrade-web-v1.war -deploymentName h2ru_2 \ -bindAllWebApps -contextRoot "/"
次の例のように、EARファイルにコンテキスト・ルートが「/」に設定されたapplication.xmlファイルが含まれる場合は、Application Server Controlまたはadmin_client.jarを使用してアプリケーションをデプロイする際に、「/」がデフォルトのコンテキスト・ルートとなることに注意してください。
<application>
<display-name>How-To Rolling Upgrade</display-name>
<module>
<web>
<web-uri>how-to-rolling-upgrade-web.war</web-uri>
<context-root>/</context-root>
</web>
</module>
</application>
<max-ajp-connections>の属性
|
注意: 「/」は、Oracle HTTP Serverに対するデフォルトのping URLでもあるため、アプリケーションのデプロイ時にコンテキスト・ルートとして「/」を使用すると、次のような問題が発生する場合があります。
この問題を回避するには、次のディレクティブを、 Oc4jMountCopy off 次のファイルに配置します。
ORACLE_HOME/Apache/Apache/conf/dms.conf
|
デフォルトでは、OC4Jのhttp.file.allowAliasプロパティはfalseに設定されています。この設定によって、シンボリック・リンクが使用できなくなります。この設定をtrueに変更すると、ある状況においてJSPソース・コードがエンド・ユーザーに表示されてしまう可能性があるため、変更しないことを強くお薦めします。
このプロパティ設定を変更するかわりに、次のいずれかの対処方法を使用できます。
OC4JアプリケーションからOracle HTTP Serverへの通信のフロント・エンドであるOC4Jの軽量HTTPリスナーを一時的に使用しないことにより、ブラウザがHTTP経由で直接ページにアクセスするのではなく、MOD_OC4JおよびApache JServ Protocol（AJP）を介して間接的にアクセスするようにします。
アプリケーション内のすべてのシンボリック・リンクを、それらが表す実際のファイル名に置換します。
シェル・スクリプトを使用すると、シンボリック・リンクの置換を自動化できます。次に例を示します。
#!/bin/ksh
PROGNAME="${0##*/}"
LN_EXTN="ln"
function displaySyntax
{
echo "${PROGNAME}! SYNTAX: ${PROGNAME} <some_dir_path>"
exit 1
}
if [[ $# < 0 ]]
then
displaySyntax
fi
DIR="$1"
if [[ ! -d ${DIR} ]]
then
displaySyntax
fi
find ${DIR} -type l|while read filepath
do
echo "FIXING: ${filepath} (=> ${filepath}.${LN_EXTN})"
mv ${filepath} ${filepath}.${LN_EXTN}
cp -L ${filepath}.${LN_EXTN} ${filepath}
done
Linuxでは、このサンプルKSHスクリプトを次のように起動します。
$ fixLinks <web_module_root>
このスクリプトは、すべてのディレクトリを再帰検索し、シンボリック・リンクであるファイルが検出されると、それらの各リンクに.ln拡張子を追加することによって名前を変更します。その後、リンクが検出がされた元の位置にリンク・ターゲットのコピーを配置します。
この項では、Enterprise JavaBeans（EJB）に関する問題について説明します。この項の内容は次のとおりです。
リリース9.0.4.1と10.1.2では、次のorion-ejb-jar.xml属性が非推奨になりました。リリース10.1.3では削除される予定です。
max-instances-per-pk
min-instances-per-pk
disable-wrapper-cache
また、次のlocking-mode属性設定も非推奨になりました。
locking-mode="old_pessimistic"
多数のEJBを含むEARファイルをデプロイすると、OutOfMemory例外が発生します。
デプロイ・プロセスでは、各EJBに対してラッパー・コード・クラスが生成されます。これらのクラスのサイズは、Bean上のビジネス・メソッドの数に比例します。パフォーマンスを最適化するために、OC4Jはすべてのラッパー・コード・クラスを1回のコンパイラ起動でコンパイルします。生成されるラッパー・コードの数が使用可能メモリーに対して多すぎる場合、エラーが発生することがあります。
これを回避するには、デプロイ・プロセスで、各EJBモジュールのラッパー・コードを個別にコンパイルします。これには、次のようにejbdeploy.batchシステム・プロパティをfalseに設定して、OC4Jを起動します。
-Dejbdeploy.batch=false
|
注意: この対処方法は、この例外が発生した場合にのみ使用してください。これにより、アプリケーションのデプロイ時間が長くなる場合があります。 |
zh_CN.GB18030ロケールで実行すると、EJBラッパー・コードのコンパイル・エラーが発生します。zh_CN.GB18030ロケールで実行すると、一部のEJBラッパー・ソース・コードの生成で文字が欠落する場合があります。この結果、コンパイル・エラーが発生します。生成されるソース・コードで文字が欠落するのは、次のサイトに記載されているSun社のバグが原因です。
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4954023
これを回避するには、別のロケールを使用します。詳細は、Sun社のバグの説明を参照してください。
インスタンス・プーリングを無効にするには、orion-ejb-jar.xmlファイルで新しい<max-instances>設定にマイナス値を使用します。これにより、EJBコールの開始時に新しいインスタンスが作成され、コールの終了時にそのインスタンスが解放されます。
非バッチ・モードでコンパイルするには（たとえば、バッチ・モードでのコンパイル時に、OC4Jがjava.lang.OutOfMemory例外をスローする場合）、-Dejbdeploy.batch=falseオプションを使用します。非バッチ・モードでは、メモリーの使用量が少なくて済みますが、デプロイ時間は長くなります。
この項では、OC4Jサービスに関するリリース・ノートについて説明します。OC4Jサービスには、Java Naming and Directory Interface（JNDI）、Java Message Service（JMS）、データソース、Oracle Remote Method Invocation（ORMI）、J2EE Interoperability（IIOP）、Java Transaction API（JTA）、J2EE Connector Architecture（J2CA）およびJava Object Cacheが含まれています。
この項の内容は次のとおりです。
この項では、データソースに関する問題について説明します。この項の内容は次のとおりです。
data-sources.xmlで定義された各データソースに、データソースが通信するバックエンド・データベースがアクセス不可能になったことを示す、致命的なエラー・コードを定義できます。OC4Jがこれらのエラー・コードの1つを検出すると（JDBCドライバによってSQLExceptionがスローされると）、OC4Jはその接続プールを一掃します。つまり、接続プール内のすべての接続が切断されます。Oracleの場合、あらかじめ定義されている致命的なエラー・コードは、3113、3114、1033、1034、1089および1090です。
Oracleの致命的なエラー・コードを追加するには、次の手順を実行します。
<data-source>要素のサブタグである<fatal-error-codes>要素を使用します。<fatal-error-codes>要素では子要素である<error-code>を使用して致命的エラー・コードを1つずつ定義します。各<fatal-error-codes>要素の下に0〜n個の<error-code>要素を定義できます。たとえば、致命的エラー・コード10、20および30の場合、データソース定義は次のように記述できます。
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="ds"
location="jdbc/ds"
xa-location="jdbc/xa/ds"
ejb-location="jdbc/ejb/ds"
@ connection-driver="oracle.jdbc.driver.OracleDriver"
username="scott"
@ password="tiger"
@ url="jdbc:oracle:thin:@//localhost:1521/oracle.regress.rdbms.dev.us.oracle.com">
<fatal-error-codes>
<error-code code='10'/>
<error-code code='20'/>
<error-code code='30'/>
</fatal-error-codes>
</data-source>
10.1.2.0.2では、次の接続プール問題が修正されました。
リリース10.1.2.0.2より前のOC4Jでは、データソース・サブシステムは、次のような場合に、同じデータソースに対して複数の接続プールを作成していました。
同じスレッドの実行時に（たとえば、サーブレットの実行時）、グローバル・トランザクションの内部とグローバル・トランザクションの外部で接続が使用される場合。この場合、グローバル・トランザクション内で使用する接続に1つの接続プールが作成され、グローバル・トランザクションの外部で使用する接続に別の接続プールが作成されていました。
デフォルト以外のユーザーまたはパスワードを使用してデータソースに接続する場合。たとえば、getConnection()を使用すると、1つの接続プールが作成され、getConnection("user", "password")を使用すると別の接続プールが作成されていました。これは、ユーザーまたはパスワードの組合せごとに別の異なる接続プールが作成されるため、適切ではありません。
データソースの接続を共有する構成を行うと、別のデータソースが作成され、前述した接続プール問題のすべてが発生していました。
この問題は、コードのBug 4226465とドキュメントのBug 4373802で修正されています。
コンポーネント依存性が原因で、JDBCシン・ドライバをOracle Application Serverインスタンス・レベルではアップグレードまたは変更できません。JDBCシン・ドライバのアップグレードは、各OC4Jインスタンスに対して実行する必要があります。
OC4JインスタンスのOracle Thin JDBCドライバを更新する手順は次のとおりです。
新しいJDBCライブラリを、OC4Jホスト・コンピュータ上のディレクトリにコピーします。
Oracle Application Serverインスタンスのホストで、iAS_ORACLE_HOME/opmn/conf/opmn.xmlファイルを開きます。
opmn.xmlファイルで、新しいJDBCシン・ドライバにアップグレードされるOC4Jインスタンスの<ias-component>エントリを探します。
新しいJDBCライブラリが配置されたディレクトリへのパスが含まれるように、Javaオプション-Djava.ext.dirsを追加（または変更）します。次に例を示します。
<module-data>
<category id="start-parameters">
<data id="java-options"
value="-Djava.ext.dirs=path/to/the/new/JDBC_dir"/>
</category>
opmn.xmlファイルを保存して閉じます。
コマンドラインを使用して、構成の変更をDCMリポジトリに伝播します。
dcmctl updateconfig -ct opmn
OC4Jインスタンスを停止してから起動します。
opmnctl stopproc process-type=<oc4j_instance_name> opmnctl startproc process-type=<oc4j_instance_name>
この項では、ORMIに関する問題について説明します。この項の内容は次のとおりです。
OC4Jは、IPv4ソケットのみを作成します。デュアル・ネットワーク・スタック・マシン（IPv4とIPv6の両方のスタックが使用可能なマシン）上でも、OC4JはIPv4ソケットのみを作成します。このため、クライアントが発行したリクエストがIPv6システムからである場合、問題が発生することがあります。これは、サーバーからIPv6クライアントへの接続拒否メッセージによって示されます。この問題を回避するには、システム・プロパティjava.net.preferIPv4Stack=trueを使用してクライアント・プロセスを起動します。これにより、クライアントが発行するのはIPv4リクエストのみとなり、サーバーとの通信が可能になります。
ORMIプロトコルはセキュアでないことに注意してください。ORMIを介した通信は、セキュリティ資格証明を含めて暗号化されません。ORMIトラフィックの暗号化が必要な場合は、ORMIをHTTPSで使用することをお薦めします。HTTPSでは、クライアントとサーバー間のすべての通信が暗号化されます。
リリース10.1.2.0.2でOracle Application Server Java Authentication and Authorization Service（JAAS）Provider（OracleAS JAAS Provider）を使用する場合の注意点について説明します。
OracleAS JAAS Provider 10.1.2.0.2では、orion-web.xmlファイルまたはorion-application.xmlファイルで、<jazn-web-app>要素のauth-method="DIGEST"設定をサポートするようになりました。すでにサポートされている設定auth-method="SSO"に加えてサポートされます。DIGESTのサポートは、すでに10.1.2.0.2の『Oracle Application Server Containers for J2EEサーブレット開発者ガイド』（orion-web.xmlの参照ドキュメントは含まれる）に記載されていますが、10.1.2.0.2の『Oracle Application Server Containers for J2EEユーザーズ・ガイド』（orion-application.xmlの参照ドキュメントは含まれる）には記載されていません。「SSO」は、Oracle Application Server Single Sign-OnをHTTPクライアント認証用に使用するためのもので、「DIGEST」はダイジェスト認証メカニズムを使用するためのものです。詳細は、10.1.2.0.2の『Oracle Application Server Containers for J2EEセキュリティ・ガイド』を参照してください。
AJP13プロトコルを使用するサイトでOC4Jが実行されているとき、OC4Jを実行しているマシンのAJPポートにリモートの攻撃者が直接アクセスできる場合には、セキュリティが脆弱になります。AJP13プロトコルがAJPのパラメータremote_userを定義し、そのパラメータは、mod_ossoを実装するためにOHSが使用します。攻撃者は、このパラメータを使用して、OC4Jに対する認証を回避できます。ユーザーが、AJPのパラメータとして有効なremote_user値を挿入したAJPパケットを構築した場合、そのユーザーは、指定されたユーザー（リモート・ユーザー）にアクセス権が付与されたリソースにアクセスできるようになります。
OC4Jを実行するシステムでは、AJPポートを外部に公開しないようにする必要があります。
次のいずれかの方法で、脆弱性から保護することができます。
OC4JとOracle HTTP Server（推奨）の間で、SSLを有効にします。リリース10.1.3.xについては、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。リリース10.1.2または9.0.4については、『Oracle Application Server Containers for J2EEサーブレット開発者ガイド』を参照してください。
global-web-application.xmlまたはorion-web.xmlで<access-mask>要素（<orion-web-app>のサブ要素）を使用して、適切なホスト名、ドメインまたはIPアドレスにアクセス権限を制限します。この要素については、『Oracle Application Server Containers for J2EEサーブレット開発者ガイド』を参照してください。
この項では、Oracle Application Server 10gリリース2（10.1.2）のOC4Jドキュメントの記載内容の誤りについて説明します。この項の内容は次のとおりです。
第6.6.1項「『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の記載内容の誤り」
第6.6.2項「『Oracle Application Server Containers for J2EEスタンドアロン・ユーザーズ・ガイド』の記載内容の誤り」
第6.6.4項「『Oracle Application Server Containers for J2EEサービス・ガイド』の記載内容の誤り」
第6.6.5項「『Oracle Application Server Containers for J2EEセキュリティ・ガイド』」
この項では、『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の記載内容の誤りについて説明します。この項の内容は次のとおりです。
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』のデプロイに関する説明には、アンデプロイおよび再デプロイについての次の注意も必要です。
アンデプロイ/再デプロイに関する一般的な注意:
アプリケーションはOC4Jからアンデプロイされると、クライアントにアクセスできなくなります。Oracle Application Server環境では、Oracle HTTP Serverが再起動され、OC4Jのマウント・ポイントが削除されます。これによって、既存のHTTPセッションが失われます。
再デプロイ時には、新しいEARを再デプロイする前に、OC4Jによって既存のアプリケーション（EAR/WAR）が削除されます。このため、たとえば、以前のアプリケーションに含まれていて、新しいアプリケーションには含まれていないHTMLファイルにアクセスしようとすると、「File Not Found」というエラーになります。
再デプロイされたWARファイルは、以前に展開されたWARの上に重ねて配置され、これによって新しいデプロイメントに古いファイルが保持される場合があるため、古いファイルを削除する必要があります。たとえば、新しいWARには含まれていない以前のデプロイメントの静的HTMLファイルは、展開されたWARディレクトリ構造にも含まれるため、手動で削除する必要があります。
ホット再デプロイに関する注意:
|
注意: ホット・デプロイとは、OC4Jの再起動を伴わないアプリケーションのデプロイのことです。 |
実行中のOC4JインスタンスでEARを再デプロイまたはホット再デプロイすると、以前のアプリケーションからJVMにロードされたクラスのステータスが変更される場合があります。ClassLoaderはファイル・システムのクラスまたはJARファイルが変更されたと認識し、クラスやライブラリを再ロードする場合があります。その他の場合として、新しいクラス定義がロードされるかどうかが、ガベージ・コレクタによる既存のクラス定義の削除をJVMチューニングが許可しているかどうかに依存する場合があります。
セッション・データを含むシリアライズされたオブジェクトに関する問題もあります。セッション・オブジェクトに関連するクラスが変更された場合、そのクラスは、元のクラスへ一般的なセッション・オブジェクトをキャストできない場合があります。これは、クラスが変更されると、その変数では、異なるメモリーを使用する場合があるためです。これによって、セッション・データが失われる場合があります。
Oracle Application Server環境では、ホット・デプロイによって、Oc4jMountディレクティブがmod_oc4j.confに追加され、Oracle HTTP Serverが再起動されます。これによって、既存のHTTPセッションが失われます。
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の表3-3には、OC4Jのデフォルトのログ・ファイル名がweb-access.logであると記述されていますが、これは誤りです。正しいデフォルトのログ・ファイル名はdefault-web-access.logです。
修正されたデフォルトのログ・ファイル名を記述した正しい表は次のようになります。
表6-1 OC4Jで生成されるログ・ファイルのリスト
| デフォルトのログ・ファイル名 | 説明 | スコープ | 構成ファイル |
|---|---|---|---|
application.log |
デプロイ済アプリケーションのすべてのイベント、エラーおよび例外。 |
デプロイ済アプリケーションごとに1つのログ・ファイル |
orion-application.xml |
global-application.log |
アプリケーションに関連するすべての共通イベント、エラーおよび例外。 |
デフォルト・アプリケーションを含めた全アプリケーション |
application.xml |
jms.log |
すべてのJMSイベントおよびエラー。 |
JMSサブシステム |
jms.xml |
rmi.log |
すべてのRMIイベントおよびエラー。 |
RMIサブシステム |
rmi.xml |
server.log |
特定のサブシステムまたはアプリケーションに関連付けられていないすべてのイベント。これは、サーバーの起動、内部サーバー・エラーのシャットダウンの履歴を記録します。 |
サーバー全体 |
server.xml |
default-web-access.log |
Webサイトへの全アクセスを記録します。 |
各Webサイト |
default-web-site.xml |
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の第3章「高度な構成および開発」、「ディレクトリ内での構築およびデプロイ」に次の注意書きを含める必要があります。
|
注意: この項で説明している手動での構築およびデプロイの方法は、スタンドアロンのOC4J環境でのみ使用可能です。エンタープライズ環境では使用できません。 エンタープライズ環境では、Oracle Enterprise Manager 10gを使用してアプリケーションを構築およびデプロイします。 |
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の記述に従って新しいWebモジュールをアクティブなOC4Jインスタンスにデプロイすると、そのサーバー・インスタンス内で実行されているすべてのWebアプリケーションのHTTPセッションが失われます。
クラスタリングされていない環境では、各orion-web.xmlファイル内のルート<orion-web-app>要素でpersistence-path属性を使用することにより、この問題を回避できます。この対処方法はクラスタ環境には適用されません。
ユーザーズ・ガイドには、クラスタ環境でのこの問題の対処方法が『Oracle Application Server高可用性ガイド』に記載されていると記述されていますが、これは誤りです。『Oracle Application Server高可用性ガイド』には、この問題に関連する情報は記載されていません。
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の第4章「OC4Jのクラスタリング」、「Webアプリケーションの状態レプリケーションの設定」には、Webアプリケーションの状態レプリケーションを構成するための6つの手順が記述されています。
この6つの手順に加えて、<cluster-config/>タグがglobal-web-application.xmlファイルに追加されていることを確認します。このタグがglobal-web-application.xmlファイルに追加されていない場合は、orion-web.xmlファイルに追加します。orion-web.xmlファイルは次の場所にあります。
ORACLE_HOME/j2ee/<instance_name>/applications/<app_name>/<app_name>/WEB-INF/orion-web.xml
<cluster-config/>タグは<orion-web-app>タグのサブ要素です。orion-web.xmlファイルと<cluster-config/>タグの詳細は、『Oracle Application Server Containers for J2EEサーブレット開発者ガイド』の第6章「構成ファイルの説明」を参照してください。
このリリース・ノートでは、『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の第3章「高度な構成および開発」の「ライブラリの共有」について詳しく説明します。
ここに示される例では、デフォルトで<library>要素が\j2ee\home\applib\ディレクトリにすでに存在しているように誤って解釈される可能性があります。また、applibディレクトリは、homeインスタンスだけでなく各OC4Jインスタンスにあることにも注意してください。
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の付録B「追加情報」の表B-2「OC4Jのコマンドライン・オプション」に、-userThreadsオプションに関する次の説明を追加してください。
-userThreadsは、ユーザーが作成したスレッドからコンテキスト参照サポートを有効にします。
この項では、『Oracle Application Server Containers for J2EEスタンドアロン・ユーザーズ・ガイド』の記載内容の誤りについて説明します。この項の内容は次のとおりです。
『Oracle Application Server Containers for J2EEスタンドアロン・ユーザーズ・ガイド』の第1章「構成およびデプロイ」、すべての環境でAdmin.JARツールを使用したデプロイに関する項に、次のような誤りがあります。
-bindWebAppの例で、Webサイトの名前がhttp_web_siteになっていますが、これは誤りです。
この場合、Webサイトの正しい名前はhttp-web-siteです。
正しい例は、次のようになります。
java -jar admin.jar ormi://oc4j_host:oc4j_ormi_port admin welcome -bindWebApp FAQApp FAQAppWeb http-web-site /FAQApp
この項では、『Oracle XML APIリファレンス』の記載内容の誤りについて説明します。この項の内容は次のとおりです。
『Oracle XML APIリファレンス』の第15章「C++用のDOM APIパッケージ」に次の情報を追加してください。
表15-7「DOMImplRefメソッドの概要: DOMパッケージ」に、formDocument()メソッドのエントリを追加し、その説明を「ドキュメントへのポインタを与えられると、ドキュメント参照を形成します。」にします。
次のメソッドの説明を追加します。
formDocument()
説明
ドキュメントへのポインタを与えられると、ドキュメント参照を形成します。
構文
DocumentRef< Node>* formDocument( Node* node);
----------------------------------------------------
パラメータ 説明
----------------------------------------------------
node ドキュメント・ノードへのポインタ
----------------------------------------------------
戻り値
ドキュメント参照へのDocumentRef< Node>*ポインタ
この項では、『Oracle Application Server Containers for J2EEサービス・ガイド』の記載内容の誤りについて説明します。この項の内容は次のとおりです。
9.0.4および10.1.2.xの『Oracle Application Server Containers for J2EEサービス・ガイド』の「データソース」にある「DataDirectデータソース・エントリ例」で例のURLが間違っています。
URLの次の部分が誤りです。
url="jdbc:databasevendor://...
正しいURLは、次のようになります。
url="jdbc:oracle:databasevendor://...
DataDirectデータソースのエントリの正しい例は次のとおりです。
SQLServer
SQLServerデータベースのデータソースの構成例は次のとおりです。
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="OracleDS"
location="jdbc/OracleCoreDS"
xa-location="jdbc/xa/OracleXADS"
ejb-location="jdbc/OracleDS"
schema="database-schemas/ms-sql.xml"
connection-driver="com.oracle.ias.jdbc.sqlserver.SQLServerDriver"
username="mssql"
password="mssql"
url="jdbc:oracle:sqlserver://PZWU-PC\WUPZIAS;User=mssql;Password=mssql"
inactivity-timeout="30"
/>
DB2
DB2データベースのデータソースの構成例は次のとおりです。
<data-source
class="com.evermind.sql.DriverManagerDataSource"
connection-driver="com.oracle.ias.jdbc.db2.DB2Driver"
name="OracleDS"
location="jdbc/OracleCoreDS"
xa-location="jdbc/xa/OracleXADS"
ejb-location="jdbc/OracleDS"
schema="database-schemas/db2.xml"
username="db2admin"
password="db2admin"
url="jdbc:oracle:db2://ying.us.oracle.com:50000;DatabaseName=sample;CreateDefa ultPackage=TRUE"
inactivity-timeout="30"
/>
Sybase
Sybaseデータベースのデータソースの構成例は次のとおりです。
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="OracleDS"
location="jdbc/OracleCoreDS"
xa-location="jdbc/xa/OracleXADS"
ejb-location="jdbc/OracleDS"
schema="database-schemas/sybase.xml"
connection-driver="com.oracle.ias.jdbc.sybase.SybaseDriver"
username="JDBC_TEST"
password="JDBC_TEST"
url="jdbc:oracle:sybase://dlsun150:4101"
inactivity-timeout="30"
/>
Informix
Informixデータベースのデータソースの構成例は次のとおりです。
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="OracleDS"
location="jdbc/OracleCoreDS"
xa-location="jdbc/xa/OracleXADS"
ejb-location="jdbc/OracleDS"
schema="database-schemas/informix.xml"
connection-driver="com.oracle.ias.jdbc.informix.InformixDriver"
username="tg4odbc"
password="tg4odbc"
url="jdbc:oracle:informix://dlsun150:3900;informixServer=gtw93;DatabaseName=ga tewaydb"
inactivity-timeout="30"
/>
10.1.2.0.2の『Oracle Application Server Containers for J2EEサービス・ガイド』の「Java Object Cache」、CacheEventListenerの実装に関する項にある例9-14では、中カッコの組合せが不適切で、インデントが誤解を招きやすいように表記されています。
CacheEventListenerを実装する正しい例は、次のようになります。
import oracle.ias.cache.*;
// A CacheEventListener for a cache object
class MyEventListener implements CacheEventListener
{
public void handleEvent(CacheEvent ev) throws CacheException
{
MyObject obj = (MyObject)ev.getSource();
obj.cleanup();
}
}
class MyObject
{
public void cleanup()
{
// do something
}
}
import oracle.ias.cache.*;
// A CacheEventListener for a group object
class MyGroupEventListener implements CacheEventListener
{
public void handleEvent(CacheEvent ev) throws CacheException
{
String groupName = (String)ev.getSource();
notify("group " + groupName + " has been invalidated");
}
void notify(String str)
{
// do something
}
}
10.1.2の『Oracle Application Server Containers for J2EEサービス・ガイド』で、第5章「Oracle Remote Method Invocation」および第6章「J2EEの相互運用性」のクライアント・サイドの要件に関する項に次の項目を追加します。
また、ojdl.jarファイルもクラスパスに追加します。ojdl.jarファイルはOracle Application Serverの一部としてインストールされており、OC4Jクライアント・パッケージには含まれません。ojdl.jarは次のURLからダウンロードできます。
http://www.oracle.com/technology/obe/obe_as_1012/j2ee/lookup/files/ojdl.jar
このトピックに関連するチュートリアルは、次のURLから入手可能です。
http://www.oracle.com/technology/obe/obe_as_1012/j2ee/lookup/lookup.htm#install
この項では、『Oracle Application Server Containers for J2EEセキュリティ・ガイド』に関する問題について説明します。この項の内容は次のとおりです。
『Oracle Application Server Containers for J2EEセキュリティ・ガイド』のデプロイのロールとユーザーに関する項の例で、<member>要素のサブ要素である<type>と<name>が適切に閉じられていません。修正後の例は次のとおりです。
<role>
<name>developer</name>
<members>
<member>
<type>user</type>
<name>john</name>
</member>
</members>
</role>
『Oracle Application Server Containers for J2EEセキュリティ・ガイド』には、internal-settings.xmlファイルでキーストア・パスワードとトラストストア・パスワードに関してパスワードの間接化がサポートされていると誤って記載されています。これは誤りです。internal-settings.xmlファイルでは、パスワードの間接化はサポートされていません。
『Oracle Application Server Containers for J2EEセキュリティ・ガイド』のいくつかの場所で、RMIPermissionおよびAdministrationPermissionのパッケージがoracle.j2ee.serverとして特定されていますが、これは誤りです。
10.1.0.2でのRMIPermissionの正しいパッケージはcom.evermind.server.rmiです。
10.1.0.2でのAdministrationPermissionの正しいパッケージはcom.evermind.serverです。
