| Oracle Application Server Standard Edition Oneリリース・ノート 10g リリース2（10.1.2）for Microsoft Windows（32 Bit） B19168-03 |
|
 戻る |
 次へ |
| Oracle Application Server Standard Edition Oneリリース・ノート 10g リリース2（10.1.2）for Microsoft Windows（32 Bit） B19168-03 |
|
| 戻る |
次へ |
この章では、Oracle Containers for J2EE（OC4J）に関するリリース・ノートについて説明します。 この章の内容は次のとおりです。
この項では、OC4Jの構成に関する問題とその対処方法について説明します。
この項の内容は次のとおりです。
OC4Jの構成方法は、『Oracle Containers for J2EE Configuration and Administration Guide』を参照してください。
クライアント・ライブラリの互換性の制約により、任意のOracle JDBC-OCIドライバ・バージョンにアップグレードすることはできません。Oracleクライアント・ライブラリに対応するOCIドライバ・バージョンへのアップグレードのみがサポートされています。このライブラリは、Oracle Application Server 10g（10.1.2）にインストールされています。たとえば、Oracle JDBC 9.0.1.4.0と9.0.1.5.0はサポートされていますが、Oracle JDBC 9.2.xドライバはサポートされていません。
Oracle Application Server内でJDBC-OCIを使用できる場合、各OC4Jインスタンスのopmn.xmlエントリが適切なORACLE_HOME とライブラリ・パスの値をその起動環境に伝播することも必要になります。
環境変数ORACLE_HOMEはすべてのプラットフォームに共通ですが、ライブラリ・パスを指定する環境変数の名前はオペレーティング・システムによって異なります。Windowsの場合はPATHです。
ライブラリ・パスをopmn.xmlで指定する一般的な構文は次のとおりです。
<prop name="<LIB_PATH_VARIABLE>" value="<LIB_PATH_VARIABLE_VALUE>"/>
<LIB_PATH_VARIABLE>は、ライブラリ・パスを指定するプラットフォーム固有の適切な変数名と置き換えてください。さらに、
<LIB_PATH_VARIABLE_VALUE>
は、その変数の値と置き換えてください。
デプロイするアプリケーションに対してOC4JのデフォルトのJVMヒープ・サイズが小さすぎる場合、OC4Jプロセスでメモリー不足エラーが発生することがあります。ディレクトリ%ORACLE_HOME%\opmn\logsにあるOC4Jインスタンスのログ・ファイルを確認すると、次のようなエラーが含まれる場合があります。
java.lang.OutOfMemoryError
この問題を回避するには、OC4JインスタンスのJavaコマンドライン・オプションを変更し、指定されているヒープ・メモリーを増やします。
Application Server Control Consoleを使用して、OC4Jインスタンスのホームページを開き、次の手順を実行します。
OC4Jインスタンスを停止します。
「サーバー・プロパティ」ページにドリルダウンします。
「サーバー・プロパティ」ページの「コマンドライン・オプション」で、ヘッダー「複数仮想マシン構成」の下の「Javaオプション」を設定します。
たとえば、JVMヒープ・サイズを512MBに設定するには、次のとおり入力します。
-Xmx512m
「適用」ボタンを使用して変更を適用します。
OC4Jインスタンスを起動します。
詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。
OC4J 10.1.2実装では、WebサイトのXMLファイルに新しい機能が追加されました。この機能によって、OC4Jアクセス・ロギング（Webサイトへのリクエストのログに使用）がモジュールごとに無効になります。
通常、テキスト・ベースのアクセス・ロギングは、WebサイトのXMLファイル（default-web-site.xmlまたはhttp-web-site.xmlなど）の<web-site>要素の<access-log>下位要素によって、Webサイトで有効になります。また、Oracle Diagnostic Logging（ODLベースのアクセス・ロギング）は、<web-site>要素の<odl-access-log>下位要素によって、Webサイトで有効になります。
リリース10.1.2では、Webアプリケーションの<web-app>要素の新しいaccess-log属性によって、テキスト・ベースのロギングまたはODLベースのロギング（必要に応じて）を特定のWebアプリケーション（モジュール）に対して無効にできます。<web-app>要素は、<web-site>の別の下位要素です。Webアプリケーションにaccess-log="false"を設定すると、<access-log>または<odl-access-log>要素が上書きされ、そのWebアプリケーションの操作中はロギングが無効になります。
次に、admin_webモジュールに対するテキスト・ベースのロギングを有効にしたまま、デフォルトのアプリケーションのdms0モジュールに対するロギングを無効にする例を示します。
<web-site ... > ... <web-app application="default" name="dms0" root="/dms0" access-log="false" /> <web-app application="default" name="admin_web" root="/adminoc4j" /> <access-log path="../log/http-web-access.log" /> ... </web-site>
|
注意: デフォルトの設定は、access-log="true"です。この設定によって、機能は以前のリリースと同じになり、<access-log>または<odl-access-log>要素の有無によってのみロギングの有効/無効が決定されます。WebサイトのXMLファイルに<access-log>または<odl-access-log>要素がない場合、ロギングは無効となり、アプリケーションに対するaccess-log="false"は機能しません。 |
アクセス・ロギングの関連情報については、リリース10.1.2の『Oracle Containers for J2EE Developer's Guide』を参照してください。
この項では、サーブレットに関する問題について説明します。 この項の内容は次のとおりです。
10.1.2実装では、サーブレットの次の問題が解決されました。
Bug#3861451: "jsp"がMIMEタイプ・リストに追加されるときに、JSPリソースの接尾辞が大/小文字を区別して処理されない。この問題は、すべての接頭辞が大/小文字を区別して処理されるよう修正されました。
Bug#3860075: フィルタの再コンパイル時またはソース・ファイルのタイムスタンプの更新時にJAZNFilter.getFilterProperty()メソッドでNullPointerExceptionがスローされる。
Bug#3696009: OC4JがWebキャッシュの背後で設定されていても、アプリケーションがOC4Jに直接アクセスする（Webキャッシュをバイパスする）と、getRequestURL()メソッドはOC4Jのホストとポートではなく、Webキャッシュのホストとポートを返す。
Bug#3287183: StrutsアプリケーションはOC4Jの停止時に例外をスローする。
Bug#3050265: サーブレットをクラス名によって起動するサーブレット起動機能がOC4Jのデフォルト構成で使用可能なため、予期せぬセキュリティ・ホールが発生する可能性がある。この機能はデフォルトでは使用できなくなりました。開発モードでのみ使用してください。
この項では、EJBに関する問題について説明します。 この項の内容は次のとおりです。
『Oracle Application Server Containers for J2EE Enterprise JavaBeans開発者ガイド』の修正版が発行されました。
リリース9.0.4.1と10.1.2では、次のorion-ejb-jar.xml属性が廃止されました。
max-instances-per-pk
min-instances-per-pk
disable-wrapper-cache
また、次のlocking-mode属性設定も廃止されました。
locking-mode="old_pessimistic"
多数のEJBを含むEARファイルをデプロイすると、OutOfMemory例外が発生します。
デプロイ・プロセスでは、各EJBに対してラッパー・コード・クラスが生成されます。これらのクラスのサイズは、Bean上のビジネス・メソッドの数に比例します。パフォーマンスを最適化するために、OC4Jはすべてのラッパー・コード・クラスを1回のコンパイラ起動でコンパイルします。生成されるラッパー・コードの数が使用可能メモリーに対して多すぎる場合、エラーが発生することがあります。
これを回避するには、デプロイ・プロセスで、各EJBモジュールのラッパー・コードを個別にコンパイルします。これには、ejbdeploy.batchシステム・プロパティをfalseに設定して、OC4Jを起動します。
-Dejbdeploy.batch=false
|
注意: この対処方法は、この例外が発生した場合にのみ使用してください。これにより、アプリケーションのデプロイ時間が長くなる場合があります。 |
zh_CN.GB18030ロケールで実行すると、EJBラッパー・コードのコンパイル・エラーが発生します。zh_CN.GB18030ロケールで実行すると、一部のEJBラッパー・ソース・コードの生成で文字が欠落する場合があります。この結果、コンパイル・エラーが発生します。生成されるソース・コードで文字が欠落するのは、次のサイトに記載されているSun社のバグが原因です。
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4954023
これを回避するには、別のロケールを使用します。詳細は、Sun社のバグの説明を参照してください。
この項では、OC4Jサービスに関する問題について説明します。OC4Jサービスには、Java Naming and Directory Interface（JNDI）、Java Message Service（JMS）、Data Source、Oracle Remote Method Invocation（ORMI）、J2EE Interoperability（IIOP）、Java Transaction API（JTA）、J2EE Connector Architecture（J2CA）およびJava Object Cacheが含まれています。
この項の内容は次のとおりです。
OC4Jは、IPv4ソケットのみを作成します。デュアル・ネットワーク・スタック・マシン（IPv4とIPv6の両方のスタックが使用可能なマシン）上でも、OC4JはIPv4ソケットのみを作成します。このため、クライアントが発行したリクエストがIPv6システムからである場合、問題が発生することがあります。これは、サーバーからIPv6クライアントへの接続拒否メッセージによって示されます。この問題を回避するには、システム・プロパティjava.net.preferIPv4Stack=trueを使用してクライアント・プロセスを起動します。これにより、クライアントが発行するのはIPv4リクエストのみとなり、サーバーとの通信が可能になります。
ORMIプロトコルはセキュアでないことに注意してください。ORMIを介した通信は、セキュリティ資格証明を含めて暗号化されません。ORMIトラフィックの暗号化が必要な場合は、ORMIをHTTPSで使用することをお薦めします。HTTPSでは、クライアントとサーバー間のすべての通信が暗号化されます。
このチュートリアルでは、IIOPアプリケーションをOC4Jで有効にする手順を説明します。このチュートリアルを終了した後は、次のことが可能になります。
IIOPを介したリモートEJBへのアクセス
SSLを介するIIOPを使用したEJBのセキュアな起動
SSLを介するIIOPを使用したリモート・クライアントによるセキュアなcorbaname参照
このチュートリアルでは、デプロイと構成の変更を最小限に抑えるために、「helloworld」というEJBデモ・アプリケーションを使用します。このアプリケーションは、インストールされたOC4JとOTNサイトで入手可能です。
http://www.oracle.com/technology/sample_code/tech/java/ejb_corba/index.html
デフォルトのOC4Jインストールを使用してhelloworldアプリケーションを構築およびデプロイすると、アプリケーションへはORMIを介してのみアクセス可能になります。任意のアプリケーションに対してIIOPを有効にするには、OC4Jのサーバー構成とクライアント・アプリケーションに変更を加える必要があります。必要な変更は次のとおりです。
IIOPServerExtensionProviderの構成
java.naming.provider.urlの変更
-iiopClientJar引数を使用したアプリケーションのデプロイ
次の項で、この手順を詳しく説明します。
事前準備
EJBデモを開発環境に展開します。helloworldアプリケーションは、次の構造で、<install-dir>\demo\ejb\helloworldの下に格納する必要があります。
|-------dist |-------etc | |-------application-client.xml | |-------application.xml | |-------ejb-jar.xml | |-------jndi.properties |-------src | |-------ejb | | |-------client | | | |-------HelloClient.java | | |-------helloworld-ejb | | |-------Hello.java | | |-------HelloBean.java | | |-------HelloHome.java | | |-------HelloLocal.java | | |-------HelloLocalHome.java |------build.xml
helloworldサンプル以外のアプリケーションは、チュートリアルの他の手順では無視してかまいませんが、IIOPを有効にするための変更により影響を受けないようにしてください。このチュートリアルでは、デモをルート・パーティションにインストールするため、アプリケーションは\demo\ejb\helloworldの下に置かれます。
付属のAntビルド・ファイルは、srcをコンパイルし、jarおよびearを構築し、クライアント・アプリケーションを実行するためのターゲットになります。このチュートリアルでは、ユーザーがAntビルド・ファイルを十分理解していることを前提としています。Antを十分理解していない場合は、Apache社のAntに関するドキュメント（http://ant.apache.org/manual/index.html）を参照してください。
OC4JでのIIOPの構成
server.xmlファイルを次のとおり編集します。
<install-dir>\j2ee\home\config\internal-settings.xml
server.xmlファイルに次の行が含まれることを確認します。
<sep-config path="./internal-settings.xml" />
この行がない場合、またはコメント・アウトされている場合は、そのコメントを削除するか、この行を次の行の下に追加してください。
<rmi-config path="./rmi.xml" />
これで、OC4J用のIIOPServerExtensionProviderが構成されます。
次に、internal-settings.xmlファイルを次のとおり編集してIIOP設定を構成します。
<install-dir>\j2ee\home\config\internal-settings.xml
ファイルに次の設定が含まれることを確認します。
<server-extension-provider name="IIOP" class="com.oracle.iiop.server.IIOPServerExtensionProvider"> <sep-property name="port" value="5555" /> <sep-property name="host" value="localhost" /> <sep-property name="ssl" value="false" /> <sep-property name="trusted-clients" value="*" /> </server-extension-provider>
必要に応じて、環境に応じてホストとポートを変更できます。ファイルにSSL用のエントリが含まれている場合は、そのエントリを一時的にコメント・アウトします。
<!-- <sep-property name="ssl-port" value="5556" /> <sep-property name="ssl-client-server-auth-port" value="5557" /> <sep-property name="keystore" value="keystore.jks" /> <sep-property name="keystore-password" value="->pwForSSL" /> <sep-property name="truststore" value="truststore.jks" /> <sep-property name="truststore-password" value="->pwForSSL" /> -->
これで、OC4JがIIOP用に構成されました。IIOPをサーバー・サイドで有効にする最終手順では、JVM引数 -DgenerateIIOP=trueを使用してOC4Jを起動します。これは、スタンドアロン版OC4Jの場合はコマンドラインで実行でき、Oracle Application Serverにインストールされている場合は%ORACLE_HOME\opmn\opmn.xmlファイルで実行できます。
JNDIプロバイダURLの構成
jndi.propertiesファイルをhelloworldアプリケーション用に次のとおり編集します。
<install-dir>\demo\ejb\helloworld\etc\jndi.properties java.naming.factory.initial=com.evermind.server.ApplicationClientInitialContextFactory java.naming.provider.url=corbaname:iiop:localhost:5555#helloworld #java.naming.provider.url=ormi://localhost:23791/helloworld java.naming.security.principal=admin java.naming.security.credentials=welcome
ORMIプロバイダURLを含む行をコメント・アウトし、corbanameプロバイダURLに一致する行を例に追加します。
アプリケーションの構築とデプロイ
<install-dir>\demo\ejb\helloworldディレクトリから、デフォルトのantターゲットを実行してアプリケーションを構築します。
<install-dir>\demo\ejb\helloworld > ant
OC4Jが起動していることを確認してから、次のデプロイ・コマンドを実行します。
java -jar ${J2EE_HOME}/admin.jar ormi://localhost:23791 admin welcome -deploy -file dist/helloworld.ear -deploymentName helloworld -iiopClientJar dist/helloworld_iiop_client.jar
これにより、helloworldアプリケーションがデプロイされ、クライアントIIOPスタブを含むクライアントEJB JARがdest\helloworld_iiop_client.jarに生成されます。
アプリケーションの実行
<install-dir>\demo\ejb\common.xmlファイルを編集し、ORACLE_HOME、JAVA_HOMEおよびJ2EE_HOMEの環境設定が使用する環境と一致していることを確認します。
> ant runを実行します。
適切な"Hello ..."レスポンスがクライアント・アプリケーションから返されます。次のJMV引数をクライアントとサーバーの両方に設定すると、この通信がIIOPを介して実行されていることを確認できます。
-Diiop.runtime.debug=true
サーバー上でのSSLを介したIIOPの有効化
internal-settings.xmlファイルを編集し、SSL設定（次の例の太字の行）をコメント解除または追加します。
<server-extension-provider name="IIOP" class="com.oracle.iiop.server.IIOPServerExtensionProvider"> <sep-property name="port" value="5555" /> <sep-property name="host" value="localhost" /> <sep-property name="ssl" value="true" /> <sep-property name="trusted-clients" value="*" /> <sep-property name="ssl-port" value="5556" /> <sep-property name="ssl-client-server-auth-port" value="5557" /> <sep-property name="keystore" value="keystore.jks" /> <sep-property name="keystore-password" value="yourPWD" /> <sep-property name="truststore" value="truststore.jks" /> <sep-property name="truststore-password" value=" yourPWD " /> </server-extension-provider>
必要に応じて、環境に応じてホストとポートを変更できます。keystoreとtruststoreは同じ物理ファイルである場合があります。前述の名前は、説明のためのものです。keystoreファイルがない場合は、keytoolを使用するためにSun社の次のサンプルを利用できます。
http://java.sun.com/docs/books/tutorial/security1.2/summary/tools.html
絶対パスとファイル名を例のkeystoreおよびtruststoreプロパティに追加します。
クライアント上でのSSLの有効化
jndi.propertiesファイルをhelloworldアプリケーション用に編集します。
<install-dir>\demo\ejb\helloworld\etc\jndi.properties java.naming.factory.initial=com.evermind.server.ApplicationClientInitialContextFactory java.naming.provider.url=corbaname:iiop:localhost:5556#helloworld java.naming.security.principal=admin java.naming.security.credentials=welcome
プロバイダURLのポートをinternal-settings.xmlのSSLポートに変更します。
helloworldアプリケーション用のejb_sec.propertiesというファイルを作成します。
oc4j.iiop.trustedServers=* nameservice.useSSL=true oc4j.iiop.trustStoreLoc=<path to server's keystore> oc4j.iiop.trustStorePass=<password for server's keystore file>
このファイルは、OC4Jクライアントのブートストラップ・クラスにアプリケーションのセキュリティ要件を通信します。この例にあるプロパティは、EJB参照にSSLを使用する必要があること、およびSSLをサポートしているすべてのサーバーが信頼できる必要があることを示します。truststore設定は、サーバーのkeystoreの証明書をエクスポートしてから2つ目のtruststoreファイルにインポートするかわりに、OC4J用に構成された同じkeystoreを使用するための簡単な方法です。
SSLを介するIIOPによるアプリケーションの実行
> ant runを実行します。
適切な"Hello ..."レスポンスがクライアント・アプリケーションから返されます。-Diiop.runtime.debug=trueをクライアントとサーバーの両方に設定すると、この通信がSSLを介するIIOPを使用して実行されていることを確認できます。
この項では、J2EE Connector Architecture（J2CA）に関するリリース・ノートについて説明します。 この項の内容は次のとおりです。
10.1.2実装では、J2CAの次の問題が解決されました。
Bug#3624173: データソースの参照に失敗した場合に、適切なエラーが生成されない。これに関連して、OC4J ApplicationConnectionManager.init()メソッドのバグも明らかになりました。このメソッドでは、関連付けられているプリンシパルのマッピング・メカニズムを正しく作成できない場合に、コネクション・ファクトリをJNDIにバインドできません。
Bug#2990051（3529400関連）: 接続プーリングが無効になった場合、コミットまたはロールバック時に接続ハンドルのみがクローズされ、物理的な接続はクローズされない。物理的な接続もクローズされる必要があります。
Bug#3525933: ManagedConnectionFactory.matchManagedConnection()をコールするユーザー・コードでNotSupportedExceptionが発生すると、OC4J ApplicationConnectionManager.allocateConnection()メソッドもNotSupportedExceptionをスローする。これは、ユーザーが接続プーリングを無効にすると、OC4JはallocateConnection()コール時に必ず強制終了されることを意味します。実際には、OC4JはNotSupportedExceptionエラーを捕捉し、プールを使用せずに接続を作成する必要があります。
この項では、OC4Jのドキュメントの誤記について説明します。 この項の内容は次のとおりです。
5.5.1項「『Oracle Application Server Containers for J2EE JSPタグ・ライブラリおよびユーティリティ・リファレンス』の誤記」
5.5.2項「『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の誤記」
5.5.4項「『Oracle Application Server Containers for J2EEセキュリティ・ガイド』の誤記」
この項では、『Oracle Application Server Containers for J2EE JSPタグ・ライブラリおよびユーティリティ・リファレンス』の誤記について説明します。 この項の内容は次のとおりです。
リリース10.1.2のOC4Jドキュメントでは、『Oracle Application Server Containers for J2EE JSPタグ・ライブラリおよびユーティリティ・リファレンス』のOracleAS Personalizationタグに関する章が、リリース10.1.2フェーズIのOracleAS Personalizationのステータスが原因で削除されています。この章は、リリース10.1.3のドキュメントで復活します。それまでは、このタグ・ライブラリの詳細は、リリース9.0.4のOC4Jのドキュメント・セットで参照できます。
この項では、『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の誤記について説明します。 この項の内容は次のとおりです。
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の第4章「OC4Jのクラスタリング」に、次の誤記があります。
「各OC4JプロセスはOC4Jインスタンスに含まれ、設定はOC4Jインスタンスから継承されます。OC4Jインスタンスにデプロイされたすべてのアプリケーションは、そのOC4JインスタンスのすべてのOC4Jプロセスにもデプロイされます。」
この文は誤記です。このようなOC4Jプロセスは他のプロセスにのみに含めることができ、OC4Jインスタンスはプロセスではありません。
正しい記述は次のとおりです。
「各OC4JプロセスはOC4Jインスタンスに関連付けられ、設定はそのOC4Jインスタンスから継承されます。あるOC4Jインスタンスにデプロイされたすべてのアプリケーションは、そのOC4Jインスタンスに関連付けられたすべてのOC4Jプロセスで起動されます。」
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の付録B「追加情報」にあるserver.xmlファイルの<metric-collector>要素に関する説明の参照先に誤記があります。
「mod_oc4jで<metric-collector>要素とメトリックベースのロード・バランシングを使用する場合の詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。」
正しい記述は次のとおりです。
mod_oc4jでメトリックベースのロード・バランシングを使用する場合の詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の第1章「OC4Jの概要」には、Oracle Application Server Containers for J2EE 10g リリース2（10.1.2）とともに使用するJava Development Kit（JDK）に関する記述に誤記があります。
OC4Jで使用するJDKに関する項には、サポートされるバージョンとしてJDK 1.3.1および1.4.1が記載されています。このリストには、JDK 1.4.2も含まれます。
要件に関する項には、OC4JとともにJDK 1.3.xがインストールされるという誤記があります。正しいバージョンはJDK 1.4.2です。
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』の第1章「OC4Jの概要」には、入門編の記述が含まれていますが、入門編は、ユーザーズ・ガイドから削除されています。
『Oracle Application Server Containers for J2EEユーザーズ・ガイド』のデプロイに関する説明には、アンデプロイおよび再デプロイについての次の注意も必要です。
アンデプロイ/再デプロイには、次の一般的な注意があります。
アプリケーションはOC4Jからアンデプロイされると、クライアントにアクセスできなくなります。Oracle Application Server環境では、Oracle HTTP Serverが再起動され、OC4Jのマウント・ポイントが削除されます。これによって、既存のHTTPセッションが失われます。
再デプロイ時には、新しいEARを再デプロイする前に、OC4Jによって既存のアプリケーション（EAR/WAR）が削除されます。このため、たとえば、以前のアプリケーションに含まれていて、新しいアプリケーションには含まれていないHTMLファイルにアクセスしようとすると、「File Not Found」というエラーになります。
再デプロイされたWARファイルは、以前に展開されたWARの上に重ねて配置され、これによって新しいデプロイメントに古いファイルが保持される場合があるため、古いファイルを削除する必要があります。たとえば、新しいWARには含まれていない以前のデプロイメントの静的HTMLファイルは、展開されたWARディレクトリ構造にも含まれるため、手動で削除する必要があります。
ホット再デプロイには、次の注意があります。
実行中のOC4JインスタンスでEARを再デプロイまたはホット再デプロイすると、以前のアプリケーションからJVMにロードされたクラスのステータスが変更される場合があります。ClassLoaderはファイル・システムのクラスまたはJARファイルが変更されたと認識し、クラスやライブラリを再ロードする場合があります。その他の場合として、新しいクラス定義がロードされるかどうかが、ガベージ・コレクタによる既存のクラス定義の削除をJVMチューニングが許可しているかどうかに依存する場合があります。
セッション・データを含むシリアライズされたオブジェクトに関する問題もあります。セッション・オブジェクトに関連するクラスが変更された場合、そのクラスは、元のクラスへ一般的なセッション・オブジェクトをキャストできない場合があります。これは、クラスが変更されると、その変数では、異なるメモリーを使用する場合があるためです。これによって、セッション・データが失われる場合があります。
Oracle Application Server環境では、ホット・デプロイ（OC4Jの再起動を伴わないアプリケーションのデプロイ）によって、Oc4jMountディレクティブがmod_oc4j.confに追加され、Oracle HTTP Serverが再起動されます。これによって、既存のHTTPセッションが失われます。
この項では、『Oracle XML APIリファレンス』の誤記について説明します。この項の内容は次のとおりです。
『Oracle XML APIリファレンス』の第15章「C++用のDOM APIパッケージ」に、次の情報を追加してください。
表15-7「DOMImplRefメソッドの概要: DOMパッケージ」に、formDocument()メソッドのエントリを追加し、その説明を「ドキュメントへのポインタを与えられると、ドキュメント参照を形成します。」にします。
次のメソッドの説明を追加します。
formDocument()
説明
ドキュメントへのポインタを与えられると、ドキュメント参照を形成します。
構文
DocumentRef< Node>* formDocument( Node* node);
----------------------------------------------------
パラメータ 説明
----------------------------------------------------
node ドキュメント・ノードへのポインタ
----------------------------------------------------
戻り値
ドキュメント参照へのDocumentRef< Node>*ポインタ
この項では、『Oracle Application Server Containers for J2EEセキュリティ・ガイド』の誤記について説明します。 この項の内容は次のとおりです。
第15章「CSIv2の構成」の<establish-trust-in-target>および<establish-trust-in-client>要素の値に誤記があります。
<establish-trust-in-target>要素の値には、supportedおよびnoneのみ使用できます。requiredは使用できません。
<establish-trust-in-client>要素の値には、required、supportedおよびnoneを使用できます。
第9章「外部LDAPプロバイダの構成」に次の問題があります。
サード・パーティのLDAPプロバイダを使用するアプリケーションは、小文字のみを使用してデプロイメント・ロールを定義する必要があります。ロール名に大文字を使用すると、認証に失敗します。orion-application.xmlにデプロイメント・ロールを定義する場合は、すべての論理ロールを小文字の名前にのみマップする必要があります。
次に、有効なデプロイメント・ロール名および無効なデプロイメント・ロール名を示します。
<security-role-mapping name="sr_developer"> <!- Logical role --> <group name="developers" /> <!- Valid deployment role --> </security-role-mapping> <security-role-mapping name="jr_developer"> <!- Logical role --> <group name="JuniorDevelopers" /> <!- Invalid deployment role; causes authorization failure --> </security-role-mapping>
第4章「全体的なセキュリティ構成」にある、プリンシパルからのレルム名の削除に関する項は不完全です。jaas.user.simplenameプロパティの<propertyname="jaas.username.simple" value="true" />は、次のインスタンス固有のjazn.xmlファイルでのみ設定されます。
%ORACLE_HOME\j2ee\%INSTANCE\config\jazn.xml
このプロパティは、指定したOC4Jインスタンスにのみ影響します。orion-application.xmlのこのプロパティの設定には影響しません。
