| Oracle Application Serverリリース・ノート 10g リリース3（10.1.3.1.0）for Linux x86 B31915-06 |
|
 戻る |
 次へ |
この章では、10.1.3.1.0のOracle Containers for J2EE（OC4J）のリリース・ノートについて説明します。内容は次のとおりです。
このドキュメントで言及しているオラクル社のマニュアルには、次のURLからアクセスできます。
http://www.oracle.com/technology/index.html
この項では、Oracle Containers for J2EE（OC4J）の構成、デプロイおよび管理に関する問題について説明します。内容は次のとおりです。
OC4Jの構成の詳細は、次の場所にあるOC4Jのドキュメント『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によるサポートが含まれます。
背景: 『Oracle Containers for J2EE構成および管理ガイド』の10.1.3.1リリースでは、「root設定に「/」を指定すると、OC4JのデフォルトWebアプリケーションが上書きされます。WebアプリケーションをWebサイトにバインドする場合、admin_client.jarユーティリティではこの設定またはNULL設定は許可されません。」と説明しています。
ただし現在では、root設定「/」が許可されています。アプリケーションのデプロイ時にコンテキスト・ルートとしてこれを使用できます。次の例では、WARファイルをデプロイし「/」にバインドするため、admin_client.jarを使用しています。
% 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 "/"
次の例のように、コンテキスト・ルートが「/」に設定されたapplication.xmlファイルがEARファイルに含まれる場合、アプリケーションが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の値に5個を超える要素が含まれている場合、OC4Jは起動しませんでした。）
現在、最大8個の要素で構成されるバージョン番号が許可されています（n1.n2.n3.n4.n5.n6.n7.n8）。
1つの要素の最大許容値は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"));
現在デフォルトでは、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スクリプトは、LINUXでは次のように起動されます。
$ 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パラメータが必要です。
JDK 1.5（10.1.3.x リリースのデフォルトのJDK）を使用する場合は、ヘッドレス・コンソールから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構成および管理ガイド』のバージョン10.1.3.1には、第4章「OC4Jランタイムの構成」、一般的なシステム・プロパティの概要に関する項にjava.awt.headlessシステム・プロパティが説明されています。
10.1.3.xの『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タイマー、タイマー・サービスまたはスケジューラを介してトリガーできます）。この制限は、各タイマーに想定される時間が短いため、デフォルトで低く設定されています）。タイマー数が制限に達した場合、たとえばなんらかの理由でタイマーの実行時間が長くなった場合、タイマーはそれ以上実行されず、新規タイマーが発生したときに警告メッセージが表示されます。この状況で使用できるOC4Jフラグは2つあります。
timer.service.debug: タイマー・サービスの追加診断情報に、現在の作動タイマー数に関する情報も含めて出力するかどうかを決定します。例: -Dtimer.service.debug=true
executor.concurrent.tasks: エグゼキュータ・サービスのコンカレント・タスクの数を指定します。このフラグを介して、OC4Jで使用できるコンカレント・タイマーの最大数を増やすことができます。例: -Dexecutor.concurrent.tasks=12
|
注意: タイマーはそれぞれ別のスレッド内で実行されます。最大値の設定が高すぎると、非常に多くのタイマーが実行され、多数のスレッドが使用されることになります。スレッドの実行が終了した後に、そのスレッドを再利用することをお薦めします。 |
アプリケーションが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プロパティのいずれかを使用して、クラスタ内の異なるOC4Jインスタンス間での再デプロイの間隔（秒数）を指定できます。この遅延により、セッション状態のレプリケーションに十分な時間が与えられます。
オプションのwaitsecまたはsequentialDelay値の導入により、デプロイメント・マネージャは、グループ内の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デプロイメント・ガイド』を参照してください。
このリリース・ノートには、次の例のように、コンカレント・タイマーの数が最大値を超えたときに発生する警告の背景および対処方法が提供されています。
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タイマー、タイマー・サービスまたはスケジューラを介してトリガーできます）。この制限は、各タイマーに想定される時間が短いため、デフォルトで低く設定されています）。タイマー数が制限に達した場合、たとえばなんらかの理由でタイマーの実行時間が長くなった場合、タイマーはそれ以上実行されず、新規タイマーが発生したときに警告メッセージが表示されます。この状況で使用できるOC4Jフラグは2つあります。
timer.service.debug: タイマー・サービスの追加診断情報に、現在の作動タイマー数に関する情報も含めて出力するかどうかを決定します。例: -Dtimer.service.debug=true
executor.concurrent.tasks: エグゼキュータ・サービスのコンカレント・タスクの数を指定します。このフラグを介して、OC4Jで使用できるコンカレント・タイマーの最大数を増やすことができます。例: -Dexecutor.concurrent.tasks=12
|
注意: タイマーはそれぞれ別のスレッド内で実行されます。最大値の設定が高すぎると、非常に多くのタイマーが実行され、多数のスレッドが使用されることになります。スレッドの実行が終了した後に、そのスレッドを再利用することをお薦めします。 |
スケジュール済ジョブのあるアプリケーションを再デプロイすると、スケジュール済ジョブはアプリケーションの再デプロイ後には実行されなくなります。
スケジュール済ジョブのあるアプリケーションを再デプロイする場合は、次の操作を実行してください。
すべてのスケジュール済ジョブの削除
アプリケーションの再デプロイ
すべてのジョブの再発行
Oracle Application Server 10.1.3.xリリースに付属するOracle Notification Service（ONS）は、Database 10.1.0.xリリースに付属するONSバージョンとは互換性がありません。この2つのバージョンで接続が試行されると、次のエラーが表示されます。
invalid connect server IP format ... Terminating connection ...
この非互換性によって、Fast Connection FailoverなどのRAC機能に障害が発生します。対処方法として、Oracle Database Server用の10.1.0.6パッチ・セットをインストールします。このパッチ・セットには更新済のONSが含まれます。このパッチはhttps://metalink.oracle.comからダウンロードできます。
管理対象の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でのアプリケーションのクラスタリング」を参照してください。
OC4J管理クライアント・ユーティリティにより、OC4Jの外部でAnt 1.6.5を使用してAntタスクを組み込むことができます。『Oracle Containers for J2EEデプロイメント・ガイド』の第10章「デプロイに対するOC4J Antタスクの使用方法」では、管理クライアント・ユーティリティを使用せずにOC4Jの外部でAntタスクを組み込む方法について説明しています。次のサイトを参照してください。
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 Technology Networkサイトにある『Oracle Containers for J2EE構成および管理ガイド』の第6章「admin_client.jarユーティリティの使用方法」、リモート管理クライアントのダウンロードおよび抽出に関する項を参照してください。
http://download.oracle.com/docs/cd/B31017_01/web.1013/b28950/adminclient.htm#CHDBEBHD
oc4j_admin_client_ release_number.zipのコンテンツを、選択したローカル・ディレクトリ（oc4j_admin_clientなど）に抽出します。
Oracle Application Server 10gリリース3（10.1.3.1.0）のホーム・ディレクトリにあるORACLE_HOME/ant/lib/ant-oracle.jarファイルを、oc4j_admin_client_ release_numberのコンテンツの抽出先となったローカル・ディレクトリ内のOC4J_ADMIN_CLIENT_DIR¥ant¥libにコピーします。
ORACLE_HOME環境変数をOC4J_ADMIN_CLIENT_DIRディレクトリに設定します。
システムのPATH環境変数にANT_HOME/ant/binを追加します。
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">
OC4J Antタスクは、build.xmlでこのネームスペースを使用して参照されます。
ORACLE_HOME/j2ee/utilitiesディレクトリのant-oracle.propertiesファイルを、ビルド・ファイル（build.xml）があるディレクトリにコピーします。
ORACLE_HOME/j2ee/utilitiesでファイルを変更し、そのファイルをビルド・スクリプトから参照することもできますが、元のファイルはテンプレートとして保存することをお薦めします。
Antタスクに渡す引数の値をant-oracle.propertiesファイルで設定します。
ファイル内のプロパティは、OC4Jのデフォルト値に設定されます。このファイルには、ORACLE_HOMEやJAVA_HOMEなどの環境変数設定も読み込まれています必要に応じて、ターゲットのOC4Jインスタンスの構成を反映するように、これらのプロパティを編集できます。
ORACLE_HOME/j2ee/utilitiesディレクトリのant-oracle.xmlファイルを、ビルド・ファイル（build.xml）があるディレクトリにコピーします。
ビルド・ファイルのトップレベルに、この<import>要素を追加します。
<import file="ant-oracle.xml"/>
X509証明書認証（X509Certificate）では、JAZNにより、Oracle Internet Directory（OID）プロバイダのマッピング属性はデフォルトで"DN"に設定されます。
デフォルト値を変更するために、mapping.attributeプロパティの値を次のように構成できます。
$Oracle_Home/j2ee/<oc4j_inst>/config/jazn.xmlファイルを確認します。
mapping.attributeプロパティ構成を<jazn>タグに追加します。次に例を示します。
<jazn provider... > ... <property name = "mapping.attribute" value="cn"/> ... </jazn>
OC4Jインスタンスを再起動します。
同様に、次のその他のログイン・モジュールも、jazn.xmlファイル内のmapping.attributeプロパティに依存するようになりました。
パスワードを使用しないWS-Securityユーザー名トークン（WSSLoginModule）
SAML（SAMLLoginModule）
SAMLLoginModuleでは、マッピングを確認するためにSubjectNameIdentifierが最初に参照されます。空白の場合、mapping.attributeが使用されます。
X509クライアント証明書認証（X509LoginModule）
サード・パーティのログイン・モジュール（LDAPLoginModule）
これらのログイン・モジュールのマッピング属性は、ここで説明しているように、jazn.xmlファイルで設定する必要があります。
OC4Jインスタンスの作成時に、インスタンス構成を含む新規の<process-type>要素がopmn.xml構成ファイルに追加されます。OC4Jのhomeインスタンスの<process-type>要素は、新規インスタンスのテンプレートとして機能し、homeインスタンスと同じ設定によって作成されます。opmn.xmlファイル内のインスタンスの<process-type>要素のheapsize、numprocs、およびtimeoutなどの設定を変更することにより、新規インスタンスの構成を変更できます。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
OC4J 10.1.3.xリリースでは、Oracle固有のojspタグ・ライブラリが非推奨になりました。これらは、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環境の構成」を参照してください。
ojspcで独自のタグ・ライブラリを使用するには、JSPページを含むWARのWEB-INF/libの下にタグ・ライブラリを置いてアーカイブをプリコンパイルするのが最善の方法です。アーカイブは、スタンドアロンのWARまたはWARを含むEARのいずれかが可能です。
たとえば、mytaglib.warに次のファイルが含まれているものとします。
jsp/mytaglib_example.jspWEB-INF/web.xmlWEB-INF/orion-web.xmlWEB-INF/lib/mytaglib.jarmytaglib.jarファイルには、META-INF/mytaglib.tldおよびそのタグ・ライブラリ・ディスクリプタ（mytaglib.tld）に宣言されているすべてのタグのクラス・ファイルが含まれます。
この例では、WAR（mytaglib.war）はMETA-INF/application.xmlとともにEARファイル内にあります。
次のojspcコマンドはEARファイルをプリコンパイルします。
ojspc -output out/mytaglib.ear mytaglib.ear
プリコンパイル後、EARファイルはout/mytaglib.earに置かれ、WEB-INF/libの下にプリコンパイル済JSPページ、__oracle_jsp_mytaglib_web.jar mytaglib.jarが格納されたWARファイルと、元のmytaglib.jarファイルを含みます。
このEARファイルをOC4にデプロイできます。また、orion-web.xmlデプロイメント・ディスクリプタで、<ojsp-init>属性main-modeを値justrunに設定すると、WEB-INF/lib内のプリコンパイル版が使用されます。 または、$J2EE_HOME/config/global-web-applications.xmlで、OC4Jインスタンスに対するjspサーブレット構成の<init-param>要素のmain_modeパラメータをjustrunに設定することもできます。
この項では、EJBに関するリリース・ノートについて説明します。内容は次のとおりです。
リリース10.1.3.1.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プレビュー・アプリケーションからリリース10.1.3.1のTopLink Essentials JPAへの移行に関する項を参照してください。
ほとんどのEJB 3.0セッションBean機能およびメッセージドリブンBean機能は、JDK 1.4のデプロイメント・ディスクリプタでサポートされています。ただし、JDK 1.4でEJB 3.0インターセプタは使用できません。これは、InvocationContextメソッドgetContextData()でJDK 1.5汎用型が返されるためです。
EJB 3.0仕様には、「Propagation of persistence contexts only applies within a local environment. Persistence contexts are not propagated to remote tiers.（永続性コンテキストの伝播はローカル環境内にのみ適用されます。永続性コンテキストはリモート層に伝播されません。）」という内容が記載されています。
クラスタ化された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 Orion永続性マネージャからOC4J TopLink永続性マネージャへの移行に関する項を参照してください。
このリリースで、orion-ejb-jar.xmlおよびorion-web.xmlでは、ejb-module属性のremoteが非推奨となりました。
クラスタ化されていない独立したWeb層およびEJB層でリモートEJBにアクセスするには、ejb-ref-mapping属性のremote-server-refおよびjndi-properties-fileを使用します。
詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』のリモートEJBへの環境参照の構成: クラスタ化されていない独立したWeb層およびEJB層に関する項を参照してください。
このリリースでは、OC4JでJPA仕様が拡張され、WEB-INF/classes/META-INFまたはWEB-INFでpersistence.xmlがサポートされています。
OC4Jでは、まずWEB-INF/classes/META-INF内が検索されます。この場所でpersistence.xmlファイルが見つかった場合、OC4Jはこのファイルを使用します。この場所でpersistence.xmlファイルが見つからない場合、WEB-INFが検索されます。
JDK 1.5（およびそれ以下）の不具合により、RedHat 4（Linux 2.6）でソケットをIPv6アドレスにバインドできません。
この問題に対処するため、OC4JではIPv4がデフォルトのIPアドレス・スタックとして使用されます。
このデフォルトを上書きするには、システム・プロパティjava.net.preferIPv4Stack=falseを設定します。
このリリースで、OC4Jでは表14-1にリストされたルールに従って静的EJBメソッドにおけるJNDI参照がサポートされています。JNDI参照を使用する静的EJBメソッドを実装する場合は、これらのルールを考慮してください。
表14-1 静的EJBメソッドおよびJNDI参照のルール
| EJB静的メソッドでのJNDI参照 | ルール |
|---|---|
|
完全にデプロイおよび初期化されている別のアプリケーションへの参照 |
サポート |
|
デフォルト・アプリケーションへの参照 |
サポート |
|
不特定のアプリケーションへの参照（デフォルト・アプリケーションに戻る） |
サポート |
|
EJBを所有するアプリケーションへの参照（このアプリケーションがデプロイおよび初期化中である間） |
サポートされていません。この場合、OC4Jで |
|
デプロイおよび初期化中である別のアプリケーションへの参照 |
サポートされていません。この場合、OC4Jで |
このリリースでは、TopLink Essentials JPA永続性プロバイダまたはTopLink CMP永続性マネージャを使用することで、OC4JではBLOB対BLOBおよびCLOB対CLOBマッピングがサポートされています。
OC4JでTopLink CMP永続性マネージャを使用するためにOrion CMPアプリケーションを移行する前に、必ず各エンティティBeanを表に関連付けてください。1つ以上のエンティティBeanが表に関連付けられていない場合、移行に失敗して次のエラー・メッセージが表示されます。
表が指定されていないため、orion-ejb-jar.xmlでエンティティ(<entity bean name>)がマップされていません。完全にマップされたorion-ejb-jar.xmlを移行ツールに指定する必要があります。アプリケーションのデプロイ後に、完全にマップされたorion-ejb-jar.xmlを/application-deploymentディレクトリから取得できます。
data-sources.xmlでOC4J管理データソースを構成する場合、Oracle JMS Connector（OJMS）で管理データソースを使用するには、manage-local-transactions属性をfalseに設定する必要があります。これはキューおよびトピックの両方の場合に適用されます。
グローバル・トランザクションに接続が関与できるかどうかを決定する際に管理データソースで使用されるデフォルトのアルゴリズムは、OJMSの使用時は不適切であり、MDBのグローバル・トランザクションへの関与を不正に妨げる可能性があります。
この属性がfalseに設定されている場合、OJMSおよび基礎となるデータベース管理システムが接続の実際のトランザクション・ステータスを正しく決定できます。
以前のリリースでは、Orion CMPの使用時に双方向、1対多、または多対多の関連の多の側にEJBを追加すると、OC4Jは、多の側の関連のすべてのメンバーをデータベースからロードしていました。これにより、パフォーマンスの問題が起きる場合がありました。
このリリースでは、OC4Jはこのような動作をしなくなりました。
この項では、Webサービスに関するリリース・ノートについて説明します。内容は次のとおりです。
この項では、構成に誤りがある場合に発生する可能性のある問題について説明します。
WSILアプリケーション・コンポーネントのインストールに使用するAntスクリプトは、特定の外部構成オプションの影響を受けます。Antが正しく構成されていない場合、WSILのインストールがNoClassDefFoundエラーで失敗する可能性があります。
Antを使用したWSILアプリケーションのデプロイ時に、OracleAS Web Services 10gで提供されているAntディストリビューションを使用しているか、確認する必要があります。このリリースには、デプロイに必要なすべてのAntタスクが含まれています。
OracleAS Web Services 10gで提供されているAntディストリビューションの内容および機能の詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。
この項では、WebServicesAssemblerの操作で発生する可能性のある問題について説明します。
第14.5.2.3項「WebServicesAssemblerでは、WSDL内のスキーマ・インポートにschemaLocation属性による修飾が必要」
第14.5.2.4項「JavaファイルにJ2SE 5.0 Annotationsが含まれる場合にassemble Antタスクで例外が発生」
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"/>
assemble Antタスクを使用して、J2SE Annotationsが含まれるJavaファイルからWebサービスを生成すると、例外が発生します。assemble Antタスクでは、注釈付きJavaファイルを正しく処理できません。
この例外を避けるには、コマンドラインでassembleを使用します。
この項では、OracleAS Web ServicesによるWSDLファイルの解釈方法で発生する可能性のある問題を説明します。
WSDL内の名前（サービス名、ポート・タイプ名、操作名、バインディング名、ポート名など）にグローバリゼーション・サポート（NLSまたは各国語サポートとも呼ばれる）文字が含まれていても、サポートされません。これを使用すると、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をコーディングします。
XMLデータ型anyURIは、WSIF（Web Service Invocation Framework）を使用するアプリケーションではサポートされません。Oracle WebサービスによりWSIFでanyURIデータ型が検出されると、次のようなエラーが返されます。
org.apache.wsif.WSIFException: Method retUri(class java.net.URI) was not found in portType.
この制限に対処するには、xsd:anyURIのかわりにxsd:stringデータ型を使用します。
この項では、Webサービスのテスト・ページに関する問題を説明します。内容は次のとおりです。
第14.5.5.2項「Webサービスのテスト・ページでのサービス起動により返されたフォーマット済XMLコンテンツが正しく表示されない」
第14.5.5.4項「Webサービスのテスト・ページ・フォーム・フィールドの無効な値が原因で「saveChangesでヘッダー・ストリームを取得できません」エラーが発生する」
第14.5.5.5項「Webサービスのテスト・ページでユーザー名またはパスワードのグローバリゼーション・サポート（NLS）文字がサポートされない」
第14.5.5.6項「Webサービスのテスト・ページで、スキーマ機能group、choice、union、または属性として導出された単純タイプがサポートされない」
第14.5.5.7項「テスト・ページ・ストレス・テスト・レポートがFirefoxまたはMozillaで正しく表示されない」
再帰的スキーマ定義を使用するサービスは、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サービスのテスト・ページで無効な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の操作中に発生する可能性のある問題について説明します。
第14.5.7.1項「getChildNodeのかわりにgetFirstChildとgetNextSiblingを使用したNodeListの取得」
第14.5.7.6項「XMLのシリアライズでdocument-literal-bareメッセージ書式にJavaデータ型arrayを使用できない」
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属性を使用してハンドラ・クラス名を指定できます。ただし、handlerClassを使用してJDeveloperでクラス名を指定する場合、エディタには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クライアントが、複雑なタイプのSOAPエンコード配列が含まれるOracleAS Web Servicesからのレスポンスを受け取った場合、クライアントは次のようなエラーをスローします。
internal error: no builtin runtime type for com.bea.staxb.buildtime.internal.bts.BuiltinBindingType
BEAと@ AXIS、IBMまたは.NETのうち1つ以上のプラットフォームの相互運用が必要である場合、soapenc配列は使用しないでください。
xs:integer制約付きのsimpleTypeタイプの要素を定義すると、OC4J、AXISおよびBEAなどすべてのJavaプラットフォームの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）で、xs:integer制限付きsimpleType要素は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サービスのJAX-RPCスタックでは、ほとんどの制約は規定されません。この問題に対処するには、生成されるBeanクラスを使用するかわりに独自のBeanクラスを記述します。
array Javaデータ型を使用するJavaメソッドを、document-literal-bare（ラップなし）メッセージ書式を使用するWebサービスとして公開しようとすると、メソッドのシリアライズに失敗します。
たとえば、次の定義を持つメソッド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であると想定しています。
このリリースでは、次のInitialContextファクトリは、非推奨となりました。
com.evermind.server.RMIInitialContextFactory
com.evermind.server.ApplicationClientInitialContextFactory
com.oracle.iiop.server.IIOPInitialContextFactory
初期コンテキスト・ファクトリの新しいパッケージ名は、次のとおりです。
oracle.j2ee.rmi.RMIInitialContextFactory
oracle.j2ee.naming.ApplicationClientInitialContextFactory
oracle.j2ee.iiop.IIOPInitialContextFactory
このリリースでは、JNDI環境変数dedicated.connection、dedicated.rmicontextおよびLoadBalanceOnLookupは、非推奨となりました。
レプリケーションに基づくロード・バランシングを構成する場合は、表14-2の設定を指定して、環境変数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」の章にある異常終了に関する項を参照してください。
このリリースの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コンソールの使用）にかかわらず、変更を有効にするにはサーバーを再起動する必要があります。
キュー表が旧互換性モードを使用するように構成されていると、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 Remote Method Invocation（RMIおよびIIOP）に関するリリース・ノートについて説明します。内容は次のとおりです。
このリリースでは、次の推奨事項に注意してください。
プロバイダのURL形式に誤りがある場合、次のエラー・メッセージが表示されます。
" Provider URL must be of the form [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サービス・ガイド』の「XML Query Service」の章には誤りがあります。「入力パラメータのタイプ・チェック」の項の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サービス・ガイド』の「XML Query Service」の章には誤りがあります。「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の内部リソース・アダプタであり、その管理タスクではデプロイおよび再デプロイに追加の操作が必要になる場合があります。
リリース10.1.3.1または10.1.3.2でOracleAS JAAS Providerを使用する場合は、次の注意事項に留意してください。
第14.8.4項「ユーザーおよびロールAPIによるOracleAS JAAS ProviderレルムAPI機能の置換え」
第14.8.5項「移行ツールの問題: カスタム・プリンシパルに対するOracle Internet Directoryレルム名のプリペンド」
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]
（この構文は、項の最後の例で正確に表示されています。）
JAAS認可を外部LDAPプロバイダととともに使用している場合、このリリース・ノートが提供する詳細によって、10.1.3.1リリースの『Oracle Containers for J2EEセキュリティ・ガイド』の第10章「外部LDAPセキュリティ・プロバイダ」、外部LDAPプリンシパルへの追加権限の付与に関する項に記載されたごく短い説明が完全な形になります。
JAZNMigrationToolは、通常はファイルベース・プロバイダから代替ファイルベース・プロバイダまたはOracle Internet Directoryへの移行に使用されますが、外部LDAPプロバイダとともに使用して、JAASポリシー情報をターゲット・サーバー上のsystem-jazn-data.xmlファイルに移行することもできます。
外部LDAPプロバイダのLDAPプリンシパルに必要な権限を付与するには、次の手順を実行します。
「-m policy」設定を使用して、開発サーバー上のsystem-jazn-data.xmlからターゲット・サーバー上のsystem-jazn-data.xmlにJAASポリシー情報を移行します。これは、ポリシー情報のみを（ターゲットのsystem-jazn-data.xmlファイルに）移行するためのものであり、JAZNMigrationToolを使用して、ユーザーおよびロール情報を外部LDAPプロバイダに直接移行することはできません。（より正確に言えば、JAZNMigrationToolでは外部LDAPプロバイダに適したLDIFファイルを作成できません。Oracle Internet Directoryで必要となるディレクトリ情報ツリーおよびスキーマを使用して、Oracle Internet Directoryのみに適したLDIFファイルを作成できます。）
移行済のポリシー情報を手動で編集し、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でターゲット・サーバーに移行したポリシー構成で参照されているプリンシパルに準拠していることを確認します。
10.1.3.1リリースの『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とします。 |
10.1.3.1リリースの『Oracle Containers for J2EEセキュリティ・ガイド』の新規トピックに関する項では、新規ユーザー/ロールAPIフレームワークに、com.evermind.securityパッケージ内の非推奨となったUserManager、UserおよびGroupクラスに対する置換機能が含まれると記載されています。
ユーザー/ロールAPIフレームワークには、oracle.security.jaznパッケージ内またはその下のレルムAPIに対する置換機能が含まれる点も記載されている必要があります。
これらのパッケージは非推奨となっており、11g リリースではサポートされません。
OracleAS JAAS Provider移行ツールを使用してファイルベース・プロバイダからOracle Identity Management（Oracle Internet Directory）セキュリティ・プロバイダにポリシー・モードまたは全モードのいずれかでポリシーを移行する際、移行ツールがOracle Internet Directoryのレルム名をポリシー構成の権限受領者エントリにあるカスタムまたは非レルムのプリンシパル名にプリペンドするという問題に注意してください（カスタム・プリンシパルは、カスタム・ログイン・モジュールを介した認証時などに使用される場合があります）。
たとえば移行後の構成で、権限受領者のカスタム・プリンシパル名は単なる"anyone"のかわりに"us/anyone"のようになります。ここで"us"はレルム名とします。この結果、権限上の問題が発生します。たとえばADFアプリケーションの場合、パブリック・ページがOracle Internet Directoryへの移行後にセキュリティ・プロバイダとして機能しないという問題が発生します。
この問題は、10.1.3.3のリリースで修正されます。10.1.3.2および10.1.3.xまでのリリースでは、次の対処方法のいずれかを使用できます。
移行ツールが作成するLDIFファイルをOracle Internet Directoryにインポートする前に、"us/"プレフィクスを手動で削除します。
移行後に、関連する権限受領者から"us/"プレフィクスをOracle Internet Directory管理ツールを使用して手動で削除します。
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>
OC4JでAJP13プロトコルを使用してサイトを実行しており、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サーブレット開発者ガイド』に記載されています。
DCMコンポーネントは、Oracle Application Server 10.1.3でサポートされなくなりました。その結果、-clustersupportオプションはjazn.jar管理ツールで使用できなくなりました。
問題
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オプションを使用しないでください。
この項では、OC4Jの一般的な問題について説明します。
スタンドアロンOC4JインスタンスをApplication Server Controlを使用して複数回再起動すると、java.lang.OutOfMemoryErrorエラーがサーバー・コンソールに表示され、OC4Jインスタンスが使用できなくなります。
回避するには、手動でOC4Jインスタンスを停止して再起動します。
この項では、Oracle Application Server 10gリリース3（10.1.3.1）のOC4Jドキュメントにおける既知の誤りについて説明します。内容は次のとおりです。
この項では、Web Servicesドキュメントの記載内容の誤りについて説明します。内容は次のとおりです。
第14.10.1.2項「『Oracle Application Server Web Servicesアドバンスト開発者ガイド』のXMLタイプ名の誤字」
第14.10.1.3項「ServerConstantsプロパティはクライアントからHTTPレイヤーへのアクセスには使用できない」
『Oracle Application Server Web Services開発者ガイド』の第4章および付録Aでは、wsclient_extended.zipファイルおよびCompanion CDに関する次の誤ったリンクが使用されています。
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コレクション・クラスのXMLタイプへのマップでは、XMLタイプ名に次の入力ミスが含まれます。
--java.util.HashMapはowi:hashmapにマップされます。これは誤りです。正しいマッピングはowi:hashMapです（Mが大文字である必要があります）。
--java.util.TreeMapはowi:treemapにマップされます。これは誤りです。正しいマッピングはowi:treeMapです（Mが大文字である必要があります）。
『Web Services開発者ガイド』のスタブ・クライアントがServiceLifecycleインタフェースを使用してヘッダーを取得する方法に関する項に、oracle.webservices.ServerConstantsクラスのHTTP_SERVLET_REQUESTおよびHTTP_SERVLET_RESPONSEプロパティを使用してHTTPメッセージ・ヘッダーにアクセスする方法が説明されています。
この項では、サーバー上と同様にクライアントでもHTTPメッセージ・ヘッダーへのアクセスにこれらのプロパティを使用できると説明されています。これは誤りです。クライアントは、これらのプロパティを使用してHTTPレイヤーにアクセスできません。これらのプロパティをクライアント上でコールしようとすると、次のような例外が返されます。
--java.util.TreeMapはowi:treemapにマップされます。これは誤りです。正しいマッピングはowi:treeMapです（Mが大文字である必要があります）。
javax.xml.rpc.JAXRPCException: Stub does not recognize property:...
対処方法はありません。
マニュアル: 『Oracle Application Server Web Servicesアドバンスト開発者ガイド』
第3章には、Oracle Web Servicesがサポートされているプラットフォームが記載されています。このリストにHP-UXおよびAIXプラットフォームを追加する必要があります。
Oracle Web Servicesスタックは、Oracle Application ServerおよびOC4Jと同じプラットフォーム上でサポートされています。各リリースのサポート対象プラットフォームの最新リストは、Webサイトhttp://metalink.oracle.comで確認してください。
この項では、『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デプロイメント・ディスクリプタ内のプロバイダ要素」は、整形式ですが無効なXMLです。
JDeveloper 10.1.3.3.0.4157のスキーマ検証では、descriptionおよびdisplay-name要素が順不同であり、誤った位置に配置されています。
変更前:
<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 Servicesドキュメントの記載内容の誤りについて説明します。内容は次のとおりです。
第14.10.3.3項「admin_client.jar -redeployコマンドのサブスイッチに関する説明からの情報の欠落」
第14.10.3.5項「removeSharedLibrary AntタスクのversionプロパティはlibraryVersionにする必要がある」
第14.10.3.8項「Application Server ControlではEJBモジュールの増分再デプロイがサポートされない」
第10章「デプロイに対するOC4J Antタスクの使用方法」の「データソース接続プールのテスト」の項にあるtestDataSourceConnectionPool Antタスクの例の"name"属性は"connectionPoolName"である必要があります。この例は『Oracle Containers for J2EEデプロイメント・ガイド』のバージョン10.1.3.1にあります。
正しい例を次に示します。
<oracle:testDataSourceConnectionPool deployerUri="deployer:oc4j:localhost" userid="oc4jadmin" password="welcome1" applicationName="default" connectionPoolName="ScottConnectionPool" sqlStatement="select * from dual" />
第11章「デプロイに対するadmin_client.jarユーティリティの使用方法」で、一部のコマンド・サブスイッチの名前が誤っています。表14-3に、それらのサブスイッチの誤った名前と正しい名前を示します。また、-addDataSourceConnectionPoolコマンドの正しい名前もこの表に示します。マニュアルではこのコマンド名のスペルが誤っています。
表14-3 admin_client.jarコマンドのサブスイッチの正しい名前
| コマンド | 誤ったサブスイッチ名 | 正しいサブスイッチ名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第11章「デプロイに対するadmin_client.jarユーティリティの使用方法」の「アーカイブの再デプロイ」の項で、-redeployコマンドのサブスイッチに関する説明から一部の情報が欠落しています。
-fileサブスイッチでは、EARだけでなく、EAR、WARまたはRARの名前を指定できます。
-bindAllWebApps [webSiteName]サブスイッチが欠落しています。このオプションのサブスイッチを使用すると、すべてのWebモジュールが、指定されたWebサイトにバインドされるか、Webサイトが指定されていない場合はdefault Webサイトにバインドされます。
オプションで、webSiteNameの値を指定できます。これは、Webサイトを構成するname_web-site.xmlファイルのname部分です。
『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ファイルは、そのタイムスタンプがファイルを含むディレクトリのタイムスタンプより新しい場合にもデプロイされます。
第10章「デプロイへのOC4J Antタスクの使用」の表10-7「スタンドアロンWARデプロイのdeployプロパティ」には、deploymentPlanプロパティが誤って記載されています。スタンドアロンWebモジュールのデプロイにはデプロイメント計画を使用できません。
第3章「EJBモジュールのデプロイ」の「EJBモジュールの増分再デプロイ」には、Application Server Controlコンソールがツールとして誤って記載されています。Application Server Controlは、EJBモジュールの増分再デプロイには使用できません。かわりに他のいずれかのツールを使用する必要があります。
admin_client.jarコマンドライン・ユーティリティ（スタンドアロンOC4Jの場合はadmin.jar）の-updateEBJModuleコマンド
updateEJBModule Antタスク
JDeveloper
EJBの再デプロイの詳細は、第3章を参照してください。
この項では、『Oracle Containers for J2EE構成および管理ガイド』の記載内容の誤りについて説明します。内容は次のとおりです。
第6章「admin_client.jarユーティリティの使用方法」で、一部のコマンド・サブスイッチの名前が誤っています。表14-4に、それらのサブスイッチの誤った名前と正しい名前を示します。また、-addDataSourceConnectionPoolコマンドの正しい名前もこの表に示します。マニュアルではこのコマンド名のスペルが誤っています。
表14-4 admin_client.jarコマンドのサブスイッチの正しい名前
| コマンド | 誤ったサブスイッチ名 | 正しいサブスイッチ名 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
第6章「admin_client.jarユーティリティの使用方法」の「アーカイブの再デプロイ」の項で、-redeployコマンドのサブスイッチに関する説明から一部の情報が欠落しています。
-fileサブスイッチでは、EARだけでなく、EAR、WARまたはRARの名前を指定できます。
-bindAllWebApps [webSiteName]サブスイッチが欠落しています。このオプションのサブスイッチを使用すると、すべてのWebモジュールが、指定されたWebサイトにバインドされるか、Webサイトが指定されていない場合はdefault Webサイトにバインドされます。
オプションで、webSiteNameの値を指定できます。これは、Webサイトを構成するname_web-site.xmlファイルのname部分です。
『Oracle Containers for J2EE構成および管理ガイド』の第11章「OC4Jでのロギング」、「テキスト・ファイル・ロギングの有効化または無効化」の項にあるテキスト・ファイル・ロギングの無効化の例では、<log>要素全体をコメントアウトしていますが、例の直前のテキストでは、<file>要素を削除またはコメントアウトすると説明しています。例は、次のように誤って記述されています。
<!-- <log> <file path="application.log" /> </log> -->
正しい例は、次のとおりです。
<log> <!-- <file path="application.log" /> --> </log>
第13章「OC4JでのWebサイトの管理」の「テキストベース・アクセス・ロギングの構成」で、<access-log>要素のformat属性の説明から$cookieおよび$header変数に関する情報が欠落しています。
Webサイトの構成ファイル（*-web-site.xml）にある<web-site>要素の下位要素<access-log>では、情報をログ・エントリに追加させるformat属性で変数の数を指定できます。$cookieまたは$header変数を指定する場合は、次の書式を使用する必要があります。
$cookie:[name] $header:[name]
第10章「タスク・マネージャとスレッド・プールの構成」の表10-2「<thread-pool>および<custom-thread-pool>の属性」で、queue属性の説明に誤りがあります。説明は、次のように誤って記述されています。
| 属性 | 説明 |
|---|---|
queue |
キューに保持できる最大リクエスト数。デフォルト値は0です。
|
queue属性に関する訂正後の説明は次のとおりです。
| 属性 | 説明 |
|---|---|
queue |
キューに保持できる最大リクエスト数。デフォルト値は0です。
|
『Oracle Containers for J2EE構成および管理ガイド』の第8章「クラスタおよびOC4Jグループの構成と管理」、「トポロジ間ゲートウェイの構成」の項にあるopmn.xmlの構成例で<topology>サブ要素の順序が誤って記載されています。 例には、ゲートウェイの構成が次のように示されています。
<opmn> <notification-server> <port ... /> <ssl ... /> <topology> <gateway list="node1.com:6201&node2.com:6202&node3.com:6203/"/> <discover list="*224.0.0.37:8205"/> </topology> </notification-server> ... </opmn>
<topology>サブ要素はopmn.xsdファイルに従って誤って順序付けられるため、この構成を使用するとOPMNエラーになります。
正しい構成は次のとおりです。
<opmn> <notification-server> <port ... /> <ssl ... /> <topology> <discover list="*224.0.0.37:8205"/> <gateway list="node1.com:6201&node2.com:6202&node3.com:6203/"/> </topology> </notification-server> ... </opmn>
次の段落は、『Oracle Containers for J2EE構成および管理ガイド』の第9章「OC4Jでのアプリケーションのクラスタリング」、「静的peer-to-peerレプリケーションの構成」の項にある誤った起動順序を示しています。
この構成では、各ノードはもう1つのノードをそのピアとして指定しています。 その結果、クラスタ内のすべてのノードは相互に接続を確立できます。 この例は、各ノードが連続して起動された場合にのみ機能します。つまり、www1.company.comはwww2.company.comより前に起動する必要があります。 起動しないと、www2.company.comはwww1.company.comを認識できません。
次の段落は、正しい起動順序です。
この構成では、各ノードはもう1つのノードをそのピアとして指定しています。 その結果、クラスタ内のすべてのノードは相互に接続を確立できます。 この例は、各ノードが連続して起動された場合にのみ機能します。つまり、www3.company.comはwww2.company.comより前に起動する必要があります。 起動しないと、www2.company.comはwww3.company.comを認識できません。
この項では、『Oracle Containers for J2EEサービス・ガイド』の記載内容の誤りについて説明します。内容は次のとおりです。
『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の暗黙接続キャッシュ（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セキュリティ・ガイド』では、「orion-application.xmlで構成されたプロバイダが認証に使用されるIDストアになり、jazn.xmlで指定されたプロバイダが認可に使用されるポリシー・ストアになるという混在した状態になります。この構成はお薦めしません」という記述を含む注意書きが2つあります。
1つは「OC4Jでの認可」の章（第5章）にある「jazn.xmlでのポリシー・リポジトリ設定」の項に記載され、もう1つは「Oracle Identity Management」の章（第8章）にある「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属性に言及している一節があります。これは実際には、<native-data-source>要素または<managed-data-source>要素のpassword属性を指します。これらの組合せで10.1.3.0.0リリースの<data-source>要素が置き換えられます。
『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セキュリティ・ガイド』では、OracleAS JAAS Providerのプロパティ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>
x509LoginModuleでは他のプロバイダと同様mapping.attributeプロパティが使用されるため、この例およびその他のx509cert.mapping.attributeに関する説明は誤っています。 このプロパティおよびその構成方法の詳細は、第14.1.20項「マッピング属性の指定」のリリース・ノートを参照してください。
この項では、『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"
付録A「OC4J固有のデプロイメント・ディスクリプタ」の「orion-application.xmlファイルの要素」では、<client-module>要素の説明でuser属性について誤った値が推奨されています。auto-startおよびuser属性の説明では、auto-start='true'のときにuserをtrueに設定するように誤って推奨されています。
ただし、これらの属性設定を使用すると、OC4Jは起動時にアプリケーション・クライアント・アーカイブ（CAR）内のメイン・メソッドをコールしなくなります。auto-start属性がtrueに設定されている場合は、userをanonymousに設定する必要があります。これらの<client-module>属性の説明は、次のように訂正する必要があります。
auto-start: OC4Jサーバーの起動時にプロセス内でアプリケーションを自動的に起動するかどうか。デフォルトはfalseです。この属性がtrueに設定されている場合は、user属性をanonymousに設定する必要があります。
user: プロセス内でクライアントを実行するには、anonymousに設定します。auto-start属性がtrueに設定されている場合は、user属性をanonymousに設定する必要があります。
この項では、『Oracle Containers for J2EEサーブレット開発者ガイド』の記載内容の誤りについて説明します。次の項目が含まれます。
orion-web.xmlファイルの<host-access>要素のdomain属性に指定する値は、ホストではなくドメインにしてください。
『Oracle Containers for J2EEサーブレット開発者ガイド10g（10.1.3.1.0）』の「付録B Webモジュールの構成ファイル」の表B-9「<host-access>属性」に、domain属性に対してホストまたはドメインを指定できるという誤った説明があります。
orion-web.xmlファイルの<host-access>要素のdomain属性に指定できるのはドメインのみです。
