| Oracle Fusion Middleware Oracle TopLink開発者ガイド 11gリリース1（11.1.1） B56246-01 |
|
 戻る |
 次へ |
この章では、Oracle TopLinkをJava EEコンテナおよびアプリケーション・サーバーで使用するための構成方法について説明します。Oracle TopLinkは任意のJava EEコンテナまたはアプリケーション・サーバーで（TopLink APIを介して）使用できますが、この章でリストされているアプリケーション・サーバーには固有の統合とサポートを提供します。
この章の内容は次のとおりです。
詳細は、次を参照してください。
TopLinkは、「ソフトウェア要件の概要」で示されている要件を満たす任意のJava EEアプリケーション・サーバーで（TopLink APIを介して）使用できます。
表8-1は、TopLinkがJPA、CMP 2.nおよびセッションEJB/BMPの固有の統合を提供するアプリケーション・サーバーを示します。
表8-1 TopLinkによる統合サポート（アプリケーション・サーバーのタイプ別）
| アプリケーション・サーバーのタイプ | アプリケーション・サーバーのバージョン | JPA | CMP 2.n | セッションBean脚注1およびBMP |
|---|---|---|---|---|
|
Oracle WebLogic Server |
10.3 |
 |
 |
|
|
Oracle WebLogic Server |
9.n |
|
|
|
|
OC4J |
10.1.3.n |
|
|
|
|
OC4J |
10.1.3 |
|
|
|
|
OC4J |
9.0.4 |
|
|
|
|
OC4J |
9.0.3 |
|
|
|
|
IBM WebSphere |
6.1 |
|
|
|
|
SunAS |
9 |
|
|
|
|
JBoss |
4.2.0 |
|
|
|
脚注1 これは、EJB 1.n、2.nおよび3.0のセッションBeanに該当します。
詳細は、次を参照してください。
この項では、次のようなTopLinkアプリケーション・サーバーの統合に固有の概念について説明します。
TopLinkアプリケーションをJava EEコンテナ内で実行するには、システムが次のソフトウェア要件を満たしている必要があります。
アプリケーション・サーバーまたはJava EEコンテナ（表8-1を参照）
XMLパーサー（8.2.2項「XMLパーサー・プラットフォームの構成方法」を参照）
ローカル・データベース・システムに接続するよう構成されたJDBCドライバ（詳細はデータベース管理者にお問い合せください）
次のようなJava開発環境
Oracle JDeveloper
IBM WebSphere Studio Application Developer（WSAD）
Sun JDK 1.5以上
Sun JDK 1.5以上と互換性のあるその他のJava環境
コマンドラインのJVM実行可能ファイル（java.exeやjre.exeなど）
TopLinkのランタイム環境は、XMLパーサーを使用して次を実行します。
XML構成ファイルの読取りと書込み（9.1.1項「project.xmlファイル」および9.1.2項「sessions.xmlファイル」を参照）
TopLink Workbenchプロジェクト・ファイルの読取りと書込み（5.1項「TopLink Workbenchの概要」を参照）
XMLレコードを使用したEISプロジェクトにおけるオブジェクト/XML間のトランスフォーメーションの実行（第77章「EISマッピングの概要」を参照）
XMLプロジェクトにおけるオブジェクト/XML間のトランスフォーメーションの実行（第53章「XMLマッピングの概要」を参照）
アプリケーション・サーバーは、XMLパーサーを使用して、ejb-jar.xmlおよび<Java EE container>-ejb-jar.xmlファイルなどのデプロイメント・ファイルを読み取ります（第9章「デプロイ用TopLinkファイルの作成」を参照）。
XMLパーサーの競合を避けるため、アプリケーションをデプロイするアプリケーション・サーバーによって使用されるのと同じXMLパーサーを使用するように、TopLinkアプリケーションを構成する必要があります。
内部的には、TopLinkは、XMLパーサーにアクセスするためにoracle.toplink.platform.xml.XMLPlatformクラスのインスタンスを使用します。
TopLinkを構成して、XMLPlatformクラスが存在するXMLパーサーを使用できます（8.2.2.1項「XMLパーサー・プラットフォームの構成」を参照）。
独自のXMLPlatformを作成して、TopLinkが現在サポートしていないXMLパーサーへのアクセスを提供することもできます（8.2.2.2項「XMLパーサー・プラットフォームの作成」を参照）。
TopLinkにより提供されるXMLPlatformのインスタンスは、表8-2のとおりです。
表8-2 サポートされているXMLプラットフォーム
| XMLPlatform | アクセスできるXMLパーサー | 使用先 |
|---|---|---|
|
|
|
|
|
|
|
次を参照してください。 |
脚注1 デフォルトです。
TopLinkアプリケーションを構成してXMLPlatformクラスの特定のインスタンスを使用するには、例8-1に示すように、システムのプロパティtoplink.xml.platformをXMLPlatformクラスの完全修飾名に設定してください。
TopLinkに付属のパブリック・ソース・ファイルに含まれているoracle.toplink.platform.xmlクラスを使用すると（13.3項「パブリック・ソースの使用」を参照）、oracle.toplink.platform.xml.XMLPlatformクラスの独自のインスタンスを作成して、表8-2にリストされていないXMLパーサーを指定できます。
XMLPlatformの作成後、それを使用するようにTopLinkを構成します（8.2.2.1項「XMLパーサー・プラットフォームの構成」を参照）。
Crimson（http://xml.apache.org/crimson/）は、Java Platform, Standard Edition（Java SE）および一部のJAXP参照の実装に付属のXMLパーサーです。
CrimsonをJAXP APIとともに使用して、システム識別子が完全修飾されたURLでないXMLファイルを解析すると、XML解析は「not valid URL」例外で失敗します。
その他のXMLパーサーでは、システム識別子のURLが明確に参照されるまで、その検証が遅延されます。
この問題が発生した場合は、次のいずれかの代替方法を検討してください。
必ず、XMLファイルが完全修飾されたシステム識別子URLを使用するようにします。
別のXMLパーサー（OracleAS XML Parser for Java v2など）を使用します。
デフォルトでは、デフォルトでないjava.lang.SecurityManagerで構成されたJVMでTopLink対応アプリケーションを実行すると、TopLinkランタイム環境は、java.security.AccessControllerメソッドdoPrivilegedでPrivilegedActionを実行して、特定の内部関数を実行します。これにより、TopLinkがその大部分の共通の操作を実行するために、TopLinkに多くのパーミッションを付与する必要がなくなります。使用するオプションのTopLink機能のタイプに応じて、特定のパーミッションを付与するだけでよいのです。
詳細は、8.8項「セキュリティ・パーミッションの定義」を参照してください。
デフォルトでないSecurityManagerのないJVMでTopLink対応アプリケーションを実行する場合は、パーミッションを設定する必要はありません。
TopLinkを永続性マネージャとして使用するように、アプリケーション・サーバーを構成できます。
JARファイルに含まれるコンテナ管理の永続性を備えたすべてのエンティティBeanに対して、ただ1つの永続性マネージャのみを使用できます。
TopLinkは、TopLinkを永続性マネージャとして使用するように既存のJava EEアプリケーションを移行するための自動サポートを提供します。詳細は、8.4.2項「OC4J TopLink永続性へのOC4J Orion CMP永続性の移行方法」を参照してください。
大部分のアプリケーション・サーバーは、TopLinkアプリケーションで利用できるクラスタリング・サービスを備えています。
アプリケーション・サーバーのクラスタでTopLinkを使用するには、次の一般的な手順を実行します。
各アプリケーション・サーバーにあるtoplink.jarファイルを、TopLinkアプリケーションをデプロイするためのクラスタにインストールして、このファイルをクラスパスに含めます。
アプリケーションに適したTopLinkキャッシュの一貫性オプションを構成します。
詳細は、第102章「キャッシュの概要」を参照してください。
CMPアプリケーションをデプロイするには、9.9.1.2項「cache-synchronizationのプロパティの構成」も参照してください。
アプリケーション・サーバーに対するTopLinkのコーディネート・キャッシュのサポートを構成します（存在する場合）。
各アプリケーション・サーバーでクラスタリングを構成します。
詳細は、アプリケーション・サーバーのドキュメントを参照してください。
TopLinkアプリケーションをOracle WebLogic Serverと統合するには、次のことを考慮する必要があります。
これらのOracle WebLogic Server固有のオプションの構成を考慮するのみでなく、8.2項「TopLinkとアプリケーション・サーバーの統合」に記載の、アプリケーション・サーバーの統合に関する一般的な問題も考慮する必要があります。
Oracle WebLogic Server上でTopLinkを初期状態で実行している場合は、アプリケーション・サーバーのクラスパスを変更する必要はありません。
com.oracle.toplink_*.jarファイルの形式であるTopLinkライブラリと、org.eclipse.persistence_*.jarファイルの形式であるEclipseLinkライブラリの両方が、サーバーの次の場所に存在していることに注意してください。
<BEA_HOME>/modules/
ここで、<BEA_HOME>はスタンドアロンのOracle WebLogic Serverがインストールされているディレクトリです。
|
注意: 本番環境には適していませんが、開発時はライブラリ・ファイルの異なる構成を考慮する可能性もあります。これらの構成オプションは、クラスパス・ツリー内でライブラリを配置する場所や、2つの異なるサーバー・バージョンを実行するかどうかによって異なります。詳細は、http://wiki.eclipse.org/EclipseLink/Examples/JPA/WebLogic_Web_Tutorial#EclipseLink_JAR_locationを参照してください。 |
JTA統合を必要とするアプリケーションの場合、セッションでサーバー・プラットフォームを構成する際に外部トランザクション・コントローラを指定します（89.9項「サーバー・プラットフォームの構成」を参照）。
詳細は、115.13項「作業ユニットと外部トランザクション・サービスの統合」を参照してください。
デフォルトでは、TopLinkアプリケーションをOracle WebLogic Serverにデプロイする場合、TopLinkランタイムによりEclipseLink永続性プロバイダが使用され、セッションごとに次のJava Management Extensions（JMX）MBeanがOracle WebLogic Server JMXサービスにデプロイされます。
org.eclipse.persistence.services.DevelopmentServices
org.eclipse.persistence.services.RuntimeServices
詳細は、『EclipseLink Developer's Guide』の「How to Integrate JMS」（http://wiki.eclipse.org/Integrating_EclipseLink_with_an_Application_Server_%28ELUG%29#How_to_Integrate_JMX）を参照してください。
Oracle WebLogic Server JMXのサポートの詳細は、次のドキュメントを参照してください。
『Oracle Fusion Middleware Developing Manageable Applications With JMX for Oracle WebLogic Server』
『Oracle Fusion Middleware Developing Manageable Applications With JMX for Oracle WebLogic Server』
一般的なJMXの詳細は、http://java.sun.com/docs/books/tutorial/jmx/index.htmlを参照してください。
セキュリティ・マネージャを使用する場合、（通常はOracle WebLogic Serverのインストール・ディレクトリにある）weblogic.policyファイルで、次のようにセキュリティ・ポリシー・ファイルを指定します。
-Djava.security.manager
-Djava.security.policy==<BEA_HOME>\wlsserver_10.3\weblogic.policy
Oracle WebLogic Serverのインストール手順は、サンプル・セキュリティ・ポリシー・ファイルを含んでいます。weblogic.policyファイルを編集し、TopLinkでリフレクションを使用するためのパーミッションを付与する必要があります。
次の例ではTopLinkに必要なパーミッションのみを示していますが、ほとんどのweblogic.policyファイルには、この例に示したもの以外のパーミッションも含まれています。
例8-2 weblogic.policyファイルのgrantセクションのサブセット
grant {
// "enableSubstitution" required to run the WebLogic console
permission java.io.SerializablePermission "enableSubstitution";
// "modifyThreadGroup" required to run the WebLogic server
permission java.lang.RuntimePermission "modifyThreadGroup";
// grant permission for TopLink to use reflection
permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};
TopLinkアプリケーションをOC4Jと統合するには、次のことを考慮する必要があります。
これらのOC4J固有のオプションの構成を考慮するのみでなく、8.2項「TopLinkとアプリケーション・サーバーの統合」に記載の、アプリケーション・サーバーの統合に関する一般的な問題も考慮する必要があります。
OC4JにおけるTopLink CMP統合を可能にするには、次の手順に従います（この手順では、TopLinkがインストール済であることを前提にしています）。
必要であれば、TopLink移行ツールを使用してCMPアプリケーションを移行してください（8.4.2項「OC4J TopLink永続性へのOC4J Orion CMP永続性の移行方法」を参照）。
UnitOfWork変更ポリシーの選択を評価します（113.2.3項「作業ユニットおよび変更ポリシー」を参照）。
必要なデプロイメント・ディスクリプタ・ファイルがすべて適切な位置にあることを確認します（第9章「デプロイ用TopLinkファイルの作成」および第10章「TopLinkアプリケーションのパッケージ化」を参照）。
必要に応じて、TopLinkが提供するEJBカスタマイズ・オプションを検討します（8.9項「各種EJB CMPオプションの構成」を参照）。
OC4J 9.0.4以下を11gリリース1（11.1.1）にアップグレードする場合、元のorion-ejb-jar.xmlファイルからtoplink-ejb-jar.xmlファイルに永続性の構成を移行する必要があります。
11gリリース1（11.1.1）では、Oracleは、リリース2（9.0.4）以降のOC4Jのインストールに対するこの移行の自動化に使用できるTopLink移行ツールを提供します。
TopLink移行ツールを使用した後で、8.4.2.4項「移行後の変更の実行」で説明されているいくつかの追加変更が必要となる場合があります。
移行中に問題が発生した場合は、8.4.2.5項「移行のトラブルシューティング」を参照してください。
この項では、TopLink移行ツールの使用方法について説明します。この項の内容は次のとおりです。
|
注意: Oracle JDeveloperからTopLink移行ツールを使用することもできます。 |
TopLink移行ツールを使用する前に、この項を参照し、TopLink移行ツールの動作方法を理解して、移行させる、または移行させないOC4J永続性マネージャのメタデータを決定してください。
入力および出力
TopLink移行ツールは、次のファイルを入力としてとります。
ejb-jar.xml
orion-ejb-jar.xml
TopLink移行ツールは、OC4J固有の永続性構成をできるだけ多く新しいtoplink-ejb-jar.xmlファイルに移行し、指定したターゲット・ディレクトリに次の新しいファイルを作成します。
orion-ejb-jar.xml
toplink-ejb-jar.xml
TopLink Workbenchプロジェクト・ファイルTLCmpProject.mwp
ejb-jar.xmlおよびorion-ejb-jar.xmlファイルは、EAR内またはJAR内のものであっても、または単にスタンドアロンであるXMLファイルであってもかまいません。EARまたはJARファイルではなく、スタンドアロンのXMLファイルから移行する場合、ドメイン・クラスがクラスパスに含まれていてアクセス可能であることを確認してください。
TopLink移行ツールは、指定したターゲット・ディレクトリに新しいorion-ejb-jar.xmlおよびtoplink-ejb-jar.xmlファイルを、読み取る元のファイルと同じ形式で作成します。たとえば、EARファイルを入力として指定すると、TopLink移行ツールは、新しいorion-ejb-jar.xmlと新しいtoplink-ejb-jar.xmlファイルの2つを含む新しいEARファイルをステージングして作成します。この2つ以外は元のEARファイルと同じです。
TopLink Workbenchプロジェクト・ファイルは、常に独立したファイルとして作成されます。
|
注意: TopLink移行ツールを使用する前に、orion-ejb-jar.xmlファイルのバックアップ・コピーを作成しておくことをお薦めします。 |
移行
TopLink移行ツールを実行すると、すべてのエラーおよび診断出力が、出力ディレクトリにあるoc4j_migration.logという名前のログ・ファイルに記録されます。TopLink WorkbenchからTopLink移行ツールを使用する場合は、ユーザーのホーム・ディレクトリ（例: C:\Documents and Settings\<user-name>）にあるTopLink Workbenchログ・ファイルoracle.toplink.workbench.logも参照してください。
TopLink移行ツールは、入力ファイルからのディスクリプタ、マッピングおよび問合せ情報を次のように処理します。
エンティティBeanごとにTopLinkディスクリプタ・オブジェクトを作成し、マップ対象の表、主キーおよびCMPとCMRのフィールドのマッピングなど、ネイティブの永続性メタデータを移行します。
エンティティBeanのCMPおよびCMRのフィールドごとにTopLinkマッピング・オブジェクトを作成し、外部キー参照などネイティブの永続性メタデータを移行します。
エンティティBeanのファインダまたはejbSelectごとにTopLink問合せオブジェクトを作成し、カスタマイズした問合せ文などの永続性メタデータを移行します。
表8-3は、orion-ejb-jar.xmlファイルからのOC4J <entity-deployment>の属性とサブ要素を示し、TopLink移行ツールが属性とサブ要素ごとに次の動作を行うかどうかを示します。
新しいorion-ejb-jar.xmlファイルにそれを保持
新しいtoplink-ejb-jar.xmlファイルにそれを移行
表8-3では、要素はかぎカッコで識別されています。属性の設定値には移行される値と破棄される値（例: exclusive-write-access）があることに注意してください。
表8-3 OC4J orion-ejb-jar.xml機能の移行
| orion-ejb-jar.xml機能 | 新しいorion-ejb-jar.xmlで保持 | 新しいtoplink-ejb-jar.xmlへ移行 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
1より大きい任意の値 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注1 force-updateは移行後に有効化できます。詳細は、119.18項「EJB CMPおよびBMP情報によるディスクリプタの構成」を参照してください。
脚注2 TopLinkは、実行時に外部結合と内部結合の両方をサポートします。これらのオプションを使用するようにEJBディスクリプタを手動で構成できます。詳細は、108.7.1.5項「結合読取りとオブジェクト・レベルの読取り問合せ」を参照してください。
脚注3 persistence-type属性表の列サイズは、存在していても破棄されます。詳細は、8.4.2.4項「persistence-type表の列サイズの復元」を参照してください。
表8-4は、OC4J機能および、TopLink移行ツールで構成されたTopLinkの同等機能を示します。
表8-4 OC4JおよびTopLinkの機能比較
| 機能 | orion-ejb-jar.xml | toplink-ejb-jar.xml |
|---|---|---|
|
CMPフィールド・マッピング |
ダイレクト。 シリアライズ・オブジェクト |
フィールドへ直接。 シリアライズ・オブジェクト |
|
CMRフィールド・マッピング |
1対1 1対多 多対多 |
1対1 1対多 多対多 |
|
部分問合せ |
完全なSQL文。 |
SQLコール。 |
|
ファインダ |
Oracle固有構文。 |
SQLコールまたはEJB QL。 |
|
遅延ロード（フェッチ・グループ） |
主キーおよびCMPフィールドの遅延ロード。 |
サポートされていません。 そのかわり、適切な場合、TopLinkの同等機能を手動で構成できます（16.2.4項「フェッチ・グループ」を参照）。 |
|
SQL文のキャッシュ |
静的SQLのキャッシュ。 |
Beanレベルではサポートされていません。 TopLinkは、セッションおよび問合せレベルでのパラメータ使用のSQLおよび文のキャッシュをサポートします（第108章「TopLink問合せの概要」を参照）。 |
|
ロック |
オプティミスティック: データベース・レベル。 ペシミスティック: Beanインスタンス・レベル。 |
オプティミスティック: オブジェクト・レベル。 ペシミスティック: データベース・レベルでの問合せロック。 |
|
読取り専用 |
スローされる |
スローされる |
|
妥当性のタイムアウト |
リロード前に読取り専用Beanの妥当性がタイムアウト。 |
キャッシュがタイムアウト。 |
|
分離レベル |
コミットされます。 シリアライズ可能 |
コミットされます。 シリアライズ可能 コミットされません。 反復不可能。 |
|
コミットまで更新を遅延 |
サポートされています。 |
サポートされています（119.18項「EJB CMPおよびBMP情報によるディスクリプタの構成」を参照）。 |
|
Beanへの排他的書込みアクセス |
デフォルト値は |
デフォルト値は |
|
存在チェックなしの挿入 |
サポートされています。 |
サポートされています。 |
|
変更済フィールドのみ更新 |
サポートされています。 |
サポートされています（113.2.3.3項「属性変更追跡ポリシー」を参照）。 |
|
強制的更新 |
永続性フィールドが変更されていなくてもBeanのライフ・サイクル用 |
サポートされています。 |
TopLink Workbenchから、「ファイル」→「移行」→「OC4J 9.0.xから」の順に選択します。
次の情報を参照し、「OC4Jの移行からMapping Workbenchプロジェクトを作成」ダイアログ・ボックスの各フィールドにデータを入力します。
| フィールド | 説明 |
|---|---|
| 作成元 | 次のフィールドを使用して、既存のOC4Jファイルの場所を指定します。これらのファイルは、JARまたはEARの一部、あるいは単独ファイルとして含めることができます。 |
| 個々のファイル | 「入力ディレクトリ」にある個々のejb-jar.xmlおよびorion-ejb-jar.xmlファイルからの変換を選択します。「参照」をクリックして、変換元となるXMLファイルを含むディレクトリの場所を選択します。 |
| アーカイブ・ファイル | 特定のアーカイブ・ファイルを使用するように選択します。「参照」をクリックし、変換元となるアーカイブ・ファイルを選択します。 |
| 作成先 | 次のフィールドを使用して、移行されたファイルが書き込まれる場所を指定します。 |
| 出力ディレクトリ | 「参照」をクリックして、新しいXMLファイルおよびTopLink Workbenchプロジェクトを作成するディレクトリの場所を選択します。 |
| クラスパス | 移行元として個々のファイルを選択する場合、ドメイン・クラスがクラスパスに含まれていてアクセス可能であることを確認してください。 |
| 移行ログの表示 | 移行ログ出力を別ウィンドウに表示するように選択します。 |
コマンドラインからTopLink移行ツールを使用するには、次の手順を実行する必要があります。
クラスパスに次が含まれているかを確認します。
<TOPLINK_HOME>/modules/oracle.toplink_11.1.1/jlib/antlr.jar
<TOPLINK_HOME>/jlib/toplink.jar
<TOPLINK_HOME>/utils/workbench/jlib/cmpmigrator.jar
<TOPLINK_HOME>/utils/workbench/jlib/toplinkmw.jar
<TOPLINK_HOME>/utils/workbench/jlib/tlmwcore.jar
<TOPLINK_HOME>/jlib
<TOPLINK_HOME>/modules/xmlparserv2.jar
EARまたはJARファイルではなく、プレーンのXMLファイルからの移行を意図する場合、ドメイン・クラスがアクセス可能で、クラスパスに含まれていることを確認してください。
元のXMLファイルのバックアップ・コピーを作成します。
表8-5にリストされた適切な引数を使用して、例8-3に示すように、TopLink移行ツールを実行してください。
TopLink移行ツールの使用方法の詳細は、次のとおりです。
java -Dtoplink.ejbjar.schemavalidation=<true|false> -Dtoplink.migrationtool.generateWorkbenchProject=<true|false> -Dhttp.proxyHost=<proxyHost> -Dhttp.proxyPort=<proxyPort> oracle.toplink.tools.migration.TopLinkCMPMigrator -s<nativePM> -i<inputDir> -a<ear>|<jar> -x -o<outputDir> -v
入力ファイルを指定するには、-aまたは-xのいずれかを指定する必要があります。
トラブルシューティング情報は、8.4.2.5項「移行のトラブルシューティング」を参照してください。
例8-3 コマンドラインからのTopLink移行ツールの使用
java -Dhttp.proxyHost=www-proxy.us.oracle.com -Dhttp.proxyPort=80 oracle.toplink.tools.migration.TopLinkCMPMigrator -sOc4j-native -iC:/mywork/in -aEmployee.ear -oC:/mywork/out -v
表8-5 TopLink移行ツールの引数
| 引数 | 説明 |
|---|---|
|
|
|
|
|
TopLink Workbenchプロジェクトの生成を使用可能にするために使用されるシステム・プロパティ。デフォルト値は |
|
|
ローカルHTTPプロキシ・ホストのアドレス。 |
|
|
ローカルHTTPプロキシ・ホストがHTTPリクエストを受信するポート番号。 |
|
|
移行元のネイティブ永続性マネージャの名前。 OC4Jには、名前 |
|
|
移行元となるOC4Jの |
|
|
移行元となるOC4Jの |
|
|
移行元となる入力ディレクトリのOC4Jファイルが、プレーンXMLファイルで、アーカイブ・ファイル中にはないことをTopLink移行ツールに指示します。 このオプションを使用する場合、ドメイン・クラスがクラスパスに含まれていてアクセス可能であることを確認してください。 |
|
|
TopLink移行ツールがファイルおよびサブディレクトリを作成できるパーミッションがこのディレクトリに設定されていことを確認します。 |
|
|
冗長モード。エラーおよび診断情報のログをコンソールに記録するようにTopLink移行ツールに指示します。 |
orion-ejb-jar.xmlファイルの永続性構成をtoplink-ejb-jar.xmlファイルに移行した後、次のような移行後の変更について検討します。
persistence-type表の列サイズの復元
orion-ejb-jar.xmlファイルにおいて、例8-4に示すように、タイプと列サイズの両方を提供するpersistence-type属性を使用して、マッピングcmp-field-mappingを指定できます。
例8-4 persistence-typeで列サイズを指定したcmp-field-mapping
<cmp-field-mapping ejb-reference-home="MyOtherEntity" name="myField" persistence-name="myField" persistence-type="VARCHAR2(30)">
TopLink移行ツールは、永続性タイプを移行しますが列サイズは移行しません。TopLinkプロジェクトは、通常、このサイズ情報を含まないためです。
persistence-typeの列サイズを復元するには、次のようにします。
8.4.2.3項「コマンドラインからのTopLink移行ツールの使用」の説明に従って、移行を実行します。
生成したTopLink Workbenchプロジェクト・ファイルTLCmpProject.mwpを開きます。
データベースにログインします（5.5.1.1項「データベースへのログインおよびデータベースからのログアウト」を参照）。
すべての列サイズが取得されます。
不明な主キー・クラス・マッピング順序表の更新
不明の主キー・クラス（8.9.2項「EJB CMPの不明な主キー・クラスのサポートの構成方法」を参照）の使用は、TopLinkでサポートされているため、TopLink移行ツールでもサポートされています。
OC4Jは、ネイティブのランタイム・キー・ジェネレータを使用して、自動識別キー・フィールドに対して一意のキーを生成します。これとは対照的に、TopLinkは順序付け表を使用します。
OC4Jの永続性構成に不明の主キー・クラスの使用が含まれている場合、TopLink移行ツールは、不明の主キー・クラスを使用するために順序付け表を作成します。
移行後、アプリケーションをデプロイする前に、次を行う必要があります。
移行前に生成済であった最大のキー値を確認します。
TopLink移行ツールが生成した順序付け表のカウンタを、移行前に生成済であった最大のキー値より1だけ大きな数に、手動で更新します。
プロジェクトのカスタマイズ
次のように、プロジェクトのコンポーネントをカスタマイズできます。
OC4JにデプロイされたEJB 2.1 CMPアプリケーション用にTopLink永続性マネージャをカスタマイズするには、orion-ejb-jar.xmlファイルのプロパティを構成します。これらのプロパティは、TopLinkランタイムがCMPプロジェクトのために内部で使用するTopLinkセッションを構成するために使用されます。詳細は、9.9.1項「persistence-managerのエントリの構成方法」を参照してください。
デプロイ時にプロジェクトにデフォルト設定を適用した後で、セッション・イベント・リスナーを構成することでTopLinkセッションをカスタマイズすることも可能です。ログイン前イベントを呼び出すようにセッションを構成すると、特に便利です。セッションが接続を初期化し取得する直前に、セッションのためのカスタム（デフォルトではない）の仕様を定義できるようになります。
詳細は、次を参照してください。
この項では、移行の際に発生する可能性のある問題の解決策について説明します。この項の内容は次のとおりです。
メッセージのロギング
TopLink移行ツールを実行すると、すべてのエラーおよび診断出力が、出力ディレクトリにあるoc4j_migration.logという名前のログ・ファイルに記録されます。TopLink WorkbenchからTopLink移行ツールを使用する場合は、ユーザーのホーム・ディレクトリ（例: C:\Documents and Settings\<user-name>）にあるTopLink Workbenchログ・ファイルoracle.toplink.workbench.logも参照してください。
これらの警告に加え、TopLink移行ツールは、移行の完了を妨げる問題が発生した場合、エラーを記録します。表8-6は、これらの問題を示し、その解決策を提案します。
表8-6 TopLink移行ツールのエラー・メッセージ
| エラー・メッセージ | 説明 |
|---|---|
|
|
|
|
ネイティブの永続性メタデータが定義された |
|
|
|
|
|
表が指定されていないため、 |
エンティティがデータベース表にマップされていません。移行前に、 |
予期しないリレーションの多重度
TopLink移行ツールは、OC4J ejb-jar.xmlファイルからではなく、orion-ejb-jar.xmlファイルからリレーションシップの多重度を取得します。
したがって、OC4J ejb-jar.xmlファイルがリレーションシップを1対多として定義しても、orion-ejb-jar.xmlファイルが同じリレーションシップを多対多として定義している場合、TopLink移行ツールはこれらのリレーションシップを多対多として移行することになります。
JTA統合を必要とするアプリケーションの場合、セッションでサーバー・プラットフォームを構成する際に外部トランザクション・コントローラを指定します（89.9項「サーバー・プラットフォームの構成」を参照）。
詳細は、115.13項「作業ユニットと外部トランザクション・サービスの統合」を参照してください。
アプリケーションの管理と問題の診断を簡略化するために、Oracle Application ServerのManageability and Diagnosabilityに対するTopLinkのサポートを検討することをお薦めします。
詳細は、A.1項「Oracle Application ServerのManageability and Diagnosabilityに対するTopLinkのサポート」を参照してください。
TopLinkアプリケーションをIBM WebSphere Application Serverと統合するには、次のことを考慮する必要があります。
これらのIBM WebSphereアプリケーション・サーバー固有のオプションの構成を考慮するのみでなく、8.2項「TopLinkとアプリケーション・サーバーの統合」に記載の、アプリケーション・サーバーの統合に関する一般的な問題も考慮する必要があります。
使用するIBM WebSphereアプリケーション・サーバーのクラスパスは、そのサーバーのバージョンに応じて異なる手順で構成します。
TopLinkは、JTAおよび、IBM WebSphere Application Server 6.1以上の統合の一般的サポートを提供します。このバージョンのクラスパスを構成するには、次の手順を実行します。
次のToplink JARファイルを含む共有ライブラリを作成し、作成した共有ライブラリをアプリケーションに関連付けます。
<TOPLINK_HOME>\jlib\toplink.jar
TopLinkアプリケーションがXMLパーサー・プラットフォームを定義していることを確認します（8.2.2項「XMLパーサー・プラットフォームの構成方法」を参照）。
TopLink sessions.xmlまたはXMLプロジェクト・デプロイを使用するTopLink対応アプリケーションをデプロイしている場合、WebSphere Application Server管理コンソールを使用して「Class loader order」を「Class loaded with application class loader first」に設定する必要があります。
JTA統合を必要とするアプリケーションの場合、セッションでサーバー・プラットフォームを構成する際に外部トランザクション・コントローラを指定します（89.9項「サーバー・プラットフォームの構成」を参照）。
詳細は、115.13項「作業ユニットと外部トランザクション・サービスの統合」を参照してください。
TopLinkアプリケーションとアプリケーション・サーバーのクラスタとの統合に関する詳細は、8.2.5項「クラスタリングの統合方法」を参照してください。
TopLinkアプリケーションをSun Application Server（SunAS）と統合するには、次のことを考慮する必要があります。
これらのSunAS固有のオプションの構成を考慮するのみでなく、8.2項「TopLinkとアプリケーション・サーバーの統合」に記載の、アプリケーション・サーバーの統合に関する一般的な問題も考慮する必要があります。
TopLinkでのSunASのサポートを構成するには、次の手順に従います。
次のJARファイルをアプリケーション・サーバーのクラスパスに追加します。
<TOPLINK_HOME>\jlib\toplink.jar
TopLinkアプリケーションがXMLパーサー・プラットフォームを定義していることを確認します（8.2.2項「XMLパーサー・プラットフォームの構成方法」を参照）。
JTA統合を必要とするアプリケーションの場合、セッションでサーバー・プラットフォームを構成する際に外部トランザクション・コントローラを指定します（89.9項「サーバー・プラットフォームの構成」を参照）。
詳細は、115.13項「作業ユニットと外部トランザクション・サービスの統合」を参照してください。
TopLinkアプリケーションをJBoss Application Serverと統合するには、次のことを考慮する必要があります。
これらのJBoss固有のオプションの構成を考慮するのみでなく、8.2項「TopLinkとアプリケーション・サーバーの統合」に記載の、アプリケーション・サーバーの統合に関する一般的な問題も考慮する必要があります。
TopLinkでのJBossのサポートを構成するには、次の手順に従います。
次のJARファイルをアプリケーション・サーバーのクラスパスに追加します。
<TOPLINK_HOME>\jlib\toplink.jar
TopLinkアプリケーションがXMLパーサー・プラットフォームを定義していることを確認します（8.2.2項「XMLパーサー・プラットフォームの構成方法」を参照）。
JTA統合を必要とするアプリケーションの場合、セッションでサーバー・プラットフォームを構成する際に外部トランザクション・コントローラを指定します（89.9項「サーバー・プラットフォームの構成」を参照）。
詳細は、115.13項「作業ユニットと外部トランザクション・サービスの統合」を参照してください。
JPAアプリケーションの場合、コンテナを有効にしてエンティティを管理するには、エンティティを静的にウィービングし、persistence.xmlファイルでJBossをターゲット・サーバーとして参照します。次のデプロイの変更を実行してください。
ウィービングが必要な場合、EARのパッケージ化の前にエンティティを静的にウィービングします。コマンドラインのウィーバまたはweaving Antタスクを使用します（『EclipseLink Developer's Guide』の「How to Configure Static Weaving for JPA Entities」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#How_to_Configure_Static_Weaving_for_JPA_Entities）を参照）。
JBossコンテナにデプロイされているすべての永続性単位のpersistence.xmlファイルでeclipselink.target-serverプロパティ（『EclipseLink Developer's Guide』の「Using EclipseLink JPA Extensions for Session, Target Database and Target Application Server」（http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_%28ELUG%29#Using_EclipseLink_JPA_Extensions_for_Session.2C_Target_Database_and_Target_Application_Server）を参照）が設定されていることを確認します。
<property name="eclipselink.target-server" value="JBoss"/>
設定されていない場合は、コンテナ管理のエンティティが事前にデプロイされていても、それらのエンティティは実行時に管理されません。
詳細は、『EclipseLink Developer's Guide』の「How to Deploy an Application to Generic Java EE 5 Application Servers」（http://wiki.eclipse.org/Packaging_and_Deploying_EclipseLink_JPA_Applications_%28ELUG%29#How_to_Deploy_an_Application_to_Generic_Java_EE_5_Application_Servers）を参照してください。
デフォルトでは、デフォルトではないjava.lang.SecurityManagerで構成されたJVMでTopLink対応アプリケーションを実行すると、TopLinkランタイムは、java.security.AccessControllerメソッドdoPrivilegedでPrivilegedActionを実行して、特定の内部関数を実行します。これにより、TopLinkがその大部分の共通の操作を実行するために、TopLinkに多くのパーミッションを付与する必要がなくなります。使用するTopLink機能のオプションのタイプに応じて、特定のパーミッションを付与するのみで済みます（8.8.1項「TopLink機能で必要なパーミッションの定義方法」を参照）。
doPrivilegedメソッドを使用するとセキュリティが強化されますが、その一方で、全体的なパフォーマンスに重大な影響を及ぼします。このメソッドを使用しないようにするため、たとえデフォルトではないSecurityManagerが存在していても、doPrivilegedメソッドの使用を無効にするようにTopLinkを構成できます（8.8.3項「doPrivileged操作を無効にする方法」を参照）。この場合、必要なすべてのパーミッションをTopLinkに付与する必要があります（8.8.1項「TopLink機能で必要なパーミッションの定義方法」および8.8.2項「doPrivilegedを無効にする場合に必要なパーミッションの定義方法」を参照）。
|
注意: doPriviledgedメソッドの使用を有効にするとTopLinkアプリケーションのセキュリティは強化されますが、その一方で、システムが意図しない方法でアプリケーション・コードによりソース・コードをコールすることができない、というように保証されることがなくなります。doPriviledgedメソッドの使用は、アプリケーションの全体的セキュリティ方針の状況を考慮する必要があります。詳細は、http://java.sun.com/security/index.jspを参照してください。 |
デフォルトではないSecurityManagerのないJVMでTopLink対応アプリケーションを実行する場合は、パーミッションを付与する必要はありません。
デフォルトではないjava.lang.SecurityManagerで構成されたJVMでTopLink対応アプリケーションを実行し、doPrivileged操作を有効にする際、アプリケーションが次のいずれかを必要とする場合は、必要に応じて追加パーミッションを付与します。
デフォルトでは、TopLink対応アプリケーションは、デフォルトの<JAVA_HOME>/lib/security/java.policyファイルで付与されたシステム・プロパティへのアクセスを必要とします。アプリケーションが他のプラットフォーム固有のプロパティか、環境またはカスタムのプロパティへのアクセスを必要とする場合、例8-5で示されているようなPropertyPermissionパーミッションをさらに付与します。
大部分のTopLink対応アプリケーションは、project.xmlおよびsessions.xmlファイルを直接読み取ります。例8-6で示されているような特定のファイルまたはファイルの場所にパーミッションを付与します。この例では、project.xmlおよびsessions.xmlファイルの両方が同じディレクトリ（アプリケーション固有のシステム・プロパティdeployment.xml.homeで既定）に置かれていることを前提としています。あるいは、ファイルごとに独立したFilePermissionを指定することもできます。
例8-6 デプロイXMLファイルのロード用パーミッション
permission java.io.FilePermission "${deployment.xml.home}/*.xml", "read";
Java EEアプリケーションにおけるFilePermission設定の詳細は、8.8.1.6項「Java EEアプリケーション・デプロイのパーミッションの付与」を参照してください。
アプリケーションがキャッシュ・コーディネーション（102.3項「キャッシュ・コーディネーション」を参照）を使用する場合、例8-7で示されているように、コーディネートされたキャッシュにより使用される特定のソケットのaccept、connect、listenおよびresolveのパーミッションを付与します。この例では、コーディネートされたキャッシュのマルチキャスト・ポートが1024であることを前提としています（103.5項「マルチキャスト・ポートの構成」を参照）。
TopLink対応アプリケーションがソケットを使用してデータ・ソースにアクセスする場合、例8-8で示されているように、そのソケットのconnectおよびresolveパーミッションを付与します。この例では、データ・ソースを提供するリモート・ホスト（リレーショナル・データベース・サーバー・ホストなど）のホスト名（またはIPアドレス）が、アプリケーション固有のシステム・プロパティremote.data.source.hostによって指定され、このホストがポート1025でデータ・ソースの接続を受け入れることを前提としています。
例8-8 非Java EEデータ・ソース接続用パーミッション
permission java.net.SocketPermission "${remote.data.source.host}:1025-", "connect, resolve";
Java EEアプリケーションでは、データ・ソースのソケットのパーミッションは、通常アプリケーション・サーバーにより処理されます。
java.util.loggingパッケージ（89.4項「ロギングの構成」を参照）を使用するようにTopLink対応アプリケーションを構成する場合、例8-9で示されているようにcontrolパーミッションをアプリケーションに付与します。
TopLink対応Java EEアプリケーションをデプロイしている場合、次に対するパーミッションを付与する必要があります。
toplink.jarファイル。次に例を示します。
grant codeBase "file:<TOPLINK_HOME>/jlib/toplink.jar" {
permission java.security.AllPermission;
};
XMLプラットフォームを使用している場合、次のパーミッションも付与する必要があります。
toplink.xml.platformシステム・プロパティ。次に例を示します。
permission java.util.PropertyPermission "toplink.xml.platform", "read"
デフォルトではないjava.lang.SecurityManagerで構成されたJVMでTopLink対応アプリケーションを実行する場合に、doPrivileged操作を無効にするには、次のパーミッションを付与する必要があります。
java.lang.reflect.RelectPermission "suppressAccessChecks"
java.lang.RuntimePermission "accessDeclaredMembers"
java.lang.RuntimePermission "getClassLoader"
また、アプリケーションが使用するTopLink機能に応じて、パーミッションをさらに付与する必要があります。詳細は、8.8.1項「TopLink機能で必要なパーミッションの定義方法」を参照してください。
デフォルトではないjava.lang.SecurityManagerで構成されたJVMでTopLink対応アプリケーションを実行する場合に、doPrivileged操作を無効にするには、システム・プロパティoracle.j2ee.toplink.security.usedoprivilegedをfalseに設定します。OC4Jを使用している場合は、システム・プロパティoracle.j2ee.security.usedoprivilegedをfalseに設定します。
doPrivileged操作を有効にするには、これらのシステム・プロパティをtrueに設定します。
TopLinkは、次のEJB CMPオプションをカスタマイズするために使用できるシステム・プロパティを提供します。
Setterのパラメータ・タイプのチェック（8.9.1項「EJB CMPのSetterのパラメータ・タイプのチェックの構成方法」を参照）
不明な主キー・クラスのサポート（8.9.2項「EJB CMPの不明な主キー・クラスのサポートの構成方法」を参照）
シングル・オブジェクト・ファインダの戻りタイプのチェック（8.9.3項「EJB CMPのシングル・オブジェクト・ファインダの戻りタイプのチェックの構成方法」を参照）
1対1および1対多のリレーションシップのsetterのパラメータが、対応するCMRフィールドと同じタイプであることをTopLinkに検証させるには、システム・プロパティtoplink.cts.collection.checkParametersの値をtrue（大文字/小文字の区別はなし）に設定します。setterが同じタイプではない場合、TopLinkはjava.lang.IllegalArgumentExceptionをスローします。
|
注意: このプロパティをtrueに設定すると、パフォーマンスに影響を及ぼします。この設定は必要な場合にのみ使用してください。 |
プロパティをfalse（デフォルト値）に設定すると、TopLinkはこの検証を行いません。この場合、パラメータが正しいタイプであるかどうかの確認は、アプリケーション側で行う必要があります。
詳細は、EJB 2.1の仕様の10.3.6項を参照してください。
特殊な状況において、コンテナ管理の永続性を持つエンティティBeanに対して、主キー・クラスまたは主キー・フィールドを指定しないことを選択することがあります。たとえば、エンティティBeanに自然な主キーがない場合、またはデプロイ担当者にデプロイ時に主キー・フィールドを選択させる場合、主キー・タイプの指定を保留しておくことができます。
この場合、findByPrimaryKeyメソッドの引数のタイプをjava.lang.Objectとして宣言する必要があります。また、主キー・クラス（prim-key-class）をデプロイ・ディスクリプタ（ejb-jar.xml）にjava.lang.Objectとして指定することも必要です。
TopLinkは、そのような主キー・タイプの指定保留に対する実行時サポートを提供しています。
詳細は、EJB 2.1の仕様の10.8.3項を参照してください。
