| Oracle Application Serverリリース・ノート 10gリリース3（10.1.3.2.0） for Microsoft Windows（64-bit）on Intel Itanium E05150-02 |
|
 戻る |
 次へ |
| Oracle Application Serverリリース・ノート 10gリリース3（10.1.3.2.0） for Microsoft Windows（64-bit）on Intel Itanium E05150-02 |
|
戻る |
次へ |
この章では、10.1.3.2.0のOracle Containers for J2EE（OC4J）のリリース・ノートについて説明します。内容は次のとおりです。
このマニュアルで言及しているオラクル社のマニュアルには、次のURLからアクセスできます。
http://www.oracle.com/technology/index.html
この項では、Oracle Application Server Containers for J2EE（OC4J）の構成、デプロイおよび管理に関する問題について説明します。内容は次のとおりです。
OC4Jの構成については、次のURLにある『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
http://www.oracle.com/technology/index.html
OC4Jには、Tomcatのサンプルがデフォルトで付属しています。Tomcatのサンプルの多くは、Oracleセキュア・コーディング標準に準拠していません。Tomcatのサンプルは、デモや環境テストで使用される場合を除き、削除することをお薦めします。
システム・プロパティKeepWrapperCode、WrapperCodeDirおよびDoNotReGenerateWrapperCodeは非推奨となりました。
これらのオプションは、EJB 2.1 CMPエンティティBeanにのみ適用され、セッションBean、メッセージドリブンBeanまたはEJB 3.0エンティティには適用されません。OC4Jでは、各EJB 2.1 CMPエンティティBeanにつき1ファイルのみ生成されます。EJB 3.0エンティティのみを使用すると、OC4Jではアーチファクトは生成されません。ラッパーにはコンテンツがほとんど含まれないため、デバッグは役に立ちません。
詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』の「生成されたラッパー・コードのデバッグ」を参照してください。
システム・プロパティejb.batch.compileは、非推奨となりました。
バッチ・コンパイルを有効または無効にする場合は、orion-application.xmlファイルの<orion-application>要素のbatch-compile属性を使用してください。
orion-ejb-jar.xmlファイルの次の属性は、サポート対象外となりました。
max-instances-per-pk
min-instances-per-pk
disable-wrapper-cache
instance-cache-timeout
locking-mode="old_pessimistic"
|
注意: このリリースでは、これらの属性を使用しないでください。使用すると、デプロイに失敗します。 |
クライアントがパス情報を使用してアプリケーションにアクセスする場合、OC4Jでは該当するファイルを検索し、関連のファイル情報をキャッシュに格納します。従来は、OC4Jではこのキャッシュからオブジェクトを解放しなかったため、メモリーが失われていました。
システム・プロパティhttp.maxFileInfoCacheEntriesが加わり、キャッシュが次のように制御されるようになりました。
http.maxFileInfoCacheEntries < 0: キャッシュしない。
http.maxFileInfoCacheEntries == 0: 前の動作を変更しない。
http.maxFileInfoCacheEntries > 0: キャッシュ済エントリの最大数を設定する。
デフォルト値は2000です。
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>
|
注意: Oracle HTTP Serverに対するデフォルトのpingのURLも「/」であるので、アプリケーションのデプロイ時にコンテキスト・ルートとして「/」を使用すると、次の問題が発生する可能性があります。
これらの問題は、次のディレクティブを使用することで回避できます。 Oc4jMountCopy off これを次のファイルで使用します。
ORACLE_HOME/Apache/Apache/conf/dms.conf
|
従来は、MANIFEST.MFファイルのSpecification-Version属性およびImplementation-Version属性のバージョン番号は、n1.n2.n3.n4.n5の5要素に制限されていました。（Specification-VersionまたはImplementation-Versionの値に6つ以上の要素がある場合、OC4Jは起動しません。）
このリリースから、8要素までのバージョン番号（n1.n2.n3.n4.n5.n6.n7.n8）が使用できるようになりました。
要素に使用できる最大値は99999999です。
AJPセキュリティは心配だが、ネットワーク上でAJPを実行する必要がなく（OC4JとOracle HTTP Serverが同じシステム上にある場合など）、SSLでAJPを構成することを望まないという場合があります。
次の例のように、default-web-site.xmlでホストとして"127.0.0.1"を指定する場合、AJPリスナーは、ループバック・インタフェースでのみリスニングを行います。この結果、実際にネットワークのハードウェアまたはドライバにアクセスすることなく、TCP/IP機能を使用できます。接続はただlocalhostにループバックします。
<web-site host="127.0.0.1" protocol="ajp13" port="..." ... > ... </web-site>
開発者は、クラスタでのデバッグ時に、クラスタ内でどのJVM、アプリケーション・サーバー・インスタンス（複数インスタンス・クラスタ内）、またはOC4Jインスタンスを実行しているかを確認することが必要になる場合がしばしばあります。これは、デバックの他に、Oracle Application Server上での管理ユーティリティの作成にも便利です。
Oracle Application Server 10.1.3.xでは、開発者がSystem.getProperty()コールによりプログラムでアクセスして、この種の情報を取得できるプロパティがいくつかあります。具体的には次のプロパティです。
oracle.home: Oracle Application Serverがインストールされる物理ディレクトリが含まれる文字列
oracle.oc4j.instancename: OC4Jインスタンスの名前が含まれる文字列
oracle.ons.instancename: Oracle Application Serverインスタンスの名前が含まれる文字列
oracle.ons.indexid: OC4Jインスタンス名、それが属するグループ、それを実行するJVMが次の書式で含まれる文字列
oc4j_instance_name.oc4j_groupname.jvm_number
たとえば、java_ee1.javaee_group.2
OC4J上で実行されているJavaプロセスで、この情報をシステム・コンソールに次のように出力できます。
System.out.println("Oracle home name: " + System.getProperty("oracle.home"));
System.out.println("OC4J Instance name: " +
System.getProperty("oracle.oc4j.instancename"));
System.out.println("AS Instance name: " +
System.getProperty("oracle.ons.instancename"));
System.out.println("Instance:Group:JVM PID: " +
System.getProperty("oracle.ons.indexid"));
『Oracle Containers for J2EEサーブレット開発者ガイド』には、デフォルトでは、クラス名によるサーブレットの起動は無効になったが、プロパティを-Dhttp.webdir.enable=trueと設定することにより有効にできると記述されています。（クラス名によるサーブレットの起動は、10.1.2.x以前のリリースではデフォルトで有効でした。）
同様に、対応する<servlet-mapping>エントリがない場合、<servlet-name>値によるサーブレットの起動にもこれが当てはまります（ただし、マニュアルには記述されていません）。このようにサーブレット名を使用したサーブレットの起動は、10.1.2.x以前のリリースではデフォルトで有効になっていましたが、リリース10.1.3.xでは-Dhttp.webdir.enable=trueの設定が必要です。
たとえば、次のweb.xmlエントリに、対応する<servlet-mapping>エントリがない場合を考えてみます。
<servlet>
<servlet-name>TestIt</servlet-name>
<servlet-class>mypackage.TestIt</servlet-class>
</servlet>
10.1.2.xでは、/servlet/TestItを使用すれば、プロパティの設定なしでこのサーブレットにアクセスできました。10.1.3.xでは、特定の構成でこのようにサーブレットにアクセスするには、-Dhttp.webdir.enable=trueを設定する必要があります。
このリリース・ノートでは、次の例のように、同時タイマーの数が最大値を超えた場合に発生する警告の背景情報および回避方法を提供しています。
WARNING J2EE OJR-10002 The number of concurrent Timers has reached the maximum limit
10.1.3.1および10.1.3.2ではデフォルトで、OC4Jは8つの同時タイマーしか使用できません。（タイマーは、EJBタイマー、タイマー・サービスまたはスケジューラによって起動されます。）この制限は、各タイマーが短期のものであることを予想しているため、デフォルトでは低い数値になっています。タイマーの数が制限値であるとき、タイマーがなんらかの理由で長く稼働していて、もう実行されないような場合、新しいタイマーが発生すると、警告メッセージが表示されます。この状況で使用できる2つのOC4Jフラグがあります。
timer.service.debug: 現在稼働中のタイマー数に関する情報など、タイマー・サービスの追加の診断情報を出力するかどうかを決定します。たとえば、-Dtimer.service.debug=trueのように使用します。
executor.concurrent.tasks: エグゼキュータ・サービスの同時タスクの数を指定します。このフラグにより、OC4Jで使用可能な同時タイマーの最大数を増やすことができます。たとえば、-Dexecutor.concurrent.tasks=12のように指定します。
|
注意: 各タイマーは、個別のスレッドで実行されます。最大数を高く設定しすぎると、多数のタイマーが実行され、多くのスレッドが使用されることになります。スレッドは、実行が終了したら、再利用することをお薦めします。 |
OC4Jは、デフォルトでhttp.file.allowAliasプロパティがfalseに設定されて出荷されるようになりました。この設定により、シンボリック・リンクは使用できません。この設定をtrueには変更しないでください。変更すると、場合によっては、エンドユーザーにJSPソース・コードが見えてしまうことがあります。
プロパティの設定を変更するかわりに、次の回避方法のいずれかを使用できます。
一時的に、OC4J軽量HTTPリスナーの使用を、Oracle HTTP Serverを介したOC4Jアプリケーションのフロントエンド処理に切り替えます。その結果、ブラウザは、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
この例のKSHスクリプトは、UNIXで次のように起動されます。
$ fixLinks <web_module_root>
このスクリプトは、任意のディレクトリを再帰検索し、シンボリック・リンクであるファイルを見つけると、各リンクの名前を.ln拡張子を追加して変更し、そのリンクが見つかった元の場所にリンク・ターゲットのコピーを置きます。
ヘッドレス・コンソールの場合、Oracle Application Server 10.1.3.1またはそれ以降の10.1.3.xリリースでJDK 1.4.2を使用してOC4Jを起動するには、-Djava.awt.headless=trueパラメータが必要です。
10.1.3.xリリース用のデフォルトのJDKであるJDK 1.5を使用している場合は、ヘッドレス・コンソールからOC4Jアプリケーションを起動するのにこのオプションは必要ありません。
次に示すのは、-Djava.awt.headless=trueを追加したOC4Jコンポーネントのopmn.xmlセクションの例です。
<ias-component id="default_group"> <process-type id="home" module-id="OC4J" status="enabled"> <module-data> <category id="start-parameters"> <data id="java-options" value="-server -Dcom.sun.management.jmxremote -Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false"/> </category> <category id="stop-parameters"> <data id="java-options" value="-Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false"/> </category> </module-data>
『Oracle Containers for J2EE構成および管理ガイド』では、第4章「OC4Jランタイムの構成」の「一般的なシステム・プロパティの概要」で、java.awt.headlessシステム・プロパティについて説明しています。
sequentialオプションを使用して、アプリケーションをグループにデプロイする際、デプロイ操作は順次実行され、デプロイが一度に1つのOC4Jインスタンスに対して行われるため、ターゲット・アプリケーションが完全に停止状態になることは絶対にありません。順次デプロイでは、現行インスタンスでのデプロイ操作が完了すると同時に、デプロイメント・マネージャによって、次のインスタンスでのデプロイがただちに開始されます。その結果、システムには安定する間がなく、次のデプロイが開始される前に新しいアプリケーションが完全にアクティブになり、次のような副作用が起こる可能性があります。
アプリケーションは、あるインスタンス上で停止していて、別のインスタンスでそのアプリケーションが使用可能であることをmod_oc4jがまだ通知されていない場合、アクセスできなくなる可能性があります。
セッション・レプリケーションのアクティビティは、実行する機会がなかった可能性があります。
場合によっては、admin_client.jarコマンドまたはredeploy Antタスクを使用して、クラスタにアプリケーションを再デプロイすると、sequentialオプションおよびkeepsettingsオプションを指定しても、アプリケーションのセッションの状態が失われることがあります。
Oracle Containers for J2EEリリース10.1.3.2または10.1.3.1では、admin_client.jar -sequential waitsecサブスイッチのwaitsecパラメータ、またはredeploy AntタスクのsequentialDelayプロパティのいずれかを使用すれば、1つのクラスタ内の異なるOC4Jインスタンスに対する再デプロイの間隔の秒数を指定できます。この遅延により、セッション状態のレプリケーションに十分な時間ができます。
オプションのwaitsecまたはsequentialDelay値の導入により、デプロイメント・マネージャは、1グループ内のOC4Jインスタンスでのデプロイ操作間に指定した期間、待機するようになります。この遅延により、グループ再デプロイ操作を実行する管理者の能力が向上し、グループ内で再デプロイ操作が実行されている間にシステムを安定化でき、アプリケーションにアクセスできなかったり、セッション状態が失われたりすることが少なくなります。
クラスタへの再デプロイのadmin_client.jarコマンドの新しい構文は次のとおりです。
java -jar admin_client.jar uri adminId adminPassword -redeploy -file path/filename -deploymentName appName [-keepSettings] [-sequential [waitsec -removeArchive
たとえば、次のadmin_client.jarコマンドは、異なるOC4Jインスタンスへの再デプロイの間に、15秒の待機時間を指定しています。
java -jar admin_client.jar deployer:cluster:opmn://host:port/home oc4jadmin password -redeploy -file "myapp.ear" -deploymentName rolling -sequential 15 -keepsettings
新しいwaitsecパラメータは、admin_client.jar deployコマンドの-sequentialサブスイッチにも適用されます。
新しいsequentialDelayプロパティを持つredeploy Antタスクは次のとおりです。
<oracle:redeploy
deployerUri="${deployer.uri}"
userid="${oc4j.admin.user}"
password="${oc4j.admin.password}"
file="${lib.dir}/${app.name}.archiveType"
deploymentName="${app.name}"
keepsettings="true"
sequential="true"
sequentialDelay="15"
logfile="${log.dir}/deploy-ear.log"/>
新しいsequentialDelayオプションは、deploy Antタスクにも適用されます。
admin_client.jarコマンドや、redeployまたはdeploy Antタスクの詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
スケジュール済ジョブのあるアプリケーションを再デプロイする場合、スケジュール済ジョブはアプリケーションの再デプロイ後に実行されません。
スケジュール済ジョブのあるアプリケーションを再デプロイする場合は、次の手順に従います。
すべてのスケジュール済ジョブを削除します。
アプリケーションを再デプロイします。
すべてのジョブを再発行します。
Oracle Application Server 10.1.3.xリリースに含まれるOracle Notification Service（ONS）は、Oracle Database 10.1.0.xリリースに含まれるバージョンのONSとは互換性がありません。2つのバージョンを接続すると、次のエラーを受け取ります。
invalid connect server IP format ... Terminating connection ...
非互換性により高速接続フェイルオーバーなどのRAC機能が失敗します。これを回避するには、10.1.0.6パッチ・セットをOracle Database Serverにインストールします。パッチ・セットには更新されたONSが含まれています。パッチはhttps://metalink.oracle.comからダウンロードできます。
OC4J管理クライアント・ユーティリティを使用して、OC4J外部のAnt 1.6.5を使用するAntタスクを組み込むことが可能です。管理クライアント・ユーティリティを使用せずにOC4J外部のAntタスクを組み込む方法は、『Oracle Containers for J2EEデプロイメント・ガイド』の第10章「デプロイに対するOC4J Antタスクの使用方法」に記載されています。Oracle Technology Networkの次の場所を参照してください。
http://download.oracle.com/docs/cd/B31017_01/web.1013/b28951/anttasks.htm#CHDGHFIE
管理クライアント・ユーティリティでは、構成およびデプロイ用にOC4J Antタスクを使用できます。
OC4J管理クライアント・ユーティリティによりOC4J外部のAnt 1.6.5を使用するAntタスクを組み込む手順:
Oracle Technology Networkの次の場所からoc4j_admin_client_ release_number.zipファイルをダウンロードします。
http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html
管理クライアント・ユーティリティとその使用方法の詳細は、『Oracle Containers for J2EE構成および管理ガイド』の第6章「admin_client.jarユーティリティの使用方法」の「リモート管理クライアントのダウンロードおよび抽出」に記載されています。Oracle Technology Networkの次の場所を参照してください。
http://download.oracle.com/docs/cd/B31017_01/web.1013/b28950/adminclient.htm#CHDBEBHD
oc4j_admin_client_ release_number.zipの内容を、oc4j_admin_clientなどの任意のローカル・ディレクトリに抽出します。
ORACLE_HOME/ant/lib/ant-oracle.jarファイルをOracle Application Server 10gリリース3（10.1.3.2）のホーム・ディレクトリから（oc4j_admin_client_ release_numberの内容を抽出したローカル・ディレクトリ内の）OC4J_ADMIN_CLIENT_DIR\ant\libにコピーします。
ORACLE_HOME環境変数をOC4J_ADMIN_CLIENT_DIRディレクトリに設定します。
ANT_HOME/ant/binをシステムのPATH環境変数に追加します。
ANT_HOME環境変数をAntインストール環境を指すように設定し、JAVA_HOME環境変数をJava 2 Standard Edition SDKの場所を指すように設定します。
一般的なANTインストール・ディレクトリは、ORACLE_HOME/antです。
Antビルド・ファイル（build.xml）の<project>要素でoracleネームスペースを宣言します。
<project name="test" default="all" basedir="." xmlns:oracle="antlib:oracle">
build.xmlでのOC4J Antタスクの参照では、このネームスペースが使用されます。
ant-oracle.propertiesファイルをORACLE_HOME/j2ee/utilitiesディレクトリからビルド・ファイル（build.xml）を含むディレクトリにコピーします。
ORACLE_HOME/j2ee/utilitiesのファイルを変更してビルド・スクリプトから参照することも可能ですが、元のファイルはテンプレートとして維持することをお薦めします。
Antタスクに渡す引数の値をant-oracle.propertiesファイルに設定します。
ファイル内のプロパティは、OC4Jのデフォルト値に設定されています。このファイルには、ORACLE_HOMEやJAVA_HOMEなどの環境変数設定も含まれます。これらの各プロパティは、1つ以上のターゲットOC4Jインスタンスの構成を反映するように、必要に応じて編集できます。
ant-oracle.xmlファイルをORACLE_HOME/j2ee/utilitiesディレクトリからビルド・ファイル（build.xml）を含むディレクトリにコピーします。
ビルド・ファイルの最上位レベルに、次の<import>要素を追加します。
<import file="ant-oracle.xml"/>
X.509証明書認証（X509Certificate）の場合、JAZNにより、Oracle Internet Directory（OID）プロバイダのマッピング属性がデフォルトで"DN"に設定されます。
デフォルト値を変更するには、mapping.attributeプロパティの値を次のように構成します。
$Oracle_Home/j2ee/<oc4j_inst>/config/jazn.xmlファイルの場所を特定します。
<jazn>タグにmapping.attributeプロパティ構成を追加します。次に例を示します。
<jazn provider... > ... <property name = "mapping.attribute" value="cn"/> ... </jazn>
OC4Jインスタンスを再起動します。
同様に、次のような他のログイン・モジュールも、現在はjazn.xmlファイルのmapping.attributeプロパティに依存しています。
パスワードなしのWS-Securityユーザー名トークン（WSSLoginModule）
SAML（SAMLLoginModule）
SAMLLoginModuleは、マッピングを特定するために最初はSubjectNameIdentifierを参照します。値が空白の場合、mapping.attributeが使用されます。
X.509クライアント証明書認証（X509LoginModule）
サード・パーティのログイン・モジュール（LDAPLoginModule）
これらのログイン・モジュールのマッピング属性は、前述のとおりjazn.xmlファイルに設定する必要があります。
OC4Jインスタンスを作成すると、インスタンス構成を含む新規<process-type>要素がopmn.xml構成ファイルに追加されます。OC4J homeインスタンスの<process-type>要素は、新規インスタンスのテンプレートとして機能し、新規インスタンスはhomeインスタンスと同じ設定で作成されます。新規インスタンスの構成を変更するには、opmn.xmlファイルでインスタンス用の<process-type>要素のheapsize、numprocs、timeoutなどの設定を変更します。OC4Jインスタンスの構成を変更したら、OC4Jインスタンスを再起動してその変更を適用する必要があります。
状態レプリケーションを使用するアプリケーションを管理対象のOracle Application Serverにデプロイすると、クラスタ全体に状態を伝播するためのポートがOPMNによって動的に割り当てられます。この割当てを、peer-to-peerレプリケーションが有効化されているアプリケーションのポート範囲に制限できます。状態レプリケーションのためのポートの指定は、明確に定義されたポート範囲を使用するファイアウォールまたはネットワークが含まれるインストール環境で必要になることがあります。
peer-to-peer状態レプリケーションのためのポート範囲を指定する手順
opmn.xmlファイルのOC4Jインスタンス構成に<port>要素を追加します。
peer-to-peerレプリケーションが有効化されているアプリケーションの名前を<port>要素のid属性の値として指定します。
<port>要素のrange属性にポート範囲を指定します。
たとえば、peer-to-peerレプリケーションが設定されているrac-webというアプリケーションのデプロイに対しては、次のOC4Jインスタンス構成内の<port id=rac-web .../>という行によって、状態レプリケーション用にポート15213〜15214を使用するようOPMNに指示します。
<port id="default-web-site" range="80-100" protocol="http"/> <port id="rmi" range="12401-12500"/> <port id="rmis" range="12701-12800"/> <port id="jms" range="12601-12700"/> <port id="rac-web" range="15213-15214"/>
状態レプリケーションの詳細は、『Oracle Containers for J2EE構成および管理ガイド』の第9章「OC4Jでのアプリケーションのクラスタリング」を参照してください。
Oracle Application Serverクラスタ内のグループのOC4Jインスタンスはすべて、10.1.3.1.0のように同じバージョンである必要があります。OC4Jインスタンスのグループの詳細は、『Oracle Containers for J2EE構成および管理ガイド』の第8章「クラスタおよびOC4Jグループの構成と管理」を参照してください。
oc4j.propertiesファイルを使用すると、デフォルトの出力先ではなく特定のデバッグの出力先にトレース・ファイルを生成するようにOC4Jインスタンスを構成できます。2つの異なるOC4Jインスタンスが同じグループ内にある場合でも、同じ出力先にトレース出力を生成するようにインスタンスを構成することはサポートされません。各OC4Jインスタンスは、各自のトレース・ファイルを管理します。
トレース出力に関するコンポーネントのログ出力のデフォルトの場所については、『Oracle Containers for J2EE構成および管理ガイド』の第11章「OC4Jでのロギング」を参照してください。
この項では、サーブレットに関するリリース・ノートについて説明します。内容は次のとおりです。
10.1.3.xの実装では、クラス名によるサーブレットの起動は、デフォルトでは有効になっていません。したがって、デフォルト・モードでは、web.xmlで標準のサーブレット構成を使用してからでないと、サーブレットを起動できません。次に例を示します。
<servlet>
<servlet-name>mytest</servlet-name>
<servlet-class>mypackage.MyTestClass</servlet-class>
</servlet>
...
<servlet-mapping>
<servlet-name>mytest</servlet-name>
<url-pattern>/servlet/mytest</url-pattern>
</servlet-mapping>
この構成を使用しないと、サーブレットを起動しようとしても、404 NOT FOUNDエラーが発生して起動に失敗します。これは、クラス名による起動が有効だった以前のリリースのデフォルト動作と異なります。
かわりに、OC4J起動時に、http.webdir.enableプロパティを次のように設定し、クラス名による起動を有効にすることができます。
-Dhttp.webdir.enable=true
10.1.3.1.0より前のリリースでは、*-web-site.xmlファイルの<web-app>要素のaccess-log属性のデフォルト値はtrueでした。10.1.3.1.0以降では、access-logのデフォルト値はfalseです。
アクセス・ロギングを有効にする場合は、該当する<web-app>要素でaccess-logをtrueに設定します。
10.1.2.xでは、SSLが有効で、セッションCookie（名前がJSESSIONIDであるCookie）がブラウザからのリクエストに存在する場合、SSLストリームに埋め込まれているセッションIDよりも、Cookieからの値がOC4Jで優先されました。10.1.3.xではこの動作が逆になり、OC4Jでは、まずSSLストリームからの値が優先されるようになりました。
以前のリリースのOC4Jでは、Webアプリケーションでエラーが発生した場合のデフォルトの動作で、クライアントに返されるHTMLエラー・ページに例外とスタック・トレースの両方が表示されていました。
このデフォルト動作は変更され、これらの詳細はデフォルトで表示されなくなりました。かわりに、汎用エラー・メッセージがHTMLエラー・ページに表示されます。例外とスタック・トレースの詳細は、関連アプリケーションのログ・ファイルに送信されます。
以前の動作に戻すには、<orion-web-app>要素のdevelopment属性の値を、次の例に示すように、Webアプリケーションのorion-web.xmlファイルでtrueに設定します。
<orion-web-app
jsp-cache-directory="./persistence"
jsp-cache-tlds="standard"
temporary-directory="./temp"
context-root="/myapp"
development="true">
...
</orion-web-app>
development属性の詳細は、『Oracle Containers for J2EEサーブレット開発者ガイド』の「Webモジュールの構成ファイル」を参照してください。
global-web-application.xmlファイルでは、特定のサーブレットを変更する場合、そのサーブレットをリロードしないようにOC4Jに強要できます。この機能を有効にするには、<servlet>要素のauto-reload属性（ドキュメントには記載されていません）をfalseに設定します。
auto-reload="false">.
このパラメータは、OC4J 10.1.3.xサーブレットのドキュメントには記載されていません。
次に、単一のサーブレットに関するこの実行例を示します。
global-web-application.xml:
...
<servlet auto-reload="false">
<servlet-name>nlservlet</servlet-name>
<servlet-class>com.netledger.core.requesthandler.NLServlet
</servlet-class>
</servlet>
この項では、JavaServer Pagesに関するリリース・ノートについて説明します。内容は次のとおりです。
JSPデモの実行中に、デモの.jspまたは.javaファイルを表示しようとして、「リソースが見つかりません」という例外が表示された場合は、次の回避方法を使用してください。
j2ee/ojspdemos/applications/ojspdemos/ojspdemos-web/WEB-INF/web.xmlにあるweb.xmlファイルに次の行を追加します。
<servlet-mapping>
<servlet-name>viewsrc</servlet-name>
<url-pattern>/servlet/ViewSrc/*</url-pattern>
</servlet-mapping>
次に、OC4Jサーバーを再起動します。
次に示すglobal-web-application.xmlファイルおよびorion-web.xmlファイルの<init-param>要素のJSP構成パラメータは、リリース10.1.3.1.0で非推奨となりました。
external_resource
extra_imports
forgive_dup_dir_attr
old_include_from_top
setproperty_onerr_continue
jsp-print-null
さらに将来のリリースでは、次に示すglobal-web-application.xmlファイルおよびorion-web.xmlファイルの<init-param>要素のJSP構成パラメータは、削除される予定です。これらのパラメータは、その動作をリリース10.1.3.1.0で実装する唯一の方法です。動作を実装した場合、これらのパラメータが削除されたリリースにアップグレードすると、コードの変更が必要になります。
xml_validate
no_tld_xml_validate
Oracle固有のojspタグ・ライブラリは、OC4Jリリース10.1.3.xで非推奨となりました。これらのライブラリは、OC4Jリリース11gではサポート対象外となります。
本番環境の効率を高めるには、ojspcを使用して事前にコンパイルされるsample-web.warで、<web-app>要素のすぐ後のsample-web.war\WEB-INF\web.xmlに次の宣言を含める必要があります。
<servlet>
<servlet-name>jsp</servlet-name>
<servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class>
<init-param>
<param-name>main_mode</param-name>
<param-value>justrun</param-value>
</init-param>
</servlet>
justrunなどのmain_modeパラメータの設定については、『Oracle Containers for J2EE JavaServer Pages開発者ガイド』の第3章「OC4JのJSP環境の構成」で説明しています。
この項では、EJBに関するリリース・ノートについて説明します。内容は次のとおりです。
リリース10.1.3.2.0のOC4Jでは、EJB 3.0の最新仕様に指定されている機能のごく一部を除くすべての機能がサポートされています。
OC4Jを10.1.3.1にアップグレードする際、ご使用のEJB 3.0 OC4Jアプリケーションのコード変更が必要になる場合があります。
10.1.3.0 JPAプレビュー・アプリケーションを10.1.3.1 JPAに移行する方法の詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』の10.1.3.0のTopLink JPAプレビュー永続性からの移行に関する項を参照してください。
ほとんどのEJB 3.0セッションBean機能およびメッセージドリブンBean機能は、JDK 1.4のデプロイメント・ディスクリプタでサポートされています。ただし、JDK 1.4でEJB 3.0インターセプタは使用できません。これは、InvocationContextメソッドgetContextData()でJDK 1.5汎用型が返されるためです。
EJB 3.0仕様には、「永続性コンテキストの伝播はローカル環境内にのみ適用されます。永続性コンテキストはリモート層に伝播されません」という内容が記載されています。
クラスタ化されたOC4J環境では、これは、拡張永続性コンテキストを使用したリモート・インタフェース搭載のEJB 3.0ステートフル・セッションBeanが、フェイルオーバーしないことを意味します。
この制限を回避するには、拡張永続性コンテキストで管理されるエンティティに対するすべての参照を、ejbPassivateコールバックを使用してNULLにした後、ejbActivateコールバックで再確立するように、ステートフル・セッションBeanを構成します。
Orion永続性マネージャは非推奨となりました。新規の開発には、OC4JとTopLink永続性マネージャを使用してください。TopLink移行ツールを使用すると、EJB 2.0エンティティBeanとOrion永続性マネージャを使用する既存のOC4Jアプリケーションを、EJB 2.0エンティティBeanとTopLink永続性マネージャを使用するアプリケーションに移行できます。
詳細は、『Oracle TopLink開発者ガイド』の「OC4J TopLinkの永続性へのOC4J Orionの永続性の移行」を参照してください。
このリリースでは、ejb-module属性remoteは、orion-ejb-jar.xmlおよびorion-web.xmlで非推奨となりました。
クラスタ化されていない独立したWeb層とEJB層でリモートのEJBにアクセスするには、ejb-ref-mappingの属性remote-server-refおよびjndi-properites-fileを使用します。
詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』の「リモートEJBへの環境参照の構成: クラスタ化されていない個別のWeb層およびEJB層」を参照してください。
JDK 1.5（およびそれ以降）での不具合のために、RedHat 4（Linux 2.6）ではソケットをIPv6アドレスにバインドできません。
この問題を回避するため、OC4JではデフォルトのIPアドレス・スタックとしてIPv4を使用します。
このデフォルトを無効にするには、システム・プロパティをjava.net.preferIPv4Stack=falseに設定します。
data-sources.xmlでOC4Jのマネージド・データソースを構成する際、Oracle JMS Connector（OJMS）でマネージド・データソースを使用する予定の場合、属性manage-local-transactionsをfalseに設定する必要があります。これは、キューとトピック・ケースの両方に当てはまります。
グローバル・トランザクションで接続を行うかどうかを判断するために、マネージド・データソースで使用されるデフォルトのアルゴリズムは、OJMS使用時には不適切であり、グローバル・トランザクションにMDBが加わることを誤って阻止する可能性があります。
この属性がfalseに設定されている場合、OJMSと基礎となるデータベース管理システムでは、接続の実際のトランザクション・ステータスを正しく判断できます。
この項では、Webサービスに関するリリース・ノートについて説明します。内容は次のとおりです。
|
注意: WebServicesAssemblerまたはJDeveloperで作成されたクライアントでWebサービスを実行することにより、Webサービスを検証し、エラーを特定できます。クライアントの作成の詳細は、『Oracle Application Server Web Services開発者ガイド』およびJDeveloperオンライン・ヘルプを参照してください。 |
この項では、間違った構成の結果生じる可能性がある問題について説明します。
WSILアプリケーション・コンポーネントのインストールに使用するAntスクリプトは、特定の外部構成オプションの影響を受けます。Antが正しく構成されていない場合、WSILのインストールがNoClassDefFoundエラーで失敗する可能性があります。
Antを使用したWSILアプリケーションのデプロイ時に、OracleAS Web Services 10gで提供されているAntディストリビューションを使用しているか確認する必要があります。このリリースには、デプロイに必要なすべてのAntタスクが含まれています。
OracleAS Web Services 10gで提供されているAntディストリビューションの内容および機能の詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
この項では、WebServicesAssemblerの操作で発生する可能性のある問題について説明します。
WebServicesAssemblerでは、topDownAssembleコマンドに対して複数のサービス要素を使用できません。
WebServicesAssemblerでは、WSDLファイルまたはXSDファイルで使用される、次のような相対パス名はサポートされません。
<import location="../../file" ...>
回避方法として、WebServicesAssembler fetchWsdlコマンドまたはfetchWsdlImports引数を使用します。fetchWsdlコマンドはトップ・ダウンWebサービス・アセンブリで使用され、ベース（またはトップ・レベル）WSDLファイルと、インポートされて含められたWSDLおよびスキーマのすべてを、指定の出力ディレクトリにコピーします。ブール型のfetchWsdlImports引数は、WSDLおよびWSDLがインポートするすべてのものについて、ローカル・コピーを作成するかどうかを示します。
schemaLocation属性は、1つ以上のネームスペースについて、スキーマの検索場所に関するヒントをスキーマ・プロセッサに提供します。値はURIのリストとして提供され、空白文字で区切られます。URIは、ネームスペースURIと、それに続くそのネームスペースのスキーマ・ドキュメントの場所とのペアで表される必要があります。
WebServicesAssemblerでスキーマが正常に処理されるには、スキーマ・インポートがschemaLocation属性で修飾されていることが必要です。
次の例では、WS-I基本プロファイルのスキーマの場所を指定しています。
<xsd:import namespace="http://ws-i.org/profiles/basic/1.1/xsd" schemaLocation="http://ws-i.org/profiles/basic/1.1/xsd"/>
J2SE注釈を含むJavaファイルからWebサービスを生成するためにassemble Antタスクを使用すると、例外が発生します。assemble Antタスクでは、注釈付きのJavaファイルを正しく処理できません。
この例外を回避するには、コマンドラインでassembleを使用します。
この項では、OracleAS Web ServicesによるWSDLファイルの解釈方法で発生する可能性のある問題について説明します。
WSDL内の名前（サービス名、ポート・タイプ名、操作名、バインディング名またはポート名など）にグローバリゼーション・サポート（NSLまたは各国語サポートとも呼ばれる）文字が含まれていても、サポートされません。これを使用すると、Webサービスのテスト・ページでエラーが発生することもあります。
RPCエンコードやドキュメントリテラルなどの複数のメッセージ書式を、1つのWebアプリケーションで使用することはできません。
この問題を回避するには、Webアプリケーションでメッセージ書式が1つしか定義されていないことを確認します。
WebServicesAssemblerのgenWsdlコマンドまたはAntタスクを使用する場合、生成されたWSDLファイルの変数は、元のJavaクラス・ファイルの順序とは異なる順序になります。WSDLファイルの生成後にJavaコードを続けて変更する場合、この異なる順序によって問題が生じる可能性があります。たとえば、クライアントがサーバーのWebサービスにアクセスできなくなることがあります。
この問題を回避するには、次の手順を実行します。
genWSDLを使用してWSDLファイルを生成します。
生成されたWSDLファイルを編集して、変数を必要な順序に並べます。
Webサービスをボトムアップで集めている場合、EAR/WARファイルの元のWSDLファイルを、編集したWSDLファイルで置き換えます。
この項では、Webサービスのスキーマ機能の制限について説明します。内容は次のとおりです。
スキーマにRPCエンコード・メッセージ書式を持つバインディングが含まれている場合に、WebServicesAssemblerで属性を持つcomplexTypeが検出されると、「サポートされていない型が検出されました」というエラー・メッセージが表示されます。
Webサービス・トップダウンまたはWebサービス・プロキシをアセンブルする場合、WebServicesAssemblerでは、XML型xsd:choiceまたはxsd:groupを含むWSDLを消費できません。これらのXML型を含むWSDLを消費する必要がある場合は、WebServicesAssemblerのdataBinding引数をfalseに設定し、ペイロードがWSDLファイルのスキーマ定義に適合するようにSOAPElementをコーディングします。
この項では、Webサービスのテスト・ページに関する問題について説明します。内容は次のとおりです。
9.5.5.2項「Webサービスのテスト・ページでのサービス起動により返された書式設定済XMLコンテンツが正しく表示されない」
9.5.5.4項「Webサービスのテスト・ページ・フォーム・フィールドの無効な値が原因で「saveChangesでヘッダー・ストリームを取得できません」エラーが発生する」
9.5.5.5項「Webサービスのテスト・ページで、ユーザー名またはパスワードのグローバリゼーション・サポート（NLS）文字がサポートされない」
9.5.5.6項「Webサービスのテスト・ページで、スキーマ機能group、choice、unionまたは属性として導出された単純型がサポートされない」
再帰的スキーマ定義を使用するサービスは、Webサービスのテスト・ページで完全にはサポートされていません。テスト・ページのHTMLフォームには再帰的要素を追加できますが、メッセージが送信されると、再帰的要素は空になります。次に示す再帰的スキーマ定義の例では、listという名前を持つ要素がそれ自身を参照しています。
<xs:element name="list"> <xs:complexType> <xs:sequence> <xs:element ref="list" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="value" type="xs:string"/> </xs:complexType> </xs:element>
再帰的要素を含むメッセージをテスト・ページで作成するには、「XMLソース」ラジオ・ボタンを選択して、メッセージの内容を手動で入力する必要があります。
書式設定済XMLテスト・ページに返されたコンテンツに、大なり（>）文字または小なり（<）文字のXMLエンティティを含む文字列がある場合、コンテンツが欠落するか、正しく表示されません。
返されたコンテンツの内容を確認するには、「XMLソース」ビューに切り替えます。
Web Servicesテスト・ページで無効なWSDLを含むサービスを起動すると、空白または破損したページが表示されます。このようなサービスを起動した場合、テスト・ページまたはログのいずれにもWSDLエラーは表示されません。
次のいずれかの方法を使用して、Webサービス内のWSDLエラーを特定できます。
JDeveloperまたはWebServicesAssemblerでサービス・クライアントを生成する。
WSDL検証コマンドをJDeveloperで使用する。
WS-I検証ツールをJDeveloperで使用する。
Webサービスのテスト・ページにあるフォーム・フィールドの1つに無効な値を送信すると、フィールドが赤にハイライト表示されます。無効な値のあるテスト・ページを送信すると、次のレスポンスを受信する場合があります。
saveChangesでヘッダー・ストリームを取得できません
このエラーを回避するには、無効なエントリを修正してから、実行用にページを送信してください。
グローバリゼーション・サポート（NLSまたは各国語サポートとも呼ばれる）文字を、Webサービスのテスト・ページでの認証用としてユーザー名またはパスワードに使用すると、次のメッセージが表示され、認証が失敗する可能性があります。
<username>を認証できません
また、テスト・ページでは、ユーザー名内のグローバリゼーション・サポート文字が?（疑問符）として表示されます。
Webサービスのテスト・ページでスキーマ機能group、choice、union、または属性として導出された単純型が検出された場合、HTMLフォームにはこれらに対する入力コントロールが表示されます。
たとえば、スキーマに次のコードが含まれているとします。
<xsd:element name="workflowContext" type="workflowContextType"/>
<xsd:complexType name="workflowContextType">
<xsd:choice>
<xsd:element name="credential" type="credentialType"/>
<xsd:element name="token" type="xsd:string"/>
</xsd:choice>
</xsd:complexType>
HTMLフォームにはworkflowContextの入力コントロールが表示されません。
回避方法として、「XMLソース」ラジオ・ボタンを選択して、メッセージの内容を手動で入力できます。
Webサービス・ストレス・テストを、FirefoxブラウザまたはMozillaブラウザで表示したテスト・ページから実行すると、返されたレポートに正しい集約値が表示されない場合があります。正しい集約値を取得するには、かわりにInternet Explorerブラウザを使用します。
この項では、Webサービスのデプロイ時に発生する可能性のある問題について説明します。
EJB 2.1 Webサービスがデプロイ後に使用できない場合は、サービスのデプロイメント・ディスクリプタ・ファイルoracle-webservices.xmlが有効であるか確認してください。アラートの送信なしに、無効なリソースを参照するサービスがデプロイされていることがあります。
この項では、OracleAS Web Servicesの操作中に発生する可能性のあるその他の問題について説明します。
9.5.7.1項「getChildNodeのかわりにgetFirstChildとgetNextSiblingを使用したNodeListの取得」
9.5.7.6項「XMLシリアライズがdocument-literal-bareメッセージ書式のArray Javaデータ型を受け入れない」
node.getChildNode()を使用して取得されたNodeListの反復時に、パフォーマンスが低下することがあります。この低下が重大になるのは、NodeListが非常に長い場合にかぎられます。
Oracleの現在のXDK実装では、node.getChildNode()によって取得されたNodeListを使用するかわりに、node.getFirstChild()の使用とnode.getNextSibling()のループによる子ノード・リストのナビゲーションを最適化できます。次のサンプル・コードは、この技術を示しています。
Node n = ...;
if (n.hasChildNodes()) {
for(Node nd=n.getFirstChild(); nd!=null; nd=nd.getNextSibling()){
nd.getValue(); // do something with nd
}
}
AntタスクでWebサービス・ハンドラを定義するbuild.xmlファイルを編集する場合、ハンドラ・コードにより、class属性またはhandlerClass属性のいずれかを使用して、ハンドラ・クラス名を指定できます。ただし、JDeveloperでhandlerClassを使用してクラス名を指定すると、エディタにはhandlerClassの下に赤線が表示され、それがハンドラ要素で定義されていないという間違った情報を示します。これは、JDeveloperに登録されたXMLスキーマによってhandlerClass属性が認識されないために発生します。
このエラーを回避するには、class属性を使用してハンドラ・クラス名を指定します。
OracleAS Web Servicesで複合型のsoapエンコード配列を使用する場合、要素のxsi型は常にsoapenc:Arrayの値に設定されます（xsi:type=soapenc:Array）。OracleAS Web Servicesでは、soapエンコードarrayTypeを使用して、配列の実際の型と長さを指定します（soapenc:arrayType=<the Actual type>[length]）。
対照的に、BEA 9.0クライアントでは、要素のxsi:typeが実際の型を反映しているものと予想します。BEAクライアントがOracleAS We Servicesから複合型のsoapエンコード配列が含まれるレスポンスを受信すると、クライアントは次のようなエラーをスローします。
internal error: no builtin runtime type for com.bea.staxb.buildtime.internal.bts.BuiltinBindingType
BEAと@ AXIS、IBMまたは.NETプラットフォームの1つ以上との相互運用性が必要な場合は、soapエンコード配列の使用は避けてください。
simpleType型（xs:integerの制限付き）の要素を定義する場合、それは、すべてのJavaプラットフォーム（OC4J、AXIS、BEAなど）でjava.math.BigIntegerにマップされます。
たとえば、次のXMLサンプル・コードの要素maxconcatは、すべてのJavaプラットフォームでBigIntegerにマップされます。
<xs:element name="maxconcat" minOccurs="0" maxOccurs="1" type="aqltype:maxconcat"/>
com.bea.staxb.buildtime.internal.bts.BuiltinBindingType
<xs:simpleType name="maxconcat">
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
ただし、.NETプラットフォームのすべてのバージョン（1.1、2.0および3.0）では、simpleType要素（xs:integer制限付き）がSystem.Stringにマップされます。そのため、この型の値が整数でない場合、実行時に相互運用性の問題が発生する可能性があります。
回避方法として、.NET開発者は、simpleTypeが送信メッセージに使用される場合に、この型に渡される文字列の値が必ず整数になるようにする必要があります。
JAX-RPC Webサービスでは、genValueTypeコマンドがデータ型のBeanクラスを生成しますが、XSDファイルの制限を検証しません。
たとえば、次のXSDフラグメントは、文字列長を16文字に制限する文字列に基づいてデータ型SerialNumberを定義します。genValueTypeがBeanクラスを作成する場合、長さは検証しません。
...
xsd:element name="SerialNumber">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:length value="16"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>/
...
これは、既知の制限です。Oracle Web Services JAX-RPCスタックは、ほとんどの制限を強要しません。この問題を回避するには、生成されたBeanクラスを使用するのではなく独自のBeanクラスを作成します。
document-literal-bare（ラップされていない）メッセージ書式を使用するWebサービスとしてarray Java型を使用するJavaメソッドを公開する場合、メソッドのシリアライズが失敗します。
たとえば、次の定義があるメソッドpublic SearchResult[] WebServiceClass()を公開するとします。
public class SearchResult implements Serializable {
public SearchResult() { }
private String name;
private String value;
public void setName(String name) { this.name = name; }
public String getName() { return name; }
public void setValue(String value) { this.value = value; }
public String getValue() { return value; }
}
public SearchResult[] WebServiceClass(String testTriger) {
System.out.println(testTriger);
return STATIC_RESULT_A;
}
Webサービスをボトムアップで作成する場合、WSDLファイルには、SearchResultメソッドの次のXMLファイルが含まれます。
...
<sequence>
<element name="result" type="tns:SearchResult" nillable="true" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
...
ただし、サービスの実行時に次のエラーが戻されます。
ERROR OWS-04046 serialization error: java.lang.ClassCastException:
この問題を回避するには、doc-literal-wrappedメッセージ書式を使用します。
この項では、OC4Jサービスに関するリリース・ノートについて説明します。OC4Jサービスには、Java Naming and Directory Interface（JNDI）、Oracle Enterprise Messaging Service（OEMS）、データソース、Remote Method Invocation（ORMIおよびIIOP）、OC4Jトランザクション・サポート、Java Object Cache（JOC）、XML Queryサービス（XQS）およびアプリケーション・クライアント・コンテナが含まれます。
この項では、次のOC4Jサービスに関するリリース・ノートについて説明します。
この項では、JNDIに関するリリース・ノートについて説明します。内容は次のとおりです。
このリリースでは、ORMIを使用し、OPMNを介してアプリケーションにアクセスする場合、アプリケーション名に空白を使用できません。次に例を示します。
opmn:ormi://<host>:<port>:home/my deploy
アプリケーション名に空白が含まれていると、次の例外がスローされます。
StrangeAppName not found
この問題を回避するには、アプリケーション名に入っている空白を削除します。
このリリースでは、クライアントJARをクラスタ化されたサーバーにデプロイする場合、/applications/appname/appname_clientディレクトリに書き込まれたjndi.propertiesファイルに、クラスタ化されたインスタンスの1つに接続するための正しいプロバイダURLが含まれていません。クラスタ内のアプリケーション・インスタンスにアクセスするための正しいプロバイダURLは、次のとおりです。
java.naming.provider.url=opmn:ormi://myhost:6003:home/appname
この例では、OPMNポートが6003で、インスタンス名がhomeであると想定しています。
このリリースでは、JNDI環境変数dedicated.connection、dedicated.rmicontextおよびLoadBalanceOnLookupは、非推奨となりました。
レプリケーションに基づくロード・バランシングを構成するには、表9-1の設定を指定して、環境変数oracle.j2ee.rmi.loadBalanceを使用します。
OPMNで管理されるアプリケーション・サーバー・インスタンスにリモート・クライアントを接続する場合、java.naming.provider.url JNDIプロパティは、localhost値をサポートしません。値は、完全なホスト名またはIPアドレスである必要があります。これは、スタンドアロン・アプリケーション・サーバー・インスタンスに接続するクライアントに影響しません。
この項では、Oracle Enterprise Messaging Service（OEMS）に関するリリース・ノートについて説明します。内容は次のとおりです。
このリリースでは、OracleASjmsリソース・アダプタのデフォルト・インスタンスがアンデプロイされている場合、OC4Jを起動するには追加の変更が必要です。
必要な追加変更は次のとおりです。
$J2EE_HOME/config/application.xmlで、次の行をコメントアウトします。
<web-module id="jmsrouter_web" path="../../home/applications/jmsrouter.war" /> <ejb-module id="jmsrouter_ejb" path="../../home/applications/jmsrouter-ejb.jar" />
$J2EE_HOME/config/default-web-site.xmlで、次の行をコメントアウトします。
<web-app application="default" name="jmsrouter_web" root="/jmsrouter" load-on-startup="true" />
これらの変更を行うと、OC4Jを起動できるようになりますが、OracleAS JMS Routerは動作しなくなります。
JMS Routerを回復するには、次のようにします。
OracleASjmsリソース・アダプタ・インスタンスを完全に再デプロイします。
$J2EE_HOME/config/application.xmlおよび$J2EE_HOME/config/default-web-site.xmlで、前述の行を非コメント化します。
OC4Jを再起動すると、OracleAS JMS Routerが使用可能になります。
OC4Jの異常停止後に、次のようなOC4J JMSサーバーの起動に関する問題が発生する場合があります。
(SEVERE) Failed to set the internal configuration of the OC4J JMS Server with: XMLJMSServerConfig[file:/D:/oas0104_web/j2ee/BLUE/config/jms.xml] WARNING: Application.setConfig Application: default is in failed state as initialization failed.
これが発生した場合、他のOC4J JMSサーバーが実行中でないことと、同じ永続性ファイルが使用されていないことを確認します。次に、.lockファイルを次のディレクトリから削除します。
ORACLE_HOME/j2ee/instance_name/persistence
もう一度再起動を試みます。
これで問題が解決しない場合は、jms.xmlファイルが有効であることを確認してください。
それでも問題が解決しない場合は、persistenceディレクトリからjms.stateファイルを削除して、もう一度再起動を試みますが、この場合、このファイルを削除することでトランザクション情報が失われる可能性がある点に注意してください。詳細は、『Oracle Containers for J2EEサービス・ガイド』の「Oracle Enterprise Messaging Service（OEMS）」の「異常終了」を参照してください。
このリリースのOracle Application Serverでは、Oracle Application Server 10.1.2とXA形式のJMS接続はサポートされていません。
下位互換性の関係で、自動登録機能はこのリリースでも使用できますが、使用しないことをお薦めします。この機能は、デフォルトでは無効になっています。グローバル・トランザクションへのXAおよびXA以外のJMS接続の登録をこれまで自動登録機能に依存していたアプリケーションの場合は、jms.xml構成ファイルのoc4j.jms.pseudoTransactionEnlistment構成プロパティをtrueに設定する必要があります。
次のJMSクライアント・プロパティに変更を加えた場合、OC4Jサーバーを再起動する必要があります。
oc4j.jms.serverPoll
oc4j.jms.messagePoll
oc4j.jms.noDms
プロパティの更新に使用する方法（手動でjms.xmlを編集するか、Application Server Controlコンソールを使用するかのいずれか）に関係なく、変更を有効にするには、サーバーを再起動する必要があります。
10.1.3.2リリースには、高パフォーマンスで完全にCTS準拠した新しいJMSプロバイダの早期アクセス版が含まれています。次のシステム・プロパティを使用してOC4Jを起動し、新しいJMSプロバイダを有効にしてください（デフォルトOC4J-JMSプロバイダを上書きします）。
-Doc4j.jms.implementation=oracle.j2ee.jms
-Doc4j.jms.implementation=oc4j.j2ee.jmsシステム・プロパティはサポートされていますが、推奨されていません。
|
注意: 新しいJMSプロバイダは、J2EE_HOME\config\jms.xmlファイルを編集して構成します。Enterprise Manager Application Server Controlコンソールを使用した構成は、サポートされていません。 |
キュー表を古い互換性モードを使用して構成した場合、OEMSデータベース永続性機能のパフォーマンスが低下します。互換性モードは、compatibleパラメータを使用して設定します。次に例を示します。
DBMS_AQADM.CREATE_QUEUE_TABLE(
Queue_table => 'demoTestQTab',
Queue_payload_type => 'SYS.AQ$_JMS_MESSAGE',
sort_list => 'PRIORITY,ENQ_TIME',
multiple_consumers => false,
compatible => '8.1.5');
新しいスキーマ・レイアウトの移行に問題がある、または既存のキュー表を新しいスキーマ・レイアウトにエクスポートできない場合のみ、compatibleパラメータを古いモードに設定してください。
最新のスキーマ・レイアウトを使用する場合は、compatibleパラメータを10.0.0.0.0に設定するか、またはパラメータを省略してデフォルトの互換性モードを使用してください。どちらのオプションを使用しても、スキーマおよびロック・メカニズムの効率が向上します。
この項では、データソースに関するリリース・ノートについて説明します。内容は次のとおりです。
com.evermind.sql.DbUtil.oracleFatalError()メソッドは、致命的エラーの取得に使用できなくなりました（RACのフェイルオーバー中など）。このメソッドは、oracle.oc4j.sql.DataSourceUtils.isOracleFatalError()メソッドに置き換えられました。これは内部メソッドで、一般利用を目的としていません。下位互換性の目的でのみ使用する必要があります。メソッドは、新しい開発には使用しないでください。
クラスoracle.jdbc.pool.OracleConnectionCacheImplは、複数のスキーマに対応していないため、非推奨となりました。コネクション・ファクトリに対するfactory-classの定義や、ネイティブ・データソースに対するdata-source-classの定義には、oracle.jdbc.pool.OracleDataSourceを使用してください。
Oracle CMPは、このリリースで提供されているデフォルトのJDBCドライバを使用した場合にのみ、正常に動作します。別のバージョンのOracle JDBCドライバを、OC4J共有ライブラリ機能などを使用して、OC4Jインスタンスに追加し、Orion CMPを使用するアプリケーションで使用するように構成すると、問題が発生します。
Orion CMPを使用する場合、常にOC4Jに付属しているOracle JDBCドライバを使用してください。
コンポーネント依存性のため、JDBC THINドライバは、Oracle Application Serverインスタンス・レベルでアップグレードまたは変更できません。JDBC THINドライバは、共有ライブラリ機能を使用して、それぞれのOC4Jインスタンスでアップグレードします。
JDBC THINドライバのアップグレード手順は、OTNのHow Toサイトにあります。
http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.html
この項では、OC4Jトランザクション・サポートに関するリリース・ノートについて説明します。内容は次のとおりです。
OC4Jによるデータベース内トランザクション・コーディネータの使用は、リリース10.1.3以降、非推奨となりました。今後は、中間層トランザクション・コーディネータを使用することをお薦めします。
OC4Jトランザクション・マネージャには、リカバリ可能最終リソース・コミット（RLRC）という新機能が含まれています。この機能により、最終リソース・コミット（LRC）トランザクションに対するリカバリ・メカニズムが強化され、そのようなトランザクションの全体的なパフォーマンスが高まります。
RLRCでは、データベース表を使用して、トランザクションIDのコミット記録を保持します。これにより、中間層にあるOC4Jトランザクション・ログのコミット記録が不要になります。コミット記録の書込みは、2フェーズ・コミット処理のパフォーマンス・コストの大部分を占めます。
|
注意: RLRCは現在、非XAリソースのデータベースが関係する場合にのみ使用できます。さらに、コミット記録がこのデータベースで保持されるため、そのようなRLRCトランザクションのリカバリが必要な場合に、データベースにアクセスできることが必要です。 |
RLRCを設定するには、次のようにします。
サーバーが起動している場合は、停止します。
J2EE_HOME/database/j2ee/jta/oracle/last_resource_commit.sqlスキーマと2pc_jdbcstore.sqlスキーマを、コミット記録を保持するデータベースにインストールします。
J2EE_HOME/config/data-sources.xmlファイルを開き、コミット記録データベースにアクセスするための接続プールを編集または作成し、コネクション・ファクトリ要素の一部としてcommit-record-table-name属性を指定します。次に例を示します。
[…]
<connection-pool name="Example Connection Pool" num-cached-statements='10'>
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@myServer:5521:main"
commit-record-table-name="scott.OC4J_TX_RLRC_LOG">
<property name="connectionCachingEnabled" value="false"/>
<property name="implicitCachingEnabled" value="true"/>
<property name="maxStatements" value="50"/>
</connection-factory>
</connection-pool>
[…]
|
注意: commit-record-table-name属性の名前は、完全修飾された値であり、指定されたパスワードにはこの表に対する削除権限および選択権限が必要です。 |
（オプション）J2EE_HOME/config/transaction-manager.xmlファイルを開き、RLRC機能のランタイム動作を変更します。次に例を示します。
[...]
<commit-coordinator>
<middle-tier>
<recovery retry-interval = "300" rlrc-purge-interval="10"
rlrc-purge-size="1000">
</middle-tier>
</commit-coordinator>
[...]
]
rlrc-purge-interval: この属性は、データベースでのコミット記録のバッチ・パージが発生する間隔（秒単位）です。
rlrc-purge-size: この属性は、データベースでのコミット記録のバッチ・パージ中に削除されるバッチのサイズです。
サーバーを起動します。
標準TransactionManagerインタフェースの新しい機能拡張機能が、OC4JTransactionManagerインタフェースに追加されました。この機能は、Spring Framework（http://www.springframework.org）のOC4JJtaTransactionManager統合を使用する際にも、使用できます。
oracle.j2ee.transaction.TransactionUtility Singletonにより、OC4JUserTransaction、OC4JTransactionManagerおよびOC4JTransactionインタフェースに直接アクセスできます。Singletonは、getOC4JUserTransaction()、getOC4JTransactionManager()およびgetOC4JTransaction()メソッドを使用してJNDIを参照せずに、これらのインタフェースにアクセスできます。
OC4JTransactionManagerインタフェースは、次のメソッドを含みます。
void begin(String type) throws javax.transaction.NotSupportedException, javax.transaction.SystemException;
public void setType(String type);
public String getType();
void setTransactionIsolation(int transactionIsolation);
int getTransactionIsolation();
int getTransactionTimeout();
OC4JTransactionインタフェースは、次のメソッドを含みます。
public void setType(String type);
public String getType();
void setTransactionIsolation(int transactionIsolation);
int getTransactionIsolation();
int getTransactionTimeout();
トランザクション型付け（または名前付け）により、トランザクションを管理およびレポート作成のための論理グループにカテゴリ分けできます。
トランザクション分離レベル毎に指定すると、グローバル・トランザクションに登録されているすべてのリソースで、指定された同一の分離レベルを共有できるようになります。現在、この機能はJDBC接続に制限されています。
この項では、OC4J Remote Method Invocation（RMIおよびIIOP）に関するリリース・ノートについて説明します。内容は次のとおりです。
このリリースでは、次の推奨事項に注意してください。
RMIポートは、ただちに解放されないことがあります。
古いトンネリングは非推奨となりました。『Oracle Containers for J2EEサービス・ガイド』のRMIに関する章の「HTTPを介したORMIトンネリングの構成」で説明している新しいURL書式を使用してください。
プロバイダのURL書式に誤りがある場合、次の間違ったエラー・メッセージが表示されます。
「プロバイダのURLは[opmn:]corbaname::host:port#/appnameの書式である必要があります」
このエラー・メッセージのURL書式は正しくありません。正しいURL書式は次のとおりです。
[opmn:]corbaname::host:port#[instancename#]appname
この項では、OC4J XML Queryサービス（XQS）に関するリリース・ノートについて説明します。内容は次のとおりです。
XQSクライアントAPIにXQSFactoryクラスが含まれるようになりました。このクラスで提供されるファクトリは、新規のメインXQSクライアント・インタフェースのインスタンスを作成するために使用されます。
oracle.xqs.client.QueryParameterI
oracle.xqs.client.XQSFacadeI
以前の各クラスは、非推奨となりました。
oracle.xds.client.QueryParameter
oracle.xds.client.XQSFacade
<xqsview-source>要素は、データベース・アクセスのSQL問合せの定義に使用されるようになりました。<wsdl-source>要素は、使用されなくなりました。<xqsview-source>要素は、SQLベースのXQSビューの一部として定義されます。
『Oracle Containers for J2EEサービス・ガイド』のXQSの章に誤りがあります。「入力パラメータのタイプ・チェック」に記載されているXQuery式の例は、正しくありません。正しい例は次のとおりです。
import schema namespace ns1="urn:namespace_1" at "http://mydomain/myschema.xsd"; declare namespace xqs = "http://xmlns.oracle.com/ias/xqs"; declare function xqs:takeNS1Input($param as element(ns1:InputElement)?) external; let $in := <ns1:InputElement>...</ns1:InputElement> let $y := xqs:takeNS1Input($in) return <result>$y//ns1:Content</result>
『Oracle Containers for J2EEサービス・ガイド』のXQSの章に誤りがあります。「XQueryのオプション機能」には、XQueryのスキーマ・インポート機能がサポートされないと記載されています。XQSでは、W3Cの定義に基づいてスキーマ・インポート機能がサポートされます。
この項では、OC4Jアプリケーション・クライアント・コンテナに関するリリース・ノートについて説明します。内容は次のとおりです。
このリリースでは、アプリケーション・クライアントのカスタム・セキュリティ・コールバック・ハンドラを実装する際、ハンドラで3つのコールバック・オブジェクト（NameCallback、PasswordCallbackおよびTextInputCallback）をすべて設定する必要があります。3つのオブジェクトをすべて設定しないと、OC4Jサーバーへのリモート接続のインスタンス化を試行する際にjava.lang.NullPointerExceptionが表示され、JNDIコンテキストの設定に失敗します。
この項では、J2EE Connector Architecture（J2CA）に関するリリース・ノートについて説明します。内容は次のとおりです。
このリリースでは、スタンドアロン・リソース・アダプタは、デフォルト・アプリケーションのクラス・ローダーに追加されなくなりました（内部JMSおよびデータソースのリソース・アダプタを除く）。かわりに、スタンドアロン・リソース・アダプタは、デフォルトですべてのアプリケーションで使用可能な共有ライブラリとして追加されます。新しいアーキテクチャは、複数のバージョンのスタンドアロン・アダプタをOC4Jにデプロイできます。詳細は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』を参照してください。
このリリースでは、スタンドアロン・リソース・アダプタがインポートできるのは、すでにデプロイされているスタンドアロン・リソース・アダプタのみです。このため、スタンドアロン・リソース・アダプタは、すべての依存スタンドアロン・リソース・アダプタより先にデプロイする必要があります。この動作は10.1.3とは異なります。10.1.3では、スタンドアロン・リソース・アダプタは、自身のデプロイ後にデプロイされたスタンドアロン・リソース・アダプタを参照し、使用することができます。
このリリース以降、デフォルトのクラス・ローダーに依存して実行時に共有ライブラリ以外の依存性を解決するリソース・アダプタは、失敗します。ライブラリおよびその他のスタンドアロン・リソース・アダプタでの依存性は、共有ライブラリのインポートによって明示的に構成されます。スタンドアロン・リソース・アダプタ固有のデプロイメント・ディスクリプタ（oc4j-ra.xml）は、共有ライブラリのインポートに使用されます。共有ライブラリのインポートの詳細は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』を参照してください。
Oracle Application Server 10.1.3.1.0実装では、OC4Jインスタンス内のスタンドアロン・リソース・アダプタのデプロイ、再デプロイ、アンデプロイ後に、デフォルト・アプリケーションを再起動する必要はなくなりました。スタンドアロン・リソース・アダプタを利用する依存J2EEアプリケーションは、再起動する必要があります。
ただし、デフォルト・アプリケーションの再起動が依然として必要な場合もあります。具体的には、Oracle Enterprise Messaging Service（OEMS）ファイルとメモリー・ベース・プロバイダ（OracleASjms.rar）またはOEMSデータベース永続性プロバイダ（ojms.rar）にアクセスするためのアダプタでデプロイ操作を実行した場合は、デフォルト・アプリケーションを再起動する必要があります。
これらのアダプタは、JMS接続用のOracle内部リソース・アダプタであり、その管理タスクでは、追加のデプロイおよび再デプロイ操作が必要になる場合があります。
OracleAS JAAS Providerをリリース10.1.3.1または10.1.3.2で使用する際には、次のノートに注意してくだい。
10.1.3.1の『Oracle Containers for J2EEセキュリティ・ガイド』の第7章「ファイルベースのセキュリティ・プロバイダ」の「移植ツールのコマンドの構文」で、項の冒頭に示されている構文は不完全です。構文にはJAZNMigrationToolのパッケージを含める必要があります。正しい構文は次のとおりです。
% java oracle.security.jazn.tools.JAZNMigrationTool [-st xml] [-dt ldap|xml] [-D binddn] [-w passwd] [-h ldaphost] [-p ldapport] [-sf sourcefilename] [-df destfilename] [-sr source_realm] [-dr dest_realm] [-m policy|realm|all] [-help]
（これは、項の最後の例で正しく示されています。）
外部LDAPプロバイダとともにJAAS認可を使用している状況について、このリリース・ノートでは、『Oracle Containers for J2EEセキュリティ・ガイド』の第10章「外部LDAPセキュリティ・プロバイダ」の「外部LDAPプリンシパルへの追加のパーミッションの付与」での非常に簡単な説明を補う詳細を提供しています。
JAZNMigrationToolは、ファイルベースのプロバイダをかわりのファイルベース・プロバイダまたはOracle Internet Directoryに移行するために使用されるのがより一般的ですが、外部LDAPプロバイダとともに使用して、JAASポリシー情報をターゲット・サーバー上のsystem-jazn-data.xmlファイルに移行することもできます。
外部LDAPプロバイダのLDAPプリンシパルに必要な権限を付与するには、次の手順を実行します。
JAASポリシー情報を、開発サーバー上のsystem-jazn-data.xmlからターゲット・サーバー上のsystem-jazn-data.xmlに、-m policy設定を使用して移行します。これにより、ポリシー情報のみがターゲットのsystem-jazn-data.xmlファイルに移行されます。外部LDAPプロバイダにユーザーおよびロール情報を直接移行するために、JAZNMigrationToolは使用できません。（より正確に言えば、JAZNMigrationToolでは、外部LDAPプロバイダに適したLDIFファイルを作成できません。作成できるのは、Oracle Internet Directoryにのみ適したLDIFファイルと、Oracle Internet Directoryで予想されるディレクトリ情報ツリーおよびスキーマです。）
移行されたポリシー情報を、LDAPPrincipalを使用するために手動で編集します。
手順1で説明したようにポリシー情報を移行すると、その結果、ターゲットのsystem-jazn-data.xmlファイル内には、XMLRealmRoleプリンシパル・クラスを参照する権限受領者のエントリが生じます。外部LDAPプロバイダと使用するには、かわりにLDAPPrincipalクラスを参照するようにこれらのエントリを更新する必要があります。たとえば、system-jazn-data.xmlで権限受領者要素に次のプリンシパル構成が含まれているとします。
<principal>
<realm-name>jazn.com</realm-name>
<type>role</type>
<class>oracle.security.jazn.spi.xml.XMLRealmRole</class>
<name>jdoe</name>
</principal>
<realm-name>要素と<type>要素を削除し、XMLRealmRoleのかわりにLDAPPrincipalを指定するためには、これを次のように手動で更新する必要があります。
<principal>
<class>oracle.security.jazn.realm.LDAPPrincipal</class>
<name>jdoe</name>
</principal>
外部LDAPプロバイダに、必要なユーザー・アカウントおよびロール・アカウントを手動で作成します。作成したユーザー名およびロール名が、手順1でターゲット・サーバーに移行したポリシー構成で参照されるプリンシパルに準拠していることを確認します。
|
注意: JAASモードを有効にし、必要なロール・マッピングを設定するためにorion-application.xmlを更新する追加の手順については、『Oracle Containers for J2EEセキュリティ・ガイド』ですでに説明されています。 |
『Oracle Containers for J2EEセキュリティ・ガイド』の第8章「Oracle Identity Management」の「SSOの構成（オプション）」の最初の手順「SSO登録ツールの実行」で、次の例が示されています。
% $ORACLE_HOME/sso/bin/ssoreg.sh -oracle_home_path $ORACLE_HOME \ -site_name myhost.mydomain.com -config_mod_osso TRUE \ -mod_osso_url http://myhost.mydomain.com:7777 -remote_midtier \ -config_file $ORACLE_HOME/Apache/Apache/conf/osso/osso.conf
実際に、構成ファイル名osso.confを使用してこの正確なコマンドを実行すると、osso.confがすでに存在していることを示すエラーが発生します。（既存のosso.confファイルを上書きしないでください。）osso.confのかわりに、たとえばmidtier_osso.confのような他のファイル名を使用します。新しいファイルが指定した名前で作成されます。ファイルには、SSOと関連付ける中間層用のSSOパートナ・アプリケーション構成が含まれます。このファイルを構成する中間層にコピーします。
|
ヒント: ファイル名は、中間層のホストおよびポートを示すように指定することをお薦めします。たとえば、midtier1_7779_osso.confのようにします。 |
『Oracle Containers for J2EEセキュリティ・ガイド』の「新機能」では、新しいユーザー/ロールAPIフレームワークに、com.evermind.securityパッケージ内の非推奨となったUserManagerクラス、UserクラスおよびGroupクラスの代替機能が含まれていることが記載されています。
ユーザー/ロールAPIフレームワークには、oracle.security.jaznパッケージ内またはその下のレルムAPIの代替機能があることにも注意してください。
これらのパッケージは非推奨となり、11gリリースではサポートされません。
OracleAS JAASプロバイダ移行ツールを使用して、ファイルベース・プロバイダからOracle Identity Management（実質的には、Oracle Internet Directory）セキュリティ・プロバイダに、policyモードまたはallモードのいずれかで、ポリシーを移行する場合、次の問題が発生することに注意してください。移行ツールでは、ポリシー構成の権限受領者エントリで、カスタムまたは非レルム・プリンシパル名の先頭に、Oracle Internet Directoryレルム名が追加されます。（たとえば、カスタム・プリンシパルは、カスタム・ログイン・モジュールを介して認証する場合に機能します。）
移行された構成では、権限受領者エントリのカスタム・プリンシパル名は、たとえば、usがレルム名だとすると、ただのanyoneではなく、us/anyoneとなります。その結果、権限の問題が発生します。たとえば、ADFアプリケーションの場合、セキュリティ・プロバイダとしてのOracle Internet Directoryへの移行後に、パブリック・ページが機能しなくなります。
この問題は、10.1.3.3リリースでは解決される予定です。10.1.3.2および前の10.1.3.xリリースでは、次のいずれかの回避方法を使用できます。
移行ツールで作成したLDIFファイルをOracle Internet Directoryにインポートする前に、ファイルからus/接頭辞を手動で削除する。
移行後にOracle Internet Directory管理ツールを使用して、関連の権限受領者エントリからus/接頭辞を手動で削除する。
10.1.3.x実装のデフォルトでは、OC4Jは、LDAPベースのプロバイダへの接続に接続プーリングを使用する場合、java.lang.ref.WeakReferenceオブジェクトを使用してJNDIコンテキストをキャッシングし、JVMガベージ・コレクションを使用してJNDIコンテキストのガベージ・コレクションを行います。
ただし、このWeakReferenceおよびJVMガベージ・コレクション機能に依存しないことをお薦めします。これを無効にするには、次のプロパティ設定を行います。
<jazn ... > <property name="jndi.ctx_pool.weakref.enable" value="false" /> ... </jazn>
（デフォルト設定は"true"です。）この機能を無効にした場合、OC4Jは、接続プールでのキャッシング制御に次のプロパティを使用します（値は管理者が適切に設定してください）。
jndi.ctx_pool.timeout: LDAP JNDI接続プールのミリ秒のタイムアウト値。デフォルト値は0（タイムアウトなし）です。推奨値は3600000ミリ秒（1時間）です。
jndi.ctx_pool.threshold_size: プールのアイドル接続数を制限するしきい値。デフォルト値は100（推奨の初期値）です。
（jndi.ctx_pool.weakref.enableが"true"の場合、両方のプロパティは無視されます。）
次に例を示します。
<jazn ... > <property name="jndi.ctx_pool.weakref.enable" value="false" /> <property name="jndi.ctx_pool.threshold_size" value="100" /> <property name="jndi.ctx_pool.timeout" value="3600000" /> ... </jazn>
|
注意:
|
DCMコンポーネントは、Oracle Application Server 10.1.3でサポートされなくなりました。そのため、jazn.jar管理ツールで-clustersupportオプションは使用できなくなりました。
問題
jazn.jarの起動時に-clustersupportオプションを使用すると、次のエラーが発生します。
An error has occured in propagating the changes to the cluster. java.lang.ClassNotFoundException oracle.security.jazn.smi.DcmUtil
この問題は、以前のリリースのOracle Application Serverによってクラスタ全体に共通構成情報をレプリケートするのに使用されていたDistributed Configuration Management（DCM）がリリース10.1.3でサポートされなくなったために発生します。このため、-clustersupportオプションは、現在JAZN（jazn.jar）管理ツールでサポートされません。
解決策
jazn.jarの起動時に-clustersupportオプションを使用しないでください。
AJP13プロトコルを使用するサイトをOC4Jで実行しているとき、リモートの攻撃者がOC4Jの稼働するマシンのAJPポートに直接アクセスできる場合には、セキュリティ上の脆弱性が存在します。AJP13プロトコルでは、AJPパラメータremote_userを定義しており、OHSではこのパラメータを使用してmod_ossoを実装します。攻撃者は、このパラメータを使用してOC4Jの認証を回避することが可能です。ユーザーは、有効なremote_user値をAJPパラメータとして挿入するAJPパケットを作成することで、指定したユーザー（リモート・ユーザー）がアクセス権を持つリソースにアクセスできます。
管理者は、OC4Jの稼働するシステムが外部に対してAJPポートを公開していないことを確認する必要があります。
この脆弱性に対処するには、次のいずれかの方法を使用します。
OC4JとOracle HTTP Server間でSSLを有効化します（推奨）。リリース10.1.3.xの場合、この方法は『Oracle Containers for J2EEセキュリティ・ガイド』に記載されています。リリース10.1.2または9.0.4の場合、この方法は『Oracle Containers for J2EEサーブレット開発者ガイド』に記載されています。
global-web-application.xmlまたはorion-web.xmlの<access-mask>要素（<orion-web-app>のサブ要素）を使用して、適切なホスト名、ドメインまたはIPアドレスのみにアクセスを制限します。この要素は『Oracle Containers for J2EEサーブレット開発者ガイド』に記載されています。
この項では、OC4Jの一般的な問題について説明します。
スタンドアロンOC4JインスタンスをApplication Server Controlを使用して複数回再起動すると、エラーjava.lang.OutOfMemoryErrorが発生し、それがサーバー・コンソールで報告され、OC4Jインスタンスは使用できなくなります。
エラーを回避するには、OC4Jインスタンスを手動で停止し、再起動します。
この項では、Oracle Application Server 10gリリース10.1.3.1および10.1.3.2で確認されているエラーについて説明します。内容は次のとおりです。
9.10.2項「『Oracle Application Server Web Servicesアドバンスト開発者ガイド』」
9.10.9項「『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』」
この項では、Webサービス・ドキュメントの訂正箇所を示します。内容は次のとおりです。
wsclient_extended.zipファイルとコンパニオンCDに対する次の間違ったリンクが、『Oracle Application Server Web Services開発者ガイド』の第4章および付録Aで使用されています。
http://download.oracle.com/otn/java/oc4j/10131/wsclient_extended.zip
正しいリンクは次のとおりです。
http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html
『Oracle Application Server Web Servicesアドバンスト開発者ガイド』の表H-4「Java CollectionクラスからXML型へのマッピング」には、XML型名に次の誤植があります。
--java.util.HashMapをowi:hashmapにマップ。これは間違っています。正しくは、owi:hashMapにマップ（Mは大文字です）。
--java.util.TreeMapをowi:treemapにマップ。これは間違っています。正しくは、owi:treeMapにマップ（Mは大文字です）。
正しいリンクは次のとおりです。
http://www.oracle.com/technology/software/products/ias/htdocs/utilsoft.html
『Oracle Application Server Web Services開発者ガイド』の「スタブ・クライアントのServiceLifecycleインタフェースによるヘッダーの取得方法」では、oracle.webservices.ServerConstantsクラスのHTTP_SERVLET_REQUESTプロパティとHTTP_SERVLET_RESPONSEプロパティをどのように使用すれば、HTTPメッセージ・ヘッダーにアクセスできるかが説明されています。
この項では、HTTPメッセージ・ヘッダーにアクセスするために、これらのプロパティを、サーバー上と同様にクライアント上でも使用できるとしています。これは間違っています。これらのプロパティを使用して、クライアントはHTTP層にまったくアクセスできません。クライアント上でこれらのプロパティをコールしようとすると、次のような例外が返されます。
javax.xml.rpc.JAXRPCException: スタブは次のプロパティを認識しません:...
回避する方法はありません。
この項では、『Oracle Application Server Web Servicesアドバンスト開発者ガイド』の誤りについて説明します。内容は次のとおりです。
『Oracle Application Server Web Servicesアドバンスト開発者ガイド』の「Webサービス・プロバイダの使用方法」には、間違ったXMLを使用した例があります。
例10-5
<provider-description>句を含むoracle-webservices.xmlフラグメントは、整形式XMLではありません。
閉じタグのスラッシュの後のスペースを削除する必要がある場合:
変更前: </ wsdl-service-name> 変更後: </wsdl-service-name>
変更前: </ implementation-class> 変更後: </implementation-class>
閉じタグのスラッシュが抜けている場合:
変更前: <auditing>...<auditing> 変更後: <auditing>...</auditing>
例10-6
web.xmlデプロイメント・ディスクリプタのProvider要素は整形式ですが、無効なXMLです。
JDeveloper 10.1.3.3.0.4157スキーマ検証に従うと、説明と表示名の要素の順序が不適切であり、位置が間違っています。
変更前:
<servlet-name>LoggerProviderPort</servlet-name>
<display-name>LoggerProviderPort</display-name>
<description>JAX-RPC endpoint Provider Port</description>
変更後:
<description>JAX-RPC endpoint Provider Port</description>
<display-name>LoggerProviderPort</display-name>
<servlet-name>LoggerProviderPort</servlet-name>
この項では、Webサービス・ドキュメントの訂正箇所を示します。内容は次のとおりです。
9.10.3.3項「removeSharedLibrary AntタスクのversionプロパティはlibraryVersionの誤り」
9.10.3.8項「EJBモジュールの増分再デプロイがApplication Server Controlでサポートされない」
第10章「デプロイに対するOC4J Antタスクの使用方法」の「データソース接続プールのテスト」に記載されているtestDataSourceConnectionPool Antタスクの例のname属性は正しくはconnectionPoolNameです。この例は、リリース10.1.3.1の『Oracle Containers for J2EEデプロイメント・ガイド』に記載されています。
正しい例は次のとおりです。
<oracle:testDataSourceConnectionPool deployerUri="deployer:oc4j:localhost" userid="oc4jadmin" password="welcome1" applicationName="default" connectionPoolName="ScottConnectionPool" sqlStatement="select * from dual" />
『Oracle Containers for J2EEデプロイメント・ガイド』の第10章「デプロイに対するOC4J Antタスクの使用方法」の「OC4J Antタスクの使用準備」および「環境へのOC4J Antタスクの組込み」で、2箇所に記載されているファイル名oracle-ant.jarは、ant-oracle.jarの誤りです。
第2段落
間違ったテキスト: oracle-ant.jarファイルは、デフォルトでORACLE_HOME/ant/libディレクトリにインストールされます。
正しいテキスト: ant-oracle.jarファイルは、デフォルトでORACLE_HOME/ant/libディレクトリにインストールされます。
ant-oracle.xmlの説明
間違ったテキスト: これが必要になるのは、oracle-ant.jarがORACLE_HOME/ant/libディレクトリにインストールされていない場合のみです。
正しいテキスト: これが必要になるのは、ant-oracle.jarがORACLE_HOME/ant/libディレクトリにインストールされていない場合のみです。
どちらの箇所でも、ディレクトリ・パスは正しい記述です。
『Oracle Containers for J2EEデプロイメント・ガイド』の第10章「デプロイに対するOC4J Antタスクの使用方法」にある「共有ライブラリの作成と管理」のサブセクション「共有ライブラリの削除」で、removeSharedLibrary Antタスクのversionプロパティは、libraryVersionの誤りです。
removeSharedLibrary Antタスクの正しい例は、次のとおりです。
<oracle:removeSharedLibrary
deployerUri="${deployer.uri}"
userid="${oc4j.admin.user}"
password="${oc4j.admin.password}"
logfile="${log.dir}/filename.log"
libraryName="name"
libraryVersion="version"/>
『Oracle Containers for J2EEデプロイメント・ガイド』の第14章「OC4Jでのオートデプロイの使用方法」にある「更新の確認機能の使用」の「注意」には、次のように記載されています。
|
注意: ORACLE_HOME/j2ee/instance/applicationsディレクトリにコピーされたEARファイルまたはWARファイルは、オートデプロイが有効かどうかに関係なく、OC4Jの起動時にデフォルトでデプロイまたは再デプロイされます。 |
EARまたはWARファイルは、そのタイムスタンプが、そのファイルを含んでいるディレクトリのタイムスタンプより新しい場合にもデプロイされます。
第6章「admin_client.jarユーティリティの使用方法」のいくつかのコマンド・サブスイッチ名は、間違っています。表9-2に、これらのサブスイッチの間違った名前と正しい名前を示します。また、この表では、ドキュメント内でスペルが間違っていた-addDataSourceConnectionPoolコマンドの正しい名前も示します。
表9-2 admin_client.jarコマンドのサブスイッチの正しい名前
| コマンド | 間違ったサブスイッチ名 | 正しいサブスイッチ名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第11章「デプロイに対するadmin_client.jarユーティリティの使用方法」の「アーカイブの再デプロイ」にある-redeployコマンド・サブスイッチの説明には、次の情報が欠けています。
-fileサブスイッチでは、EARだけでなく、EAR、WARまたはRARの名前を指定できます。
-bindAllWebApps [webSiteName]サブスイッチが記載されていません。このオプションのサブスイッチでは、指定したWebサイトにすべてのWebモジュールをバインドできます。指定がない場合は、default Webサイトにバインドされます。
オプションで、webSiteNameの値を指定できます。この値は、Webサイトを構成するname_web-site.xmlファイルのname部分に相当します。
deploymentPlanプロパティが、第10章「デプロイに対するOC4J Antタスクの使用方法」の表10-7「スタンドアロンWARデプロイのためのdeployタスクのプロパティ」に誤ってリストされています。deploymentPlanを使用して、スタンドアロンのWebモジュールをデプロイすることはできません。
Application Server Controlコンソールが、第3章「EJBモジュールのデプロイ」のEJBモジュールの増分再デプロイに関する項にツールとして誤ってリストされています。EJBモジュールの増分再デプロイにApplication Server Controlを使用することはできません。かわりに、リストされている次のツールを使用します。
admin_client.jarコマンドライン・ユーティリティの-updateEBJModuleコマンド（またはスタンドアロンOC4Jの場合はadmin.jar）
updateEJBModule Antタスク
JDeveloper
EJBの再デプロイの詳細は、この章を参照してください。
この項では、OC4Jサービス・ガイド・ドキュメントの訂正箇所を示します。内容は次のとおりです。
『Oracle Containers for J2EEサービス・ガイド』の「データソースの定義」に誤りがあります。「構成に関する注意事項」の項の5番目の項目は正しくありません。項目の正しい内容は、次のとおりです。
「ネイティブ・データソースを定義するには、<native-data-source>要素を使用します。data-source-class属性には、javax.sql.DataSourceインタフェースを実装するオブジェクトのいずれかの完全修飾クラス名を設定できます。」
『Oracle Containers for J2EEサービス・ガイド』のデータソースの章に誤りがあります。接続プールの属性の表に、time-to-live-timeout属性とabandoned-connection-timeout属性の誤ったデフォルト値がリストされています。これらの機能の正しいデフォルト値は、-1ではなく0です。デフォルト値（0）は、これらの機能が無効化されることを示します。
表5-3「接続プールの属性」には、disable-server-connection-pooling属性の説明が含まれます。この属性は、サポート対象外となったため、J2EE_HOME/config/data-sources.xml構成ファイルに追加しないでください。
『Oracle Containers for J2EEサービス・ガイド』のデータソースの章に誤りがあります。接続プールの属性の表では、max-connections属性を0に設定すると、接続プールが無効になると説明されています。OracleのImplicit Connection Cache（ICC）を使用する場合、この値を0に設定しても接続プールは無効になりません。かわりに、SQLエラーが戻されます。
java.sql.SQLException: Unable to get a physical connection from the database... there are no connections available.
oracle.jdbc.pool. OracleDataSource接続ファクトリ・クラスを使用する場合に接続プールを無効にするには、connectionCachingEnabledプロパティをfalseに設定します。次に例を示します。
<connection-pool name="myConnectionPool"
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//localhost:1521/">
<property name="connectionCachingEnabled" value="false"/>
</connection-factory>
</connection-pool>
この項では、リリース10.1.3.1の『Oracle Containers for J2EEセキュリティ・ガイド』の次の訂正箇所を示します。
リリース10.1.3.1の『Oracle Containers for J2EEセキュリティ・ガイド』には、次の記載を含む2つの注意事項があります。「...orion-application.xmlで構成されたプロバイダが認証に使用されるIDストアになり、jazn.xmlで指定されたプロバイダが認可に使用されるポリシー・ストアになるという混在した状態になります。この構成はお薦めしません。」
この文章は、第5章「OC4Jでの認可」の「jazn.xmlでのポリシー・リポジトリ設定」および第8章「Oracle Identity Management」の「Oracle Internet DirectoryとOC4Jの関連付け」にあります。
これが推奨されないと説明するのは、正しくありません。実際には、外部LDAPまたはカスタム・ログイン・モジュールを使用する場合、代替策はこれのみです。特定の手順または注意が必要ですが、この手順はすでに説明されています。
リリース10.1.3.1の『Oracle Containers for J2EEセキュリティ・ガイド』の第6章の「パスワードの間接化の使用方法」に、次の注意事項があります。「現在のOC4J実装で間接パスワードの使用を選択すると、system-jazn-data.xmlファイルに間接ユーザーが作成されます。これらの間接ユーザー・アカウントは、アプリケーションをアンデプロイしても自動的に削除されないことに注意してください。不要となった間接ユーザー・アカウントは、Application Server Controlコンソールを使用して手動で削除する必要があります。」
この注意事項は誤りで、間接ユーザー・アカウントがWebサービスの場合に自動的に作成されるのは、Application Server Controlコンソールを使用してキーストアまたはキーストア・パスワード（署名キーおよび暗号化キー）を構成する場合のみです。
この注意事項は、正しくは、間接ユーザー・アカウントを自動または手動のいずれかで作成した場合、アプリケーションをアンデプロイしてもアカウントは自動的に削除されないため、手動で削除する必要がある、という内容です。
リリース10.1.3.1および10.1.3.0.0の『Oracle Containers for J2EEセキュリティ・ガイド』の第6章の「パスワードの間接化の使用方法」に、ファイルdata-sources.xml内の<data-source>要素のpassword属性に関する文章があります。これは、正しくは、リリース10.1.3.0.0の<data-source>要素のかわりに組み合せて使用する<native-data-source>要素または<managed-data-source>要素のpassword属性です。
『Oracle Containers for J2EEセキュリティ・ガイド』では、OracleAS JAASプロバイダのプロパティx509cert.mapping.attributeについて、誤った記述があります。特に、第13章「Webアプリケーションのセキュリティ構成」の「CLIENT-CERT認証の使用」には、次の間違った例が含まれます。
<orion-application ... >
...
<jazn provider="XML" ... default-realm="myrealm" ... >
<property name="x509cert.mapping.attribute" value="CN"/>
...
</jazn>
...
</orion-application>
この例とその他のx509cert.mapping.attributeに関する記述は間違っています。x509LoginModuleは、他のプロバイダと同様にmapping.attributeプロパティを使用するためです。このプロパティとその構成方法の詳細は、9.1.18項「マッピング属性の指定」のリリース・ノートを参照してください。
『Oracle Containers for J2EEセキュリティ・ガイド』では、少なくとも2つの箇所で、カスタム・セキュリティ・プロバイダ（カスタム・ログイン・モジュール）ではフォーム認証方式がサポートされないと誤って記載されています。これは間違いであり、リリース10.1.3.xの実装では、カスタム・セキュリティ・プロバイダでフォーム認証方式がサポートされます。
間違っている箇所は、次のとおりです。
10.1.3.0.0:
第2章「OC4Jセキュリティの概要」の「OC4J環境での認証」
第13章「Webアプリケーションのセキュリティ構成」の「web.xmlでのauth-methodの指定」
10.1.3.1以上:
第2章「Javaプラットフォームのセキュリティ」の「Webアプリケーションの標準認証方式」
第17章「Webアプリケーションのセキュリティ構成」の「web.xmlでのauth-methodの指定」
この項では、『Oracle Containers for J2EE開発者ガイド』の訂正箇所を示します。内容は次のとおりです。
『Oracle Containers for J2EE開発者ガイド』の第5章「アプリケーションを管理するためのMBeanの作成」の「JMXリモートAPI（JSR-160）を使用するリモート管理」で、コード例に含まれる一部のサービスURL文字列から、必須のコロン文字（:）が欠落しています。間違ったエントリは、次のように記載されています。
String url="service:jmx:rmi///opmn://opmnhost1.company.com:6003/home"
このエントリで、rmiと///の間に「:」が抜けています。
正しいサービスURL文字列は次のとおりです。
String url="service:jmx:rmi:///opmn://opmnhost1.company.com:6003/home"
<client-module>要素の説明では、付録A「OC4J固有のデプロイメント・ディスクリプタ」の「orion-application.xmlファイルの要素」に記載されているuser属性の誤った値が推奨されています。auto-start属性とuser属性の説明では、auto-start='true'の場合、userをtrueに設定するように誤って推奨されています。
ただし、このような属性の設定では、起動時にアプリケーション・クライアント・アーカイブ（CAR）のメイン・メソッドをOC4Jで呼び出せません。auto-start属性をtrueに設定する場合、userをanonymousに設定する必要があります。これらの<client-module>属性の説明は次のようになります。
auto-start: OC4Jサーバーの起動時にアプリケーションのインプロセスを自動的に起動するかどうか。デフォルトはfalseです。この属性をtrueに設定する場合、user属性をanonymousに設定する必要があります。
user: クライアントのインプロセスを実行するには、anonymousに設定します。auto-start属性をtrueに設定する場合、user属性をanonymousに設定する必要があります。
「例: XercesパーサーでのOracle XMLパーサーの置換え」の最後にあるサンプルでは、max-version属性の終わりの引用符が欠落しています。
<import-shared-library name="xerces.xml" max-version="2.5.0/>
サンプルのコード・ラインは次のようになります。
<import-shared-library name="xerces.xml" max-version="2.5.0"/>
この項では、『Oracle Containers for J2EE構成および管理ガイド』の訂正箇所を示します。内容は次のとおりです。
『Oracle Containers for J2EE構成および管理ガイド』の第10章「OC4Jでのロギング」の「テキスト・ファイル・ロギングの有効化または無効化」では、テキスト・ファイル・ロギングを無効化する例として<log>要素全体がコメントアウトされていますが、この例の前の本文では、<file>要素を削除するかコメントアウトするよう記載されています。間違った例は次のとおりです。
<!-- <log> <file path="application.log" /> </log> -->
正しい例は次のとおりです。
<log> <!-- <file path="application.log" /> --> </log>
第6章「admin_client.jarユーティリティの使用方法」のいくつかのコマンド・サブスイッチ名は、間違っています。表9-3に、これらのサブスイッチの間違った名前と正しい名前を示します。また、この表では、ドキュメント内でスペルが間違っていた-addDataSourceConnectionPoolコマンドの正しい名前も示します。
表9-3 admin_client.jarコマンドのサブスイッチの正しい名前
| コマンド | 間違ったサブスイッチ名 | 正しいサブスイッチ名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第6章「admin_client.jarユーティリティの使用方法」の「アーカイブの再デプロイ」にある-redeployコマンド・サブスイッチの説明には、次の情報が欠けています。
-fileサブスイッチでは、EARだけでなく、EAR、WARまたはRARの名前を指定できます。
-bindAllWebApps [webSiteName]サブスイッチが記載されていません。このオプションのサブスイッチでは、指定したWebサイトにすべてのWebモジュールをバインドできます。指定がない場合は、default Webサイトにバインドされます。
オプションで、webSiteNameの値を指定できます。この値は、Webサイトを構成するname_web-site.xmlファイルのname部分に相当します。
$cookie変数と$header変数に関する情報が、第13章「OC4JでのWebサイトの管理」の「テキストベースのアクセス・ロギングの構成」に記載されている<access-log>要素のformat属性の説明から欠落しています。
Webサイトの構成ファイル（*-web-site.xml）の<web-site>要素の<access-log>サブ要素では、ログ・エントリの先頭に情報を追加する複数の変数をformat属性に指定できます。$cookie変数または$header変数を指定する場合、formatは次のようになります。
$cookie:[name] $header:[name]
第10章「タスク・マネージャとスレッド・プールの構成」の表10-2「<thread-pool>および<custom-thread-pool>の属性」のqueue属性の説明に誤りがあります。間違った説明は次のとおりです。
| 属性 | 説明 |
|---|---|
queue |
キューで保持できる最大リクエスト数。デフォルト値は0です。
|
queue属性の正しい説明は次のとおりです。
| 属性 | 説明 |
|---|---|
queue |
キューで保持できる最大リクエスト数。デフォルト値は0です。
|
この項では、『Oracle Containers for J2EEサーブレット開発者ガイド』の訂正箇所を示します。内容は次のとおりです。
orion-web.xmlファイルの<host-access>要素のdomain属性の値には、ホストではなくドメインを指定する必要があります。
『Oracle Containers for J2EEサーブレット開発者ガイド』の付録B「Webモジュールの構成ファイル」の表B-9「<host-access>属性」には、domain属性にホストまたはドメインを指定できると誤って記載されています。
orion-web.xmlファイルの<host-access>要素のdomain属性に指定できるのは、ドメインのみです。
この項では、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』の訂正箇所を示します。内容は次のとおりです。
『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』の第20章「データソースの構成」の「TopLinkOracle JDBCドライバとの関連付け」の「EJB 2.1. CMPアプリケーション」には、boot.xmlファイルでの新しいOracle JDBC共有ライブラリの定義方法が説明されています。ドキュメントに記載されているようにユーザーがboot.xmlファイルを編集することはお薦めしません。これはサポートされていません。
