Comments
Description
Transcript
IBM RAD V6.0
IBM Ｒａｔｉｏｎａｌ Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｖｅｌｏｐｅｒ Ｖ７.0 マイグレーション・ガイド ～RAD V6.0 からの移行～ 当資料は発行時点の情報に基づいて作成されていますが、事前の予告なく変 更される場合があります。 • IBM、WebSphere、DB2、ClearCase, Rational, Rational Application Developer は、IBM Corporation の商標。 • "Java" およびすべてのJava関連の商標およびロゴは Sun Microsystems, Inc.の米国およびその他の国における商標。 • 他の会社名、製品名およびサービス名等はそれぞれ各社の商標。 1 目次 1. はじめに ...............................................................................................................................................3 2. 製品のマイグレーション ......................................................................................................................3 3. ワークスペースおよびプロジェクトのマイグレーション ....................................................................4 4. 3.1. ワークスペースのマイグレーション ............................................................................................5 3.2. SCM システムからロードされたプロジェクトのマイグレーション............................................6 3.3. プロジェクト交換を使用してインポートされたプロジェクトのマイグレーション.....................7 3.4. データベース定義のマイグレーション ........................................................................................8 J2EE プロジェクトのマイグレーション............................................................................................14 4.1. 5. 4.1.1. EJB プロジェクトのマイグレーション時の考慮事項........................................................19 4.1.2. 下位互換性に関する考慮事項 ............................................................................................19 4.1.3. RAD V7 デバッガーの変更により対応が必要な点 ............................................................20 J2EE プロジェクトの仕様レベルのマイグレーション ......................................................................22 5.1. J2EE1.3 から 1.4 仕様レベルへのマイグレーション.................................................................23 5.1.1. Web プロジェクト(サーブレット 2.3 からサーブレット 2.4) ...........................................23 5.1.2. EJB プロジェクト (EJB 2.0 から EJB 2.1) ....................................................................25 5.1.3. コネクター・プロジェクト (JCA 1.0 から JCA 1.5) .......................................................31 5.1.4. Web サービス (J2EE 1.3 から J2EE 1.4).......................................................................32 5.1.5. セキュア Web サービスのマイグレーション .....................................................................35 5.2. 6. 考慮事項.....................................................................................................................................19 J2EE1.2 から 1.4 仕様レベルへのマイグレーション.................................................................36 5.2.1. Web プロジェクト(サーブレット 2.2 からサーブレット 2.4) ...........................................36 5.2.2. EJB プロジェクト (EJB 1.1 から EJB 2.1) ....................................................................37 Struts Web プロジェクトのマイグレーション ..................................................................................46 6.1. RAD V6.0 で作成した Struts Web プロジェクトのマイグレーション ......................................46 7. Web プロジェクトでの Faces ランタイム・リソースの更新...........................................................47 8. WAS V5.1 をターゲットとし、SDO を含む Web アプリケーションの マイグレーション .............52 2 1. はじめに 当資料では、IBM Rational Application Developer for WebSphere Software V6.0.x (以下 では RAD V6.0 または単に V6.0 と記述)を使用して J2EE アプリケーションの開発を行っ てきた開発者が、開発環境および開発対象のアプリケーションを IBM Rational Application Developer for WebSphere Software V7.0 (以下 RAD V7.0 または単に V7.0 と記述)に移行 させる際に必要となる手順および考慮事項を説明しています。また開発環境の移行にとも ない、J2EE アプリケーションを最新の API にマイグレーションするための手順および考 慮時奥についても説明しています。 なお、ターゲット・ランタイムを WebSphere® Application Server (以下では WAS と記述) V5/V5.1 から V6/V6.1 に変更する場合は、以下の資料もご参照ください。 z WebSphere Application Server Information Center 特にマイグレーションに関する各項 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp z IBM Redbook "WebSphere Application Server V6 Migration Guide" 特にPart 1. For application developersの各項 http://www.redbooks.ibm.com/abstracts/sg246369.html?Open 2. 製品のマイグレーション RAD V6.0 製品から RAD V7.0 製品へのマイグレーションを行う場合、RAD V6.0 の稼動す る同一のマシン上に RAD V7.0 を導入し、同時に稼動させることが可能です。 この場合は、以下の点に注意してください： z RAD V6.0 に付属する IBM Agent ControllerV6 は、RAD V7.0 では使用できません。 また異なるバージョンの IBM Agent Controller を同一端末に導入することはできませ ん。したがって、RAD V7.0 をインストールする前に、RAD V6.0 付属の IBM Agent Controller V6 を ア ン イ ン ス ト ー ル し 、 改 め て RAD V7.0 付 属 の IBM Agent ControllerV7.0.1 を導入してください。 z それぞれの製品に付属する WAS テスト環境は、それぞれ別のディレクトリーに導入さ れますが、デフォルトではアプリケーション・サーバーの使用するポート番号が共通 となります。同一のポートを使用する WAS プロセスを同時に使用することはできませ ん。 3 ワークスペースおよびプロジェクトのマイグレーション 3. ここでは、V6.0 から V7.0 へのマイグレーションの基本的な流れについて説明します。詳細につい ては後述のトピックおよび製品のヘルプを参照してください。 手順 ①V7.0 と V6.0 との互換性について理解します。 V7.0 で任意の V6.0 ワークスペースを初めて開くとき、そのワークスペースは自動的にマイグレーシ ョンされます。一度マイグレーションしたワークスペースは、前のバージョンの製品では開けなくなり ます。しかし、V7.0 にマイグレーションされたこのワークスペース内のプロジェクトはそのまま V6.0 と 共用できます。 ②V6.0 ワークスペースのバックアップをとります。 ③V6.0 から V7.0 にワークスペースおよびプロジェクトをマイグレーションする V6.0 から V7.0 にワークスペースおよびプロジェクトをマイグレーションするには、以下の３つの方 法があります。（詳細は後述します） a．ワークスペースのマイグレーション b．SCM システムからロードされたプロジェクトのマイグレーション c．プロジェクト交換を使用してインポートされたプロジェクトのマイグレーション ④V6.0 に任意のベンダーのプラグインをインストールしている場合は、V7.0 に対応するプラグイン を入手してインストールする必要があります。 ⑤エージェント・コントローラーが必要な機能を使用している場合は、 V7.0 で提供されているバー ジョンをインストールしてアップグレードします。 注意： ■古いビルダーを使用できない V7.0 に、V6.0 で作成されたプロジェクトがロードされた場合、「ビルダ ーの欠落」に関するメッセージが表示されたり、ログに記録されたりする場合があります。これらのメッセー ジは正常ですので、無視してかまいません。 ■マイグレーションの際、各 V6.0 プロジェクトについて、V7.0 のプロジェクト・フォルダーに自動的 に .compatibility ファイルが追加されます。このファイルは V6.0 との下位互換性の目的で使用するた め、編集したり削除したりしないでください。 ■マイグレーション中のワークスペースと関連したデバッグ起動構成がある場合、一部の起動構成が自 動的にマイグレーションされません。 4 3.1. ワークスペースのマイグレーション V6.0 ワークスペースを永続的にマイグレーションする準備が整ったら、そのワークスペースを V7.0 で開始します。 手順 ①RAD V7 を起動します。 「スタート」＞「すべてのプログラム」＞「IBM Software Development Platform」＞「IBM Rational Application Developer」＞「IBM Rational Application Developer」 ②ワークスペース・ランチャーで V6.0 のワークスペースを指定し、「OK」をクリックします。 ③ワークスペースのマイグレーション中、下のような「エラー」ダイアログ・ボックスが開いたら、「OK」 をクリックしてダイアログ・ボックスを閉じます。 （このエラー・メッセージは、ワークスペースのマイグレーションの成功には影響ありません。） ④「ウィンドウ」＞「パースペクティブのリセット」でパースペクティブをリセットます。 5 3.2. SCM システムからロードされたプロジェクトのマイグレーション SCM システム（CVS,IBM Rational Clear Case などのソース・コード管理システム）に 存在する V6.0 のプロジェクトは、V7.0 へのロード時に自動的に V7.0 にマイグレーショ ンされます。 手順 （例：CVS からのプロジェクトのチェックアウト） ①CVS リポジトリー･エクスプローラーを開きます。 「ウィンドウ」＞「パースペクティブを開く」＞「その他」で CVS リポジトリー・エクスプローラーを選択 ②CVS リポジトリー・エクスプローラーでリポジトリーからプロジェクトをチェックアウトします。 V6.0 のプロジェクトを右クリックして「チェックアウト」を選択 6 3.3. プロジェクト交換を使用してインポートされたプロジェクトのマイグレーション プロジェクト交換フィーチャーを使用して V6.0 からエクスポートされ V7.0 にインポートされるプロ ジェクトは、自動的に V7.0 にマイグレーションされます。 手順 ①「ファイル」＞「インポート」で「その他」＞「プロジェクト交換」を選択して「次へ」 ②6.0 でエクスポートされたプロジェクトを選択し、インポートする 7 3.4. データベース定義のマイグレーション WSAD V5.1.2 および RAD V6.0.x で作成されたデータベース定義をサポートするツール に変更があったため、最新のツールと互換性を持つように既存のデータ・プロジェクト を マイグレーションする必要があります。 V7.0 で既存ワークスペースを開く、ソース・コード管理 (SCM) システムからプロジェク トをインポートする、またはプロジェクト交換を使用してプロジェクトをインポートする、 といった操作を実行しても、データ・プロジェクトが自動的にマイグレーションされるこ とはありません。既存のデータ・プロジェクトは、特殊なデータベース・プロジェクト・ マイグレーション用ウィザードを使用してインポートします。 V7.0 ワークスペースにデータベース定義をインポートする際、インポートするリソースの ターゲットとして、以下の 2 つのタイプのデータ・プロジェクトから 1 つを選択します。 データ設計プロジェクト データベースの設計および情報の統合に使用されます。このタイプのプロジェクトには、 物理データ・モデル、論理データ・モデル、ドメイン・モデル、用語集モデル、XSD モデ ル、およびスクリプトが保管されます。 データ開発プロジェクト DB2® のストアード・プロシージャーおよびユーザー定義関数、Derby のストアード・プ ロシージャー、および SQL ステートメントを開発するために使用されます。開発プロジ ェクトは「データベース・エクスプローラー」ビューで接続と関連付けられているため、 ユーザーがデータベースのメタデータをプロジェクトにコピーする必要はありません。 注意： 両方のターゲット・プロジェクト・タイプを作成したい場合、またはデータ開発プロジェクトに 複数のソース・データベースをマイグレーションしたい場合には、既存のデータベース定義に対 してインポート・ウィザードを複数回実行できます。ソース・データベース・プロジェクトは、 マイグレーション・ウィザードの影響を受けません。 8 定義プロジェクトを V7.0 ワークスペースにインポートするには、次のようにします。 手順 ① 「ファイル」 > 「インポート..」をクリックし、 「次へ」をクリックします。 ② 「一般」フォルダーを展開し、「既存の RAD 6.x データ定義プロジェクト」をク リックしてから、「次へ」をクリックします。 ③ 新規ページの「マイグレーションするプロジェクト・フォルダーの選択」フィー ルドに、インポートするデータベース・プロジェクトのパスおよびフォルダー名 を入力します。 「既存のプロジェクト接続を 1 つ選択」フィールドに、プロジ ェクトの接続の名前が表示されます。接続が見つからない場合には「接続なし」 と表示されます。これは、ソース・ワークスペースに誤りがあるか、選択したフ ォルダーにデータベース接続が記述されていないことを示します。 9 ④ 「既存のプロジェクト接続を 1 つ選択」フィールド内で、接続を 1 つクリック します。 ⑤ 「ターゲット・プロジェクト・タイプの選択」で、インポートするリソースのタ ーゲット・プロジェクトとして、「データ設計プロジェクト」もしくは「データ開 発プロジェクト」のいずれかを選択し、ウィザード内の各ステップを実行します。 • 「データ設計プロジェクト」を選択した場合のステップ ①「ターゲット・プロジェクト・タイプの選択」で「データ設計プロジェクト」 を選択し、「次へ」 • ②プロジェクト名を指定して「終了」 （ロケーションの指定も可能） 10 • 「データ開発プロジェクト」を選択した場合のステップ ①「ターゲット・プロジェクト・タイプの選択」で「データ開発プロジェクト」 を選択し、「次へ」 ②プロジェクト名など、新規作成するプロジェクトの基本定義を行って「次へ」 11 ③「新規接続の作成」もしくは「既存の接続を使用」を選択します。 ■「既存の接続を使用」選択する場合は、該当する接続を選択して「終了」をク リックします。 ■「新規接続の作成」を選択する場合は「次へ」をクリックします。 12 DB への接続パラメータの定義を行いさらに「次へ」をクリックします。 必要に応じてスキーマ･フィルターの指定を行い、「終了」をクリックします。 注意： 新しいバージョンのデータベースへの接続を選択する必要のある場合があります。 V5.1.2 およ び V6.0.x でサポートされているすべてのデータベースが、V7.0 でサポートされているわけで はありません。マイグレーション・ウィザードは、既知のターゲット接続がサポートされている ものであれば、その接続に対してソース接続をマッチングさせます。サポートされていない接続 である場合には、新規接続ウィザードを初期化します。新規接続ウィザードには、サポートされ るデータベースのバージョンがリストされます。 13 J2EE プロジェクトのマイグレーション 4. RAD V6.0 の J2EE プロジェクトは、基本的には RAD V7.0 にロードすると、自動的にマ イグレーションが行われ、そのままプロジェクトを使用することが可能となります。 ただし、環境の違いによって未解決のクラスパス・エラーなどのコンパイル・エラーが表 示され、そのままではプロジェクトのビルドおよび実行ができなくなることがあります。 この場合は、次のステップによって、コンパイル・エラーを解決する必要があります。 手順 ターゲット・ランタイムおよび Java のビルド・パスを確認し、必要な場合は再設定し ① ます。 ② 不完全なビルド・パスの Java コンパイラー設定を「警告」に変更します。 ③ プロジェクト・クリーンを実行します。 以下でこれらを詳しく説明します。 ターゲット・ランタイムの確認と再設定 RAD V6.0 で作成した J2EE プロジェクトのターゲット・ランタイムは RAD V7.0 にロー ドすると受け継がれますが、RAD V6.0 においてターゲット・ランタイムが正しく設定され ていなかった場合などに、RAD V7.0 ではエラーが表示されることがあります。この場合、 そのプロジェクトを使用する前に、ターゲット・ランタイムを再設定する必要があります。 (例えば、「クラスパスのアンバインド」などのエラーが表示されることがあります)。以下 の手順でターゲット・ランタイムの確認および設定を行ってください。 手順 ① J2EE プロジェクトを右クリックして「プロパティー」を選択します。 ② プロパティーのリストで「ターゲット・ランタイム」をクリックします。 ③ 「ターゲット・ランタイム」について、そのプロジェクトに適したターゲット・ラン タイムを選択されていることを確認します。 (例えば、WebSphere® Application Server v6.0 など。) 14 ④ 「適用」をクリックしてから「OK」をクリックします。 Java のビルド・パスの確認と再設定 プロジェクトを正しくビルドするには、設定したターゲット・ランタイムに適合したビル ド・パスが設定されている必要があります。以下の手順で確認および再設定を行います。 手順 ① J2EE プロジェクトを右クリックして「プロパティー」を選択します。 ② プロパティーのリストで「Java のビルド・パス」をクリックし、右側のペインで「ラ イブラリー」のタブを選択します。 ③ 「JRE システム・ライブラリー」が存在しない場合や、選択したターゲット・ランタ 15 イムと一致していない場合はこれを除去し、以下の手順で正しい JRE システム・ライ ブラリーを選択します。 1. 「ライブラリーの追加」ボタンを押します。 2. 「JRE システム・ライブラリー」を選択し、「次へ」をクリックします。 3. 「代替 JRE」のリストから、ターゲット・ランタイムに合致する JRE を選択し、 「終了」をクリックします。 ④ 「サーバー・ランタイム」が存在しない場合や、選択したターゲット・ランタイムと 一致していない場合はこれを除去し、以下の手順で正しい JRE システム・ライブラリ ーを選択します。 1. 「ライブラリーの追加」ボタンを押します。 16 2. 「サーバー・ランタイム」を選択し、「次へ」をクリックします。 3. サーバー・ランタイムのリストから、ターゲット・ランタイムに合致するランタ イムを選択し、「終了」をクリックします。 ⑤ 「OK」をクリックします。 不完全なビルド・パスの Java コンパイラー設定の変更 不完全なビルド・パスの Java コンパイラー設定を「警告」に変更するには、次のように します。 手順 17 「ウィンドウ」 > 「設定...」をクリックします。 「設定」ウィンドウが開きます。 ① ② 左側で「Java」を展開してから、「コンパイラー」を展開して、「ビルド」をクリック します。 ③ 「設定」ウィンドウの左側にある「ビルド・パスの問題」の下で、「不完全なビルド・ パス:」のドロップダウン・リストの選択項目を「警告」に変更します。 ④ 「適用」をクリックします。 ⑤ 以下のダイアログが開きますので、 「はい」をクリックして、フル・ビルドを実行しま す。 プロジェクト・クリーンの実行 プロジェクト・クリーンを実行するには、次のようにします。 手順 ① メインメニューで、「プロジェクト」 > 「クリーン...」をクリックします。 ② 「クリーン」ウィンドウで、「以下で選択したプロジェクトをクリーン」を選択して、 リストでプロジェクトを選択してから「OK」をクリックします。 18 プロジェクトのクリーンを行うと、残りのコンパイラー・エラーは解決するはずです。 考慮事項 4.1. 4.1.1. EJB プロジェクトのマイグレーション時の考慮事項 RAD V6.0 からプロジェクト交換によってエクスポートされたファイルには、デフォルトで は、生成された EJB のデプロイ・コードが含まれていません。したがって、RAD V7.0 に インポートした後に、デプロイメント・コードの生成を行うか、あるいは、プロジェクト 交換のエクスポート時に下記のように「Include derived files.」にチェックを入れる必要が あります。 4.1.2. 下位互換性に関する考慮事項 RAD V6.0 で作成され、RAD V7.0 ワークスペースにロードされたプロジェクトは、RAD V6.0 と共用可能ですが、以下の手順によって互換性を除去することが可能です。 下位互換性は、そのエンタープライズ・アプリケーション・プロジェクトが旧バージョン との相互運用性や互換性を以後必要としないことが確実である場合にのみ使用不可に設定 してください。 下位互換性を除去する方法は、次のとおりです。 手順 ① エンタープライズ・アプリケーション・プロジェクトを右クリックし、ポップアップ 19 から「互換性の除去」メニュー・オプションを選択する。 ② エンタープライズ・アプリケーション・プロジェクトの下位互換性の除去について確 認を求めるダイアログが表示されます。 ③ 「はい」をクリックして、互換性の除去操作を継続します。 互換性の除去操作が実行されると、エンタープライズ・アプリケーション・プロジェクト とエンタープライズ・アプリケーション・プロジェクトの下にネストされたすべてのモジ ュールおよびユーティリティー・プロジェクトは、RAD V6.0 と下位互換性がなくなります。 4.1.3. RAD V7 デバッガーの変更により対応が必要な点 RAD V7.0 では、デバッグ・ツールに多くの変更点があります。 RAD V6.0 からのマイグ レーション後に、プロジェクトでデバッグ・ツールを使用するためには、これらの変更点 を認識しておく必要があります。設定の変更または復元が必要な場合があります。 ワークスペースおよび起動構成のマイグレーション V5.1.2 または V6.0 のワークスペースを V7.0 で開いた際には、このワークスペースに関 連付けられた次のデバッガー起動構成は自動的にマイグレーションされません。 サーバーでデバッグ 「サーバーでデバッグ」アクションで以前に作成した起動構成は、 V7.0 にはマイグレー ションされません。 V7.0 で、サーバーでデバッグを行うためにアプリケーションを起動 するには、アプリケーションを選択し直して「サーバーでデバッグ」を選択します。これ により、そのアプリケーションの新規起動構成が作成されます。 サーバー接続 サーバー接続のために以前に作成された WebSphere® Application Server デバッグ起動 構成は、自動的に V7.0 にマイグレーションされません。以前の WebSphere Application Server デバッグ起動構成を機能させるには、その旧起動構成をダブルクリックして開き、 「ホスト名」 、 「JVM デバッグ・ポート」、および「WebSphere Application Server のバー ジョン」を指定します。 20 SQLJ デバッガー SQLJ デバッグ起動構成は存在しなくなりました。以前に作成した SQLJ 起動構成は V7.0 にマイグレーションされません。 V7.0 でデバッグを行うために SQLJ プログラム を起動するには、 Java™ アプリケーションの起動構成を使用してください。 ストアード・プロシージャー・デバッガー 以前に作成したストアード・プロシージャー・デバッガー起動構成は、V7.0 にマイグレー ションされません。 DB2® ストアード・プロシージャーをデバッグする際には、新規の起 動構成を作成する必要があります。 XSL 変換デバッガー 旧バージョンで作成された XSL 変換デバッガー起動構成は、V7.0 にマイグレーションさ れません。 XSL 変換をデバッグする際は、新規の起動構成を作成する必要があります。 21 J2EE プロジェクトの仕様レベルのマイグレーション 5. RAD V7.0 の J2EE マイグレーション・ウィザードによって、すべての J2EE モジュール・ タイプのプロジェクトについて、 J2EE 1.2 と 1.3 仕様両方からの J2EE 1.4 仕様レベル へのマイグレーションが可能です。 注意：マイグレーション・ウィザードを使用する前に、以下のステップを実行するよう強くお勧めします。 手順 ① ワークスペース全体をバックアップする。 ② 共用リポジトリーの作業を行っている場合は、対応するすべてのプロジェクトをチェ ックアウトまたはロックする。 以下のようにして J2EE マイグレーション・ウィザードにアクセスできます。 手順 ① J2EE パースペクティブの「プロジェクト・エクスプローラー」ビューで、マイグレ ーション対象のエンタープライズ・アプリケーション・プロジェクトを右クリックし ます。 ② ポップアップ・メニューから 「マイグレーション」 > 「J2EE マイグレーション・ ウィザード」の順に選択します。 ③ J2EE マイグレーション・ウィザードの「ようこそ」ページの指示に従って、マイグ レーション・プロセスを進めます。 注 以下の移行では手動によるマイグレーション作業が必要となりますので、それぞれの該当 するページを参照してください。 z J2EE 1.3 から 1.4 へのマイグレーションでは、メッセージ駆動型 Bean およびセキュ ア Web サービス のマイグレーションについて、手動のステップが必要です。 z J2EE 1.2 から 1.4 へのマイグレーションでは、EJB1.1 のコンテナー管理パーシステ ンス(CMP)を EJB2.1 にマイグレーションする際、手動のステップが必要です。 RAD V7 J2EE マイグレーション・ウィザードには、以前のバージョンからの変更がありま す。変更点については、オンライン・ヘルプの「V7.0 での J2EE マイグレーション・ウ ィザードの変更」を参照してください。 22 J2EE1.3 から 1.4 仕様レベルへのマイグレーション 5.1. RAD V7.0 の J2EE マイグレーション・ウィザードを使用して、J2EE 1.3 仕様レベルの J2EE プロジェクトを J2EE 1.4 仕様レベルにマイグレーションすることができます。この セクションでは、J2EE マイグレーション・ウィザードにより J2EE 1.3 から J2EE 1.4 に マイグレーションされる成果物について、J2EE プロジェクトのタイプごとに、説明します。 Web プロジェクト(サーブレット 2.3 からサーブレット 2.4) 5.1.1. J2EE マイグレーション・ウィザードによって、J2EE 1.3 レベルの Web プロジェクトが J2EE 1.4 にマイグレーションされると、サーブレットのレベルも 2.3 から 2.4 にマイグレ ーションされます。このとき、Web デプロイメント記述子(web.xml)に対して以下の変更 が行われます。 TagLib J2EE 1.3 の web.xml の、taglib オブジェクトは、J2EE 1.4 では jsp-config オブジェク トに移動されます。Taglib オブジェクトは、 J2EE 1.3 では web-app オブジェクトに直 属していました。 移行前： <web-app id="WebApp"> … <taglib> <taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri> <taglib-location>/WEB-INF/struts-bean.tld</taglib-location> </taglib> … </web-app> 移行後： <?xml version="1.0" encoding="UTF-8"?> <web-app id="WebApp_ID" version="2.4"… … <jsp-config> <taglib> <taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri> <taglib-location>/WEB-INF/struts-bean.tld</taglib-location> </taglib> 23 … </jsp-config> </web-app> Description マイグレーション・ウィザードは、Web デプロイメント記述子(web.xml)で記述されてい る EJB 参照、セキュリティ参照など多くの項目の「説明(description)」を移行しません。 アプリケーションの実行には影響しませんが、必要な場合は再度設定が必要となります。 24 EJB プロジェクト (EJB 2.0 から EJB 2.1) 5.1.2. J2EE マイグレーション・ウィザードによって、J2EE 1.3 レベルの EJB プロジェクトが J2EE 1.4 にマイグレーションされると、EJB の仕様レベルも 2.0 から 2.1 にマイグレーシ ョンされます。このとき、ステートレス・セッション Bean およびメッセージ駆動型 Bean に対し、以下の変更が行われます。J2EE 1.3 と J2EE 1.4 仕様レベルの間ではエンティテ ィ Bean には変更はありません。 セッション Bean のマイグレーション J2EE マイグレーション・ウィザードは、EJB プロジェクトのステートレス・セッション Bean が Web サービスを提供している場合（EJB プロジェクトの webservices.xml 記述 子に service endpoint interfaces (SEI) として定義されている場合）に、以下のマイグレ ーションを行います。 J2EE 1.4 仕様では、セッション Bean が Web サービスのエンドポイントとして使用さ れる場合、SEI がこのステートレス・セッション Bean に定義されている必要があります。 EJB JAR ファイルのマイグレーション中、 EJB プロジェクトの webservices.xml 記述 子で使用されているすべてのセッション Bean に対して、サービス・エンドポイントが設 定されます。以下は、 J2EE 1.4 仕様レベルへのマイグレーションの前と後で EJB プロ ジェクトのメタデータがどのように変化するかについて例を示したものです。 J2EE 1.3 の EJB プロジェクトの webservices.xml (マイグレーション前) 以 下 の 例 で は 、 webservices.xml 記 述 子 の <service-endpoint-interface> タ グ と <service-impl-bean> タグが、J2EE 1.3 仕様レベルの webservices 記述子のサービス・ エンドポイントとしてステートレス・セッション Bean「EchoEJB」を定義しています。 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN" "http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd"> <webservices id="WebServices_1084831328093"> <webservice-description id="WebServiceDescription_1084831328093"> <webservice-description-name>EchoEJBService</webservice-description-name> <wsdl-file>META-INF/wsdl/EchoEJB.wsdl</wsdl-file> <jaxrpc-mapping-file>META-INF/EchoEJB_mapping.xml</jaxrpc-mapping-file> <port-component id="PortComponent_1084831328103"> <port-component-name>EchoEJB</port-component-name> 25 <wsdl-port id="WSDLPort_1084831328103"> <namespaceURI>http://test</namespaceURI> <localpart>EchoEJB</localpart> </wsdl-port> <service-endpoint-interface>test.EchoEJB</service-endpoint-interface> <service-impl-bean id="ServiceImplBean_1084831328103"> <ejb-link>EchoEJB</ejb-link> </service-impl-bean> </port-component> </webservice-description> </webservices> J2EE 1.4 の EJB プロジェクトの ejb-jar.xml (マイグレーション後) 以下の EJB デプロイメント記述子(ejb-jar.xml)では、<service-endpoint> タグが、ステー トレス・セッション Bean「EchoEJB」を J2EE 1.4 仕様レベルのサービス・エンドポイ ントとして定義しています。 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE ejb-jar> <ejb-jar id="ejb-jar_ID" version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd"> <display-name>EchoEJBProject</display-name> <enterprise-beans> <session id="EchoEJB"> <ejb-name>EchoEJB</ejb-name> <home>test.EchoEJBHome</home> <remote>test.EchoEJB</remote> <service-endpoint>test.EchoEJB</service-endpoint> <ejb-class>test.EchoEJBBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> </ejb-jar> 26 メッセージ駆動型 Bean のマイグレーション J2EE マイグレーション・ウィザードは、 メッセージ駆動型 Bean の EJB 2.0 から EJB 2.1 へのマイグレーションをサポートします。 メッセージ駆動型 Bean は、Java™ Message Service (JMS) からの非同期メッセージの処 理をサポートするために、EJB 2.0 で導入されました。EJB 2.1 仕様は、JMS だけでなく、 あらゆるメッセージング・システムをサポートできるように、メッセージ駆動型 Bean の 定義を拡張しました。 注意： 仕様レベルが EJB 2.0 から EJB 2.1 にマイグレーションされ、WAS V6/V6.1 にデプロイされるメッセ ージ駆動型 Bean は、(WAS V5 で使用されていた) リスナー・ポートではなく Java Connector Architecture (JCA) 1.5 のリソース・アダプターにデプロイする必要があります。 EJB 2.1 メッセージ 駆動型 Bean で JCA アダプターを使用するには、デプロイメント記述子エディターを使用して WebSphere バインディングの設定を変更する必要があります。下記の『JCA アダプターを使用するた めの EJB 2.1 メッセージ駆動型 Bean の構成』の手順に従ってください。 マイグレーションされる EJB 2.0 メッセージ駆動型 Bean の成果物は以下の通りです。 z acknowledgeMode z messageSelector z destinationType z subscriptionDurablity EJB 2.0 メッセージ駆動型 Bean 要素の一部は、 activation-config プロパティーに置換 されました。メッセージング・サービスを記述するために activation-config プロパティー で使用されるプロパティー名と値は、使用されるメッセージ・サービスのタイプによって 異なります。ただし、EJB 2.1 は JMS ベースのメッセージ駆動型 Bean に対して固定さ れたプロパティーのセットを定義します。 以下の例は、EJB 2.0 のサンプル Bean の要素が EJB 2.1 でどのように表示されるかを 比較したものです。 27 EJB 2.0 でのメッセージ駆動型 Bean 要素の例: <message-driven id="Mdb20"> <ejb-name>Mdb</ejb-name> <ejb-class>ejbs.MdbBean</ejb-class> <transaction-type>Bean</transaction-type> <message-selector>mdbMessage</message-selector> <acknowledge-mode>Auto-acknowledge</acknowledge-mode> <message-driven-destination> <destination-type>javax.jms.Topic</destination-type> <subscription-durability>Durable</subscription-durability> </message-driven-destination> </message-driven> EJB 2.1 でのメッセージ駆動型 Bean 要素の例: <message-driven id="Mdb21"> <ejb-name>Foo/ejb-name> <ejb-class>ejbs.FooBean</ejb-class> <messaging-type>javax.jms.MessageListener</messaging-type> <transaction-type>Bean/transaction-type> <message-destination-type>javax.jms.Topic</message-destination-type> <activation-config> <activation-config-property> <activation-config-property-name>destinationType </activation-config-property-name> <activation-config-property-value>javax.jms.Topic </activation-config-property-value> </activation-config-property> <activation-config-property> <activation-config-property-name>subscriptionDurability </activation-config-property-name> 28 <activation-config-property-value>Durable</activation-config-property-value> </activation-config-property> <activation-config-property> <activation-config-property-name>acknowledgeMode </activation-config-property-name> <activation-config-property-value>AutoAcknowledge </activation-config-property-value> </activation-config-property> <activation-config-property> <activation-config-property-name>messageSelector </activation-config-property-name> <activation-config-property-value>fooSelector </activation-config-property-value> </activation-config-property> </activation-config> </message-driven> JCA アダプターを使用するための EJB 2.1 メッセージ駆動型 Bean の構成 Enterprise Java™ Bean (EJB) 2.0 から EJB 2.1 仕様レベルにマイグレーションされて、 WAS V6 にデプロイされたメッセージ駆動型 Bean は、リスナー・ポートの代わりに、Java Connector Architecture (JCA) 1.5 リソース・アダプターに対してデプロイされる必要があ ります。 次のステップでは、JCA アダプターを使用するように EJB 2.1 メッセージ駆動型 Bean のデプロイメント記述子を変更する方法を説明します。 手順 ① プロジェクト・エクスプローラーで EJB プロジェクトを開きます。 ② プロジェクト・エクスプローラーでその EJB プロジェクトの「デプロイメント記述 子 (Deployment Descriptor)」ファイルをダブルクリックします。 EJB デプロイメン ト記述子エディターが開きます。 ③ 「Bean」タブをクリックして「Bean」ページを開きます。 ④ EJB プロジェクト内の EJB 2.1 メッセージ駆動型 Bean ごとに、以下を実行します。 1. 「Bean」ページの左側にある Bean のリストで、EJB 2.1 メッセージ駆動型 Bean を選択します。 2. 「WebSphere バインディング」のヘッダーの下で「JCA アダプター」ボタンを 29 選択します。 3. 以下のバインディング・デプロイメント・プロパティーを指定します。 (ア) 「ActivationSpec JNDI 名」 このメッセージ駆動型 Bean をデプロイするのに使用される J2C 活動化仕様の JNDI 名を入力します。この名前は、 WAS に対して定義する J2C 活動化仕様の 名前と一致する必要があります。 (イ) 「ActivationSpec 許可の別名」 JCA リソース・アダプターへの接続を認証するために使用される J2C 認証別名 の名前です。 J2C 認証別名により、JCA リソース・アダプターへの新しい接続 の作成を認証するのに使用されるユーザー ID とパスワードが指定されます。 (ウ) 「宛先 JNDI 名」 メッセージ駆動型 Bean が JNDI 名前空間で JMS 宛先を検索するのに使用す る JNDI 名を入力します。 ⑤ 変更を保管して、デプロイメント記述子エディターを閉じます。 30 コネクター・プロジェクト (JCA 1.0 から JCA 1.5) 5.1.3. J2EE マイグレーション・ウィザードは、J2EE Connector Architecture (JCA) 1.0 プロジ ェクトの記述子を JCA 1.5 にマイグレーションします。マイグレーションされた成果物は、 OutboundResourceAdaptor と ConnectionDefinition という 2 つの新規オブジェクト と同様に、ResourceAdaptor オブジェクトの要素に関連付けられます。これらはコネクタ ー・プロジェクトの J2EE 1.4 仕様レベルで ResourceAdaptor オブジェクトに追加され ました。 以下はマイグレーション済み要素のマッピングについての説明です。 z 以下の要素は、ResourceAdaptor オブジェクトから OutboundResourceAdaptor オ ブジェクトに移動されます。 z ¾ reauthenticationSupport ¾ transactionSupport 以下の要素は、ResourceAdaptor オブジェクトから ConnectionDefinition オブジェ クトに移動されます。 z ¾ managedConnectionFactoryClass ¾ connectionFactoryInterface ¾ connectionFactoryImplClass ¾ connectionInterface ¾ connectionImplClass outboundResourceAdaptor オブジェクトには、ConnectionDefinition 定義のリスト が含まれます。ConnectionDefinition は、 OutboundResourceAdaptor によって保持 されている ConnectionDefinition リストに追加されます。 z OutboundResourceAdaptor オブジェクトは、 ResourceAdaptor オブジェクトに含 まれます。 z AuthenticationMechanism オブジェクトは JCA 1.5 でいくつかの変更がありました。 customAuthMechType 要 素 が authenticationMechanism に 置 換 さ れ 、 authenticationType 要素が authenticationMechanism に置換されました。 z ResourceAdaptor オブジェクトの description 属性は Description オブジェクトに 置換され、そこで description 属性ストリングが以下のオブジェクトの Description オブジェクトの値要素に設定されます。 ¾ SecurityPermission ¾ AuthenticationMechanism ¾ ConfigurationProperties 31 5.1.4. Web サービス (J2EE 1.3 から J2EE 1.4) J2EE 1.4 仕様では、新規 JAX-RPC 1.0 API を介した Web サービスへのサポートが追加 されました。JAX-RPC API は以下を通じてサービス・エンドポイントをサポートします。 z JAXR-RPC のサーブレット z 直接 SOAP を持つサーブレット z ステートレス・セッション Bean J2EE 1.4 仕様は、J2EE 仕様 (JSR 109) に対する Web サービスをサポートします。JSR 109 は Web サービスのデプロイメント要件を定義して、 JAX-RPC プログラミング・モ デルを使用します。 以下の Web サービス成果物が J2EE マイグレーション・ウィザードを使用してマイグレ ーションされます。 z Web サービス記述子 z Web サービス・クライアント記述子 z JAX-RPC マッピング記述子 なお、ステートレス・セッションBeanに関連するＷｅｂサービスのマイグレーションにつ いては、「5.1.2 EJBプロジェクト」の「セッション Bean のマイグレーション」の節を参 照してください。 Web サービス・デプロイメント記述子のマイグレーション J2EE 1.4 仕様レベルにマイグレーションされる J2EE 1.3 プロジェクトに含まれた Web サービスのデプロイメント記述子は、JSR-109 V1.0 (J2EE 1.3 の場合) から J2EE 1.4 に マイグレーションされます。 Web サービス・デプロイメント記述子は、JSR-109 V1.0 で定義されているように、 webservices.xml ファイルと webservicesclient.xml ファイル、および webservices.xml ファイルと webservicesclient.xml ファイルが参照するすべての JAX-RPC マッピン グ・デプロイメント記述子で構成されています。他の J2EE デプロイメント記述子と同様 に、マイグレーションにより、記述子に含まれている情報の構造は J2EE 1.4 仕様に準拠 するように変更されます。Web サービス・デプロイメント記述子に固有の 1 つの構造上 の 変 更 は 、 修 飾 名 の 表 記 方 法 に 対 す る 変 更 で す 。 JSR-109 V1.0 で は 、 修 飾 名 は <namespaceURI> と <localpart> という、それぞれネーム・スペース URI と名前のロ ーカル・パートを含む、2 つの要素のシーケンスを使用して表記されていました。 J2EE 1.4 32 での修飾名は、XML ネーム・スペースを使用する XMLSchema QName タイプを基にし ています。 以下では各 Web サービス・デプロイメント記述子のマイグレーションについてさらに詳し く説明します。 Web サービス記述子 (webservices.xml) webservices.xml デプロイメント記述子は、J2EE Web サービスを含む Web プロジェク トと EJB プロジェクトにあります。<wsdl-port> 要素と <soap-header> 要素はいずれも 修飾名を含んでおり、これらのコンテンツは J2EE 1.4 フォーマットにマイグレーション されます。 例えば、<wsdl-port> がマイグレーション前に次のように表記されている場合、 <wsdl-port> <namespaceURI>http://addressbook.webservice</namespaceURI> <localpart>AddressBook</localpart> </wsdl-port> マイグレーション後、<wsdl-port> の表記は次のようになります。 <wsdl-port xmlns:pfx="http://addressbook.webservice">pfx:AddressBook</wsdl-port> 接頭部 "pfx" が、マイグレーションされるすべての修飾名のネーム・スペース接頭部とし て使用されます。 Web サービス・クライアント記述子 (webservicesclient.xml) webservicesclient.xml デプロイメント記述子は、 J2EE Web サービス・クライアントを 含む J2EE 1.3 Web プロジェクト、EJB プロジェクト、およびアプリケーション・クライ アント・プロジェクトにあります。 J2EE 1.3 から 1.4 へのマイグレーション中、 webservicesclient.xml のコンテンツはマイグレーションされ、プロジェクトのデプロイメ ント記述子に移動されます。次のようなプロセスが発生します。 z Web プロジェクトの場合、webserivcesclient.xml のすべての <service-ref> 要素は、web.xml の <web-app> 要素の下に移動される。 z アプリケーション・クライアント・プロジェクトの場合、 webservicesclient.xml の す べ て の <service-ref> 要 素 は 、 application-client.xml の <application-client> 要素の下に移動される。 z EJB プ ロ ジ ェ ク ト の 場 合 、 webserviceclient.xml 33 の <component-scoped-refs> 内 に あ る す べ て の <service-ref> 要 素 は 、 ejb-jar.xml の対応する <enterprise-bean> の下に移動される。 z Webservicesclient.xml が削除される。 <service-qname> 要素と <soap-header> 要素はいずれも修飾名を含んでおり、これらの コ ン テ ン ツ は J2EE 1.4 フ ォ ー マ ッ ト に マ イ グ レ ー シ ョ ン さ れ ま す 。 例 え ば 、 <service-qname> がマイグレーション前に次のように表記されている場合、 <service-qname> <namespaceURI>http://addressbook.webservice</namespaceURI> <localpart>AddressBookService</localpart> </service-qname> マイグレーション後、<service-qname> の表記は次のようになります。 <service-qname xmlns:pfx="http://addressbook.webservice"> pfx:AddressBookService </service-qname> 接頭部 "pfx" が、マイグレーションされるすべての修飾名のネームスペース接頭部として 使用されます。 JAX-RPC マッピング記述子 webservices.xml と webservicesclient.xml デプロイメント記述子の両方が 1 つ以上の JAX-RPC マッピング・デプロイメント記述子を参照することができます。 webservices.xml ファイルでは、これらの参照は、各 <webservice-description> 要素の下 にある <jaxrpc-mapping-file> 要素に入っています。 webservicesclient.xml ファイルで は、これらの参照は、各 <service-ref> 要素の下にある <jaxrpc-mapping-file> 要素に入 っています。 J2EE 1.3 か ら 1.4 へ の マ イ グ レ ー シ ョ ン 中 、 webservices.xml お よ び webservicesclient.xml で参照されているすべての JAX-RPC マッピング・デプロイメン ト記述子がマイグレーションされます。マイグレーションにはすべての修飾名を J2EE 1.4 フォーマットにマイグレーションすることが含まれます (マイグレーション後の修飾名の 例については、前述の webservices.xml と webservicesclient.xml のセクションを参照し 34 てください)。 5.1.5. セキュア Web サービスのマイグレーション セキュア Web サービスは、Web サービスが J2EE 1.3 から J2EE 1.4 にマイグレーショ ンされるときに J2EE マイグレーション・ウィザードによってマイグレーションが行われ ません。セキュア Web サービスのマイグレーションには手動のステップが必要です。 J2EE マイグレーション・ウィザードの使用後に、以下の手順でセキュア・バインディン グと拡張ファイルを手動で J2EE 1.4 にマイグレーションする必要があります。 手順 ① webservices.xml ファイルをダブルクリックして Web サービス・エディターを開く。 ② 「バインディング構成」タブを選択して、バインディング・ファイルを編集する。 ③ 「要求受信側のバインディング構成の詳細」および「応答送信側のバインディング構 成の詳細」という新規セクションの下に必要なバインディング構成をすべて追加する。 ④ 「セキュリティ拡張」タブを選択して拡張ファイルを編集する。 ⑤ 「要求受信側サービス構成の詳細」および「応答送信側サービス構成の詳細」という 新規セクションの下に必要な拡張構成をすべて追加する。 ⑥ 保管してエディターを終了する。 35 J2EE1.2 から 1.4 仕様レベルへのマイグレーション 5.2. RAD V7.0 の J2EE マイグレーション・ウィザードを使用して、J2EE 1.2 仕様レベルの J2EE プロジェクトを J2EE 1.4 仕様レベルにマイグレーションすることができます。この セクションでは、J2EE マイグレーション・ウィザードにより J2EE 1.2 から J2EE 1.4 に マイグレーションされる成果物について、J2EE プロジェクトのタイプごとに説明します。 Web プロジェクト(サーブレット 2.2 からサーブレット 2.4) 5.2.1. J2EE マイグレーション・ウィザードによって、J2EE 1.2 レベルの Web プロジェクトが J2EE 1.4 にマイグレーションされると、サーブレットのレベルも 2.2 から 2.4 にマイグレ ーションされます。このとき、Web デプロイメント記述子(web.xml)に対して以下の変更 が行われます。 TagLib J2EE 1.2 の web.xml の、taglib オブジェクトは、J2EE 1.4 では jsp-config オブジェク トに移動されます。Taglib オブジェクトは、 J2EE 1.2 では web-app オブジェクトに直 属していました。 移行前： <web-app id="WebApp"> … <taglib> <taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri> <taglib-location>/WEB-INF/struts-bean.tld</taglib-location> </taglib> … </web-app> 移行後： <?xml version="1.0" encoding="UTF-8"?> <web-app id="WebApp_ID" version="2.4"… … <jsp-config> <taglib> <taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri> <taglib-location>/WEB-INF/struts-bean.tld</taglib-location> </taglib> 36 … </jsp-config> </web-app> Description マイグレーション・ウィザードは、Web デプロイメント記述子(web.xml)で記述されてい る EJB 参照、セキュリティ参照など多くの項目の「説明(description)」を移行しません。 アプリケーションの実行には影響しませんが、必要な場合は再度設定が必要となります。 5.2.2. EJB プロジェクト (EJB 1.1 から EJB 2.1) J2EE マイグレーション・ウィザードによって、J2EE 1.2 レベルの EJB プロジェクトが J2EE 1.4 にマイグレーションされると、EJB の仕様レベルも 1.1 から 2.1 にマイグレーシ ョンされます。 EJB 1.1 から EJB 2.1 への EJB プロジェクトのマイグレーションでは、 コンテナー管 理パーシスタンス(CMP) エンティティ Bean のマイグレーションを実行可能です。 ※ EJB2.0 と EJB2.1 ではエンティティ Bean には変更がないため、以下では EJB2.0 と EJB2.1 を総称して EJB2.x と記述しています。 注意： CMP 1.x Bean から CMP 2.x Bean へのマイグレーションはオプションです。また、RAD V7.0 は CMP 1.x Bean から CMP 2.x Bean へのマイグレーションをサポートしていますが、以下に記述するようにかなり 煩雑な手動によるステップを必要としています。一方、RAD V7.0 では、ツールサポートにより新規の CMP Bean を比較的容易に作成することが可能となっています。旧バージョンのツールによって生成さ れた CMP のコードに特に変更を加えていない場合は、マイグレーションのほか、新規に CMP 2.1 を作 成することもご検討ください。 コンテナー管理エンティティ Bean を EJB 1.1 から EJB 2.x 仕様レベルにマイグレーシ ョンするには、以下のステップが必要です。 手順 ① EJB プロジェクトを EJB 1.1 から EJB 2.x に変換する。 ② EJB コードを EJB 1.1 から EJB 2.x にマイグレーションする。 ③ ユーザー定義の EJB 1.1 参照を EJB 2.x のローカル参照にマイグレーションする。 EJB 1.1 から EJB 2.x へのプロジェクトの変換 EJB 1.1 プロジェクトは、J2EE マイグレーション・ウィザードを使用して EJB 2.x プロ ジェクトに変換することができます。 37 オリジナルの EJB 1.1 プロジェクトを保持したい場合は、新規の 2.x プロジェクトを作 成し、既存のプロジェクト JAR ファイルをそこにインポートすることができます (「ファ イル」 > 「インポート」 > 「EJB JAR」)。この場合、作成したプロジェクトは EJB 2.x プロジェクトですが、既存の (インポートされた) EJB 1.1 コンテナー管理パーシスタンス (CMP) エンティティ Bean は EJB 1.1 Bean のままとなります。すなわち、CMP エン ティティ Bean は EJB 2.x に変換されません。 J2EE マイグレーション・ウィザードは、オプションの指定により、EJB 2.x プロジェク ト内の エンタープライズ Bean を 1.1 から 2.x にマイグレーションします。 手順 ① J2EE パースペクティブの「プロジェクト・エクスプローラー」ビューで、マイグレ ーション対象のエンタープライズ・アプリケーション・プロジェクトを右クリックし ます。 ② ポップアップ・メニューから 「マイグレーション」 > 「J2EE マイグレーション・ ウィザード」の順に選択します。 ③ 「EJB モジュールのマイグレーション」の選択画面にて、対象となるプロジェクトを 選択し、「CMP 1.x Bean から CMP 2.x Bean へのマイグレーション」にチェックを入 れます。 38 ④ 「ローカル・クライアント・ビューを追加します。 」にチェックを入れることによって、 マイグレーション後の CMP 2.x Bean にローカル・クライアント・ビューを追加する ことができます。 この場合は、以下の画面にてリモート・クライアント・ビューの削除を選択すること が可能です。 39 CMP Entity Bean を 2.x にマイグレーションするように選択した場合は、2.x プロジェク ト内のすべての Bean がマイグレーションされることに注意してください。 z ウィザードは EJB 2.x プロジェクトで既存の EJB 1.1 継承を維持します。 z ウィザードは EJB 1.1 (専有) リレーションを EJB 2.x (標準) にマイグレーションし ます。 注意： マップされた関連がある場合は、その関連自体に対して EJB 2.x の関連が作成されますが、その関連の 役割マップは無効になります。妥当性検査を実行するとエラーが発生します。これを回避するためには、 最初にマッピング・エディターを開いてマップを保管してください。役割マップが除去されます。その後、 もう一度妥当性検査を実行して、役割を再マップすることができます。 40 EJB 1.1 から EJB 2.x へのコードのマイグレーション EJB 1.1 から EJB 2.x に変換されるプロジェクトについては、既存の EJB 1.1 コードを EJB 2.x にマイグレーションするためのステップを実行する必要があります。 注意： EJB 2.x Bean は EJB 2.x プロジェクトでのみサポートされます (ただし、2.x プロジェクトは 1.1 Bean もサポートします)。 手順 ① CMP 1.1 Bean については、各 CMP フィールドを getXXX および setXXX 抽象メ ソッドと置換します (Bean クラスは抽象である必要があります)。 ② CMP については、基本キーの getXXX および setXXX 抽象メソッドを作成します。 ③ CMP 1.1 ファインダー・メソッドについては、各ファインダー・メソッドごとに EJBQL (EJB 照会言語) メソッドを作成します。 注意： V7.0 では、 EJB 照会言語に以下の制限があります。 z 他の EJB へのリレーションで構成されたキーを持つ EJB を使用する EJB 照会言語によ る照会は無効とされ、デプロイメント時にエラーが発生します。 z IBM® EJB 照会言語サポートはいくつかの制限を緩和したり、 DB2® 機能をさらに追加す るなど、さまざまな方法で EJB 2.x 仕様を拡張します。各種ベンダー・データベース間や EJB デプロイメント・ツール間の移植を検討する場合は、「EJB 2.x 仕様」の第 11 章にあ る指示に従って、すべての EJB 照会言語クエリーを慎重に作成する必要があります。 ④ CMP 1.1 フ ァ イ ン ダ ー に つ い て は 、 java.util.Enumeration の 代 わ り に java.util.Collection を戻します。 ⑤ CMP 1.1 Bean については、ejbCreate() 内、およびコード内のどこでも、 this.field = value のすべてのオカレンスを setField(value) に変更します。 ⑥ 非アプリケーション例外の例外処理 (ロールバックの振る舞い) を更新します。 z java.rmi.RemoteException の代わりに javax.ejb.EJBException をスローして、 非アプリケーション例外を報告します。 z EJB 2.x および 1.1 では、インスタンスによってスローされたすべての非アプリ ケーション例外により、インスタンスを実行したトランザクションがロールバッ クされ、インスタンスが廃棄されます。 ⑦ アプリケーション例外の例外処理 (ロールバックの振る舞い) を更新します。 z EJB 2.x および 1.1 では、アプリケーション例外が原因でコンテナーが自動的に トランザクションをロールバックすることはありません。 z EJB 1.1 で は 、 イ ン ス タ ン ス が そ の EJBContext オ ブ ジ ェ ク ト で setRollbackOnly() メソッドを使用して呼び出された場合にのみ、コンテナーはロ 41 ールバックを実行します。 ejbCreate 内のアプリケーション固有のデフォルト値の CMP 設定をすべて更新しま ⑧ す (EJB 1.1 コンテナーは前のアプリケーション固有のデフォルトを上書きする ejbCreate を呼び出す前にすべてのフィールドを汎用のデフォルト値に設定してしま うため、グローバル変数を使用しないで行います)。 データ・ソースのマイグレーション EJB 1.x では、WAS V4 タイプのデータ・ソースを使用する必要がありましたが、EJB 2.x では WAS V5 以降のデータ・ソースを使用する必要があります。デプロイメント記述子エ ディターを使用し、データ・ソースに関する設定を変更してください。 EJB 1.1 リレーション用の EJB 参照のマイグレーション EJB 1.1 リレーションを作成すると、 「リモート・クライアント」ビューに EJB 参照が作 成されます。 J2EE マイグレーション・ウィザードを使用した EJB 1.1 プロジェクトの マイグレーション中に、これらの EJB 1.1 リレーションに対する EJB リモート参照は除 去されて、 EJB ローカル参照に置換されます。ユーザー定義の EJB 参照のローカル参 照は、手動で再作成する必要があります。 注意： EJB 2.x では、Bean にローカル・クライアント・ビューが定義されており、 EJB ローカル参照が EJB 2.x リレーションに対して作成されている場合にのみ、 EJB リレーションを作成することができます。 ユーザー定義の EJB 参照の場合、マイグレーションは J2EE マイグレーション・ウィザードを使用し て実行されません 。以下のステップに従ってローカル参照をセットアップしてください。 手順 ① デプロイメント記述子エディターの「参照」ページで既存の EJB リモート参照を削 除する。 ② デプロイメント記述子エディターの「参照」ページで EJB ローカル参照を追加する。 マイグレーション中のメソッド要素のマージ J2EE マイグレーション・ウィザードを使用したマイグレーション中、すべての Bean で 同じタイプのメソッド要素 (セキュリティー ID、コンテナー・トランザクション、メソッ ド許可、アクセス・インテント、および分離レベルなど) がマージされ、論理的にグループ 化されます。 以下は、マイグレーション前と後のデプロイメント記述子(ejb-jar.xml)のメソッド許可部分 のサンプルです。 42 マイグレーション前： <method-permission> <role-name>rol1</role-name> <role-name>rol2</role-name> <method> <ejb-name>TestBean1</ejb-name> <method-intf>Home</method-intf> <method-name>getEJBMetaData</method-name> <method-params> </method-params> </method> <method> <ejb-name>TestBean1</ejb-name> <method-intf>Home</method-intf> <method-name>getHomeHandle</method-name> <method-params> </method-params> </method> <method> <ejb-name>TestBean2</ejb-name> <method-intf>Home</method-intf> <method-namae>remove</method-name> <method-params> <method-param>java.lang.Object</method-param> </method-params> </method> <method> <ejb-name>TestBean2</ejb-name> <method-intf>Home</method-intf> <method-name>remove</method-name> <method-params> <method-param>javax.ejb.Handle</method-param> 43 </method-params> </method> </method-permission> <method-permission> <role-name>rol1</role-name> <role-name>rol2</role-name> <method> <ejb-name>TestBean2</ejb-name> <method-intf>Remote</method-intf> <method-name>isIdentical</method-name> <method-params> <method-param>javax.ejb.EJBObject</method-param> </method-params> </method> </method-permission> マイグレーション後： <method-permission> <role-name>rol1</role-name> <role-name>rol2</role-name> <method> <ejb-name>TestBean1</ejb-name> <method-intf>Home</method-intf> <method-name>getEJBMetaData</method-name> <method-params></method-params> </method> <method> <ejb-name>TestBean1</ejb-name> <method-intf>Home</method-intf> <method-name>getHomeHandle</method-name> <method-params></method-params> </method> <method> 44 <ejb-name>TestBean2</ejb-name> <method-intf>Home</method-intf> <method-name>remove</method-name> <method-params> <method-param>>java.lang.Object</method-param> </method-params> </method> <method> <ejb-name>TestBean2</ejb-name> <method-intf>Home</method-intf> <method-name>remove</method-name> <method-params> <method-param>javax.ejb.Handle</method-param> </method-params> </method> <method> <ejb-name>TestBean2</ejb-name> <method-intf>Remote</method-intf> <method-name>isIdentical</method-name> <method-params> <method-param>javax.ejb.EJBObject</method-param> </method-params> </method> </method-permission> 注意： J2EE マイグレーション・ウィザードで、CMP 1.x から CMP 2.x Bean へのマイグレーションも選択 された場合、アクセス・インテントと分離レベルは除去されますが、それ以外はすべてマイグレーション 中にマージされます。アクセス・インテントと分離レベルが除去される理由は、拡張機能モデルの変更に よってこれらが無効になったためです。新規モデルでは、アクセス・インテントと分離レベルの両方がア クセス・インテントに定義されており、 Bean レベル・アクセス・インテントとメソッド・レベル・ア クセス・インテントの両方があります。メソッド・レベル・アクセス・インテントではなく、常に Bean レベル・アクセス・インテントを使用することをお勧めします。 45 6. 6.1. Struts Web プロジェクトのマイグレーション RAD V6.0 で作成した Struts Web プロジェクトのマイグレーション RAD V6.0 で作成した Struts Web プロジェクトは、通常の J2EE プロジェクトと同様の方 法で RAD V7.0 にマイグレーション可能であり、そのまま実行できます。 ただし、RAD V6.0 で作成した Struts 1.1 Web プロジェクトと RAD V7.0 で作成した Struts 1.1 Web プロジェクトでは、プロジェクトの構造に変更があり、RAD V6.0 で作成した Struts JSP ファイルを RAD V7.0 の Struts Web プロジェクトにインポートして使用する 場合は、以下の変更が必要となります。 RAD V6.0 で作成した Struts 1.1 Web プロジェクトでは Struts の使用する tld ファイルが /WEB-INF の下に配置されますが、RAD V7.0 で作成した Struts 1.1 Web プロジェクトで は tld ファイルは/WEB-INF 下には置かれていません。このため、JSP ファイルの taglib 参 照を適切に書き換える必要があります。/WEB-INF/struts-*.tld の形式で記述された taglib URI を、http://jakarta.apache.org/struts/tags-* の形式の taglib URI で置き換えます。 詳しくは、次の表を参照してください。 表. RAD V6.0 Struts 1.1 および RAD V7.0 Struts 1.1 の Struts taglib 参照 RAD V6.0 Struts 1.1 taglib 参照 RAD V7.0 Struts 1.1 taglib 参照 <%@ taglib <%@ taglib uri="/WEB-INF/struts-bean.tld" uri=http://jakarta.apache.org/struts/tags-bean prefix="bean" %> prefix="bean" %> <%@ taglib <%@ taglib uri="/WEB-INF/struts-html.tld" uri=http://jakarta.apache.org/struts/tags-html prefix="html" %> prefix="html" %> <%@ taglib <%@ taglib uri="/WEB-INF/struts-logic.tld" uri=http://jakarta.apache.org/struts/tags-logic prefix="logic" %> prefix="logic" %> <%@ taglib <%@ taglib uri="/WEB-INF/struts-template.tld” uri=http://jakarta.apache.org/struts/tags-template prefix="template" %> prefix="template" %> 46 Web プロジェクトでの Faces ランタイム・リソースの更新 7. V6.0 に付属していた JavaServer Faces のランタイム・リソースは、V7.0 用に更新され ています。この Web プロジェクトでの開発を継続する場合は、Faces ランタイム・リソー スを最新レベルに更新することをお勧めします。 V7.0 では、古いリソースを含む Web プロジェクトのインポート時やワークスペースのオープン時 に、 Faces ランタイム・リソースの更新が自動的に行われます。 V6.0 から V7.0 に対して Web プロジェクトをインポートしたりワークスペースを開いたりした後で、 Faces ランタイム・リソースを最 新レベルに更新するように指示するプロンプトが表示されます。 7.1. ランタイム・リソースを自動的に更新する Web プロジェクトに対して Faces ランタイム・リソースを自動的に更新するには、以下のようにしま す。 手順 ①Faces コンテンツを含む Web プロジェクト (またはワークスペース) を V6.0 からインポートしま す。「プロジェクトのマイグレーション」ウィンドウが開きます。 注意： 「プロジェクトのマイグレーション」ウィンドウが開かない場合は、自動ビルドの設定が無効になっていま す。プロジェクト・エクスプローラーで Web プロジェクトを右クリックして、 「ビルド」 > 「プロジェクト」を選 択します。これにより、プロジェクトの再ビルド・プロセスが実行されて、「プロジェクトのマイグレーション」 ウィンドウが開きます。 ②Faces コンテンツが含まれた他の Web プロジェクトがワークスペース内にある場合は、「アップ グレードの必要がある他のプロジェクトにこの選択を適用する」チェック・ボックスを選択すると、す べての Web プロジェクトが更新されます。 47 ③「適用する」を選択してクリックします。 ・適用する （更新を自動的に完了します） ・後で適用する （更新を延期します） ・適用しない （ランタイムを更新しません） 注意： ■「後で適用する」を選択した場合、後にランタイム・リソースを自動的に更新するには、Web プロジェク トを再ビルドする前に、Web プロジェクトを閉じてから再び開くかワークベンチを再始動する必要がありま す。 ■「適用しない」を選択して古いランタイム・リソースを意図的に保持した場合は、ランタイム・リソースを更 新するように指示するプロンプトは再表示されません。その後ランタイム・リソースの更新が必要な場合 は、手動で更新する必要があります。 7.2. ランタイム・リソースを手動で更新する Web プロジェクトに対して Faces ランタイム・リソースを手動で更新するには、以下のようにします。 手順 ①JSF7 という名前の新規 Web プロジェクトを作成します。 a．ターゲット・ランタイムのコンボ･ボックスで、更新する既存プロジェクトのランタイムと同じサーバー を指定し、「次へ」をクリックします。（例では WebSphere Applicatin Server v5.1） 48 ｂ．プロジェクト・ファセットの選択画面で、「JSTL」「基本 Faces サポート」「拡張 Faces サポート」にチ ェックを追加し、「終了」をクリックします。 ②Faces ページ・ファイルを作成します。 新規 Web プロジェクトの WebContent フォルダーを右クリックし、「新規」 > 「Web ページ」を選 択します。任意の名前を付けて「終了」をクリックします。 49 ③「入力 - リッチ・テキスト・エディター」および「パネル - タブ付き」コンポーネントを、パレットから 新規 Faces ページにドラッグ・アンド・ドロップします。 いずれの場合も、新規リソースを追加するようプロンプトが出されたら、「OK」をクリックします。 ④更新したい既存の Faces プロジェクトごとに以下を実行します。 ａ．リソース・パースペクティブを開き、ナビゲーターで既存のプロジェクトを展開して、 WebContent/WEB-INF/lib/ フォルダー内のファイルを表示します。このディレクトリーに ある以下の JAR ファイルを削除します。 ・jsf-api.jar ・jsf-ibm.jar ・jsf-impl.jar ・odc-jsf.jar ・DocEditor.jar ・rte.jar 50 ｂ．JSF7 プロジェクトの WebContent/WEB-INF/lib ディレクトリーにあるすべての JAR ファイルをコピーし、更新するプロジェクトの同じ場所にそれらを貼り付けます。 ｃ．既存プロジェクトでデータ・アクセスに WebSphere® Data Objects (WDO) を使用し ていた場合は、次の追加ステップを実行します。 i）オリジナル・プロジェクトで 「ファイル」>「新規」>「Web ページ」とクリックして、 一時 Faces JSP ファイルを新規作成します。 ii）パレットのデータ・ドロワーからリレーショナル・レコード・リスト・コンポーネント をページにドラッグします。 iii）任意の接続とデータ・ソースを選出して、「終了」をクリックします。選択されるデー タは重要ではありません。このプロセスによりこのプロジェクトで WDO の使用を継続す るために必要な構成が生成されます。 iv）一時 JSP ファイルを削除します。 ⑤JSF7 Web プロジェクトを削除します。 51 8. WAS V5.1 をターゲットとし、SDO を含む Web アプリケーションの マイグレーション WAS V5.1 ランタイムをターゲットとし、Service Data Object (SDO) アクセス Bean を含む Web プ ロジェクトを、WAS 以外のランタイム (例えば Apache Tomcat など) にマイグレーションする場合、 WAS 以外のランタイムで JavaServer Faces JSP を実行した際に、SDO XML ファイルに対する「フ ァイル入出力例外」を受け取るケースがあります。このケースでは、プロジェクトの PageCodeBase クラスの変更が必要になります。 この現象は、リソース・パスを扱う JavaServer Faces の実装がターゲットとするランタイムによって異 な る た め に 発 生 し ま す 。 WAS の ラ ン タ イ ム で は リ ソ ー ス ・ パ ス と し て 相 対 パ ス (/MyProject/WebContent/sdo.xml など) が要求されますが、他のランタイムでは絶対システム・パ ス (例えば、D:/workspace/MyProject/WebContent/sdo.xml など)が要求される場合があるため です。 このようなケースでは、リソース・パスの解決時に絶対パスを戻すように プロジェクトの PageCodeBase クラスの getRealPath(String relPath) メソッドを変更してください。 52