IBM Rational Application Developer for Windows and Linux、バージョン 6.0 マイグレーション・ガイド


目次

第 1 章 WebSphere Studio V5.1、5.1.1、または 5.1.2 からのマイグレーション

  • WebSphere Studio V5.1.x との互換性
  • WebSphere Studio V5.1.x との互換性の使用不可化
  • Web プロジェクトでの Faces ランタイム・リソースの更新
  • Web プロジェクトでの Faces Client ランタイム・リソースの更新
  • Struts Web プロジェクトのマイグレーション
  • V6.0 でのデバッガーの変更
  • WDO から SDO へのマイグレーション
  • V6.0 の EGL 予約語
  • 第 2 章 Rational Application Developer V6.0 の Web プロ ジェクトに対する Faces ランタイム・リソースの更新

    第 3 章 Rational Application Developer V6.0 Application Developer V6.0 のポートレット・プロジェクトに対する Faces ランタイム・リソースの更新

    第 4 章 J2EE プロジェクトのマイグレーション

  • セキュア Web サービスのマイグレーション
  • J2EE 1.3 から 1.4 仕様レベルへのマイグレーション
  • Enterprise JavaBean プロジェクト (EJB 2.0 から EJB 2.1)
  • Web プロジェクト (サーブレット・レベル 2.3 からサーブレット・レベル 2.4)
  • コネクター・プロジェクト (JCA 1.0 から JCA 1.5)
  • Web サービス (J2EE 1.3 から J2EE 1.4)
  • J2EE 1.2 から 1.4 仕様レベルへのマイグレーション
  • Enterprise JavaBeans プロジェクトのマイグレーション (EJB 1.1 から EJB 2.1)
  • Web プロジェクト (サーブレット・レベル 2.2 からサーブレット・レベル 2.4)
  • Rational Application Developer V6.0 での J2EE マイグレーション・ウィザードの変更
  • 第 5 章 Rational Application Developer V6.0 での Portal Tools のマイグレーション

  • WebSphere Portal V4.2 ポートレットから V5.x へのマイグレーション
  • ポートレット・プロジェクトでの Faces ランタイム・リソースの更新
  • 第 6 章 WebSphere テスト環境の変更



    第 1 章 WebSphere Studio V5.1、5.1.1、または 5.1.2 からのマイグレーション

    この文書では、WebSphere(R) Studio Application Developer V5.1.x から Rational(R) Application Developer V6.0 へのマイグレーションについて 説明します。

    以下のトピックについての 追加情報があります。

    Rational Application Developer の 使用についての情報は、オンライン・ヘルプを参照してください。

    更新文書については、 www.ibm.com/developerworks/rational を参照してください。

    WebSphere Studio の前のバージョンから v5.x へのマイグレーション、または VisualAge(R) for Java(TM) から WebSphere Studio へのマイグレーションについて詳しくは、 www.ibm.com/software/awdtools/studioappdev/support/ で「migration guide」を検索してください。

    WebSphere Studio V5.1.x からマイグレーションするには、 以下のようにします。

    1. インストールの前に、「Eclipse V2.x および WebSphere Studio V5.1.x との互換性」について読む。 WebSphere Studio V5.1.2 の Portal Toolkit V5.0.2.2 から マイグレーションされたポートレット・アプリケーション・プロジェクトでは 後方互換性はサポートされていませんのでご注意ください。
    2. WebSphere Studio V5.1.x ワークスペースをバックアップする。
    3. Rational Application Developer をインストールする。 1 枚目の製品 CD のルートにある「インストール・ガイド 」(install.html ファイル) を 参照してください。
    4. 推奨: デフォルトにより、 Rational Application Developer を初めて開始すると、 rationalsdp6.0¥workspace という名前のワークスペースを使用することを確認する プロンプトが表示される。 つまり、「ワークスペース・ランチャー (Workspace Launcher)」ダイアログ・ボックスが、 ユーザーの WebSphere Studio ワークスペースではないディレクトリーを指します。古いワークスペースを マイグレーションする前に新規環境を探索するには、デフォルトを受け入れるか、 または Rational Application Developer を開始するときに 別の新規ディレクトリー名を指定してください。これは、例えば 1 つか 2 つのテスト・プロジェクトを作成する、 新機能について読む (「ヘルプ」 -> 「ようこそ」)、 いくつかの新規チュートリアル (「ヘルプ」 -> 「チュートリアル・ギャラリー」) を実行する、 またはいくつかの新規サンプルを試す (「ヘルプ」 -> 「サンプル・ギャラリー」) といった場合に行うことができます。
    5. V6.0 にプロジェクトをマイグレーションする。WebSphere Studio V5.1.x で作成したプロジェクトは、以下の手順で自動的に V6.0 にマイグレーションされます。
      1. ワークスペースをマイグレーションする:V5.1.x ワークスペースを永続 的にマイグレーションする準備ができたら、古いワークスペースで Rational Application Developer を開始する。進行標識は、プロジェクトが自動的にマイグレーションされていることを確認します。

        注: ワークスペースのマイグレーション中、「問題 」ダイアログ・ボックスが開いて 「ワークベンチのレイアウトを復元できません。理由: ワークベンチの復元中に 問題が発生しました 」というメッセージが表示されます。このエラー・メッセージは、ワークスペースのマイグレーションの成功には何の影響もありません。 エラー・ダイアログ・ボックスの「詳細」ボタンをクリックして 復元できなかったパースペクティブの名前をメモしてから、 「OK」をクリックしてダイアログ・ボックスを閉じてください。

        パースペクティブを復元するには、以下のようにします。

        1. 「ウィンドウ」 -> 「パースペクティブを閉じる (Close Perspective)」 を選択してパースペクティブを閉じる。
        2. 「ウィンドウ」 -> 「パースペクティブを開く (Open Perspective)」 を選択してパースペクティブを再び開く。
        注:
        WebSphere Studio V5.1.2 で EGL Web パースペクティブを使用したエンタープライズ開発言語 (EGL) プロジ ェクトの場合: このパースペクティブは Rational Application Developer V6.0 では除去されました。 Rational Application Developer V6.0 では、すべての EGL プロジ ェクトはこのパースペクティブがなくても安全にマイグレーションされます。 EGL Web パースペクティブを使用した場合は、以下のことを実行してください。
        1. EGL Web パースペクティブを閉じる。
        2. 「設定」 (「ウィンドウ」 -> 「設定」) で EGL 機能を使用可能にする。EGL 機能の 使用可能化について詳しくは、オンライン・ヘルプを参照してください。
        3. 「ウィンドウ」 -> 「パースペクティブを開く」を選択し、 Web パースペクティブを選択する。
      2. SCM (ソース・コード管理) システムからロードされたプロジェクトをマイグレ ーションする: SCM システムに存在する WebSphere Studio 5.1.x のプロジェクトは、 Rational Application Developer にロードされたと きに自動的に V6.0 にマイグレーションされます。
      3. プロジェクト交換を使用してインポートされたプロジェクトをマイグレーション する: WebSphere Studio V5.1.2 または V5.1.1 からエクスポートされて、プロジェクト交換フィーチャーを使用して Rational Application Developer V6.0 にインポート されたプロジェクトは、自動的に V6.0 にマイグレーションされます。 プロジェクト交換フィーチャーは、 WebSphere Studio V5.1.2 で使用可能であり、 V5.1.1 ではオプションのプラグインでした。

      注:

      重要:

    6. DB2(R) Net JDBC ドライバーは、 Rational Application Developer V6.0 ではサポートされていません。 DB2 Net JDBC ドライバーを使用して JDBC 接続を作成した場合は、 Rational Application Developer V6.0 で再接続できません。 サポートされる JDBC ドライバーの 1 つを使用するにように接続を変更する必要があります。 V6.0 でサポートされる JDBC ドライバーについて詳しくは、オンライン・ヘルプを 参照してください。
    7. Web または XML ファイル・コンテンツを、Shift_JIS 文字セットを使用し、 ベンダー選択文字を組み込んだ WebSphere Studio Application Developer V5.1.x からマイグレーションした場合は、代わりに Windows-31J 文字セットを指定する必要があります。
    8. WebSphere Studio Application Developer V5.1.x と共に ベンダーのプラグインをインストールした場合は、 V6.0 用の対応するプラグインを入手して再インストールする必要があります。
    9. Rational Application Developer の インストール時にバックレベルの WebSphere V5.x 単体テスト 環境をインストールしており、なおかつ組み込みメッセージング・サービスを使用している場合は、 Rational Application Developer で提供されている バージョンをインストールしてアップグレードしてください。 組み込みメッセージング・サービスについて詳しくは、 「インストール・ガイド 」を参照してください。
    10. エージェント・コントローラーが必要な機能を使用している場合は、 Rational Application Developer で提供されているバージョンを インストールしてアップグレードしてください。 詳しくは、「インストール・ガイド 」を参照してください。
    11. VisualAge Generator からマイグレーションするには、 「VisualAge Generator からエンタープライズ開発言語 (EGL) へのマイグレーション・ガイド 」を参照してください。 この文書は、オンライン・ヘルプの「インストールとマイグレーション」セクションの ヘルプ・トピック「VisualAge Generator から EGL マイグレーション・ガイドへのアクセス」 の下に PDF 形式で置いてあります。 最新コピーは、 http://www.ibm.com/developerworks/rational/library/egldoc.html から入手できます。

    WebSphere Studio V5.1.x との互換性

    WebSphere Studio V5.1.x ワークスペースを初めて Rational Application Developer で開くと、 そのワークスペースは自動的にマイグレーションされます。ワークスペースをマイグレーションした後は、 WebSphere Studio Application Developer でそのワークスペースを開くことはできなくなります。 ただし、V6.0 ワークスペースのプロジェクトは、ソース・コード管理 (SCM) システム (例、Rational ClearCase(R)) を使用したり、プロジェクト交換を使ってプロジェクトをインポートおよびエクスポートしたり、 アーカイブのインポートとプロジェクトのエクスポートを通じて、引き続き WebSphere Studio V5.1.x と共用することができます。重要: Rational Application Developer V6.0 の Portal Tools にマイグレーションされる Portal Toolkit V5.0.2.2 の ポートレット・アプリケーシ ョンは後方互換にはなりません。

    注:
    以下は、ポートレット・アプリケーション・プロジェクトには適用されません。

    SCM システムまたはプロジェクト交換を使用する別の開発者から V6.0 に ロードされる既存の V5.1.x プロジェクトは、 以下のいずれのアクションも行わなければ、V5.1.x と互換となり共用することができます。

    V5.1.x プロジェクトを Rational Application Developer V6.0 ワークスペースで開くと、.compatibility ファイルが自動的に プロジェクト・ディレクトリーに作成されます。.compatibility ファイルは、 プロジェクト・リソースがマイグレーションされるときに、 Rational Application Developer が これらのリソースのタイム・スタンプをトラッキングするために使用します。 これは編集または削除しないでください。

    WebSphere Studio Application Developer V5.1.x との互換性の使用不可化 について詳しくは、「WebSphere Studio V5.1.x との互換性の使用不可化」を参照してください。

    Eclipse の考慮事項

    Rational Application Developer のこのバージョンは、 Eclipse V3.0 を基にしています。独自のプラグインを開発する場合は、マイグレーションを 実行する前にプラットフォームに対する変更事項についての情報をお読みください。

    詳しくは、 Rational Application Developer V6.0 のインストール・ロケーションの eclipse¥readme サブディレクトリー にある README ファイルを参照してください。 README ファイルの中でマイグレーションに関連するセクションは以下の通りです。

    J2EE プロジェクトの互換性

    WebSphere Studio V5.1.x で作成されたプロジェクトの Rational Application Developer V6.0 との互換性は、 V5.1.x ワークスペースをマイグレーションしたときに .project ファイルに 自動的に追加されるメタデータによって使用可能にされます。同様に、 新規 J2EE 1.2 または 1.3 モジュール、あるいはアプリケーションを Rational Application Developer V6.0 で作成すると、 V5.1.x との互換性のためにビルド・メタデータが .project ファイルに自動的に追加されます。 この情報を直接編集または削除しないでください。

    注:
    この互換性メタデータにより、 V6.0 で作成された新規 J2EE 1.2 および J2EE 1.3 モジュールまたはアプリケーションが、 V6.0 ビルダーが使用できない WebSphere Studio Application Developer V5.1.x で使用されると、「ビルダーの欠落」に関するメッセージが表示されるか、または ログに記録されます。これらのメッセージは正常ですので、無視してかまいません。

    この互換性メタデータが あるかぎり、Rational Application Developer V6.0 プロジェクトが WebSphere Studio V5.1.x に再びロードされると、 「ビルダーの欠落」に関するメッセージを受け取ります。「ビルダーの欠落」メッセージ の例は次の通りです。

    !ENTRY org.eclipse.core.resources 2 1 Sep 06, 2004 19:55:20.592
    !MESSAGE Skipping builder com.ibm.wtp.j2ee.LibCopyBuilder for project Test60EARWeb. 
    Either the builder is missing from the install, or it belongs to a project nature that is missing or disabled.
    

    これらのメッセージは正常ですので、無視してかまいません。ある特定の プロジェクトについて、 WebSphere Studio V5.1.x で作業する必要がなくなったことが確実な場合は、 そのプロジェクトの後方互換性を使用不可化 してメッセージを停止することができます。

    重要: V6.0 で作成される新規 J2EE または 1.3 仕様プロジェクトは、 WebSphere Studio V5.1.x と互換ですが、 プロジェクトが WebSphere Studio にロードされた後は、そのプロジェクトの作業をする前に いくつかの手動ステップを実行する必要があります。6.0 で作成された 新規 J2EE 1.2 または 1.3 仕様プロジェクトのランタイム・ターゲット が V5.1.x のターゲット・サーバーとは直接後方互換ではないため、 これらのステップが必要です。新規 V6.0 プロジェクトを V5.1.x でロードした後、 以下の手動ステップが必要です。

    1. .classpath ファイルを持つ J2EE プロジェクトごとに .classpath ファイルを開く。
    2. .classpath ファイルから以下のクラスパス・エントリーを削除し、ファイルを保管して閉じる。
    3. 必ず「J2EE 設定」ページでサーバー・ターゲット・サポートが使用可能になっていることを 確認する。「ウィンドウ」 -> 「設定」 -> 「J2EE」を選択し、 「サーバー・ターゲット・サポート」の下で 「サーバー・ターゲット・サポートを使用可能にする」が 選択されていることを確認します。
    4. プロジェクトを右クリックし、 「プロパティー」 -> 「J2EE」を選択する。
    5. プロジェクトのランタイム・ターゲットの対応するターゲット・サーバー (例えば、JDK 1.4 ランタイム環境を使用する WebSphere Application Server V5.1) を選択して、 「OK」をクリックする。
    6. 選択されたターゲット・サーバーは、 Rational Application Developer V6.0 と WebSphere Studio Application Developer V5.1.x の両方で互換となる。 SCM システムに変更がコミットされた後は、J2EE プロジェクトは SCM システムを使用して V5.1.x と V6.0 の間で相互操作可能となります。
      注:
      ターゲット・サーバーが再び Rational Application Developer V6.0 に設定されると、 J2EE プロジェクトの互換性は失われて、再確立が必要になります。

    UML ダイアグラムの互換性

    WebSphere Studio Application Developer V5.1.x に 存在していた UML ダイアグラムは上位互換であり、Rational Application Developer V6.0 で 読み取り専用モードで開くことができます。 V6.0 では、J2EE マイグレーション・ウィザードは、 J2EE プロジェクト構造のマイグレーション中に、 V5.1.x J2EE プロジェクトで作成された UML ダイアグラムを 自動的にマイグレーションします。マイグレーションが行われた後は、 UML ダイアグラムを Rational Application Developer V6.0 で 編集することができます。

    注:
    Rational Application Developer V6.0 にマイグレーションされたりそこで作成されたワークスペースの UML ダイアグラムは、 WebSphere Studio Application Developer V5.1.x で開くことはできません。

    WebSphere Studio V5.1.x との互換性の使用不可化

    WebSphere Studio Application Developer V5.1.x との互換性は、 Rational Application Developer V6.0 で作成された エンタープライズ・アプリケーション・プロジェクト、または WebSphere Studio の 前のバージョンからマイグレーションされたエンタープライズ・アプリケーションから 完全に除去することができます。 WebSphere Studio V5.1.x との互換性は、エンタープライズ・アプリケーション・プロジェクトが V5.1.x と 相互操作可能である必要も、または互換である必要もなくなったことが 確実な場合にのみ使用不可にしてください。

    WebSphere Studio Application Developer V5.1.x との互換性を 除去するには、以下のようにします。

    1. エンタープライズ・アプリケーション・プロジェクトを右クリックし、 ポップアップから「互換性の除去」メニュー・オプションを選択する。
    2. エンタープライズ・アプリケーション・プロジェクトとそのプロジェクトの下に ネストされたすべてのモジュールとユーティリティー・プロジェクトの後方互換性の除去について 確認を求めるダイアログが表示される。
    3. はい」をクリックして、互換性の除去操作を継続する。

    互換性の除去操作が実行されると、エンタープライズ・アプリケーション・プロジェクト とそのエンタープライズ・アプリケーション・プロジェクトの下にネストされたすべての モジュールとユーティリティー・プロジェクトが、 WebSphere Studio Application Developer V5.1.x と後方互換ではなくなります。


    Web プロジェクトでの Faces ランタイム・リソースの更新

    WebSphere Studio Application Developer V5.1.x に付属 していた JavaServer Faces ランタイム・リソースは、 Rational Application Developer V6.0.1 用に更新されました。 この旧製品バージョンで作成された Web プロジェクトでの開発を継続したい場合は、Faces ランタイム・リソースを最新レベルに更新することをお勧めします。

    Rational Application Developer V6.0.1 では、 Faces ランタイム・リソースの更新は、古いリソースが含まれた Web プロジェクトがインポ ートされるか、古いリソースが含まれたワークスペースが開かれたときに自動的に行われます。 WebSphere Studio Application Developer V5.1.x から Rational Application Developer V6.0.1 に Web プロジェクト をインポートするかワークスペースを開いた後で、Faces ランタイム・リソースを最新レベ ルに更新するように指示するプロンプトが表示されます。

    ランタイム・リソースを自動的に更新する

    Web プロジェクトに対して Faces ランタイム ・リソースを自動的に更新するには、以下のようにします。

    1. Faces コンテンツが含まれた Web プロジェクト (またはワークスペース) を WebSphere Studio Application Developer V5.1.x からインポートする。 「プロジェクトのマイグレーション」ウィンドウが開きます。
      注:
      「プロジェクトのマイグレーション」ウィンドウが開かない場合は、自動ビルドの設定が おそらく無効になっています。 プロジェクト・エクスプローラーで Web プロジェクトを右クリックして、 「ビルド」 -> 「プロジェクト」を選択します。これにより、プロジェクトの再ビルド・プロセスが 実行されて、「プロジェクトのマイグレーション」ウィンドウが開き ます。
    2. Faces コンテンツが含まれた他の Web プロジェクトがワークスペース内にある場合 は、「アップグレードの必要がある他のプロジェクトにこの選択を適用する」チェック・ボックスを選択すると、すべての Web プロジェクトが更新される。
    3. 次のいずれかをクリックする。
    注:
    Faces Client コンポーネントが含まれた Faces JSP を作成した場合は、Faces Client コンポーネント・ランタイム・リソースを別個に最新レベルに更新する必要があります。「Web プロジェクトでの Faces Client ランタイム・リソースの更新」を参照してください。

    ランタイム・リソースを手動で更新する

    Web プロジェクトに対して Faces ランタイム・リソー スを手動で更新するには、以下のようにします。

    1. Faces コンテンツが含まれた既存の Web プロジェクトを Rational Application Developer V6.0.1 ワークスペースにインポー トする。
    2. JSF601 という名前の新しい Web プロジェクトを作成する (または EGL で 作業をしている場合は JSF601 という名前の新しい EGL Web プロジェクトを作成する)。 このプロジェクトは、最新ランタイム・リソースのソースとしてのみ使用し、更新の完了後には削除できます。
    3. プロジェクト・エクスプローラーで JSF601 プロジェクトを右クリックし、 メニューから「プロパティー」を選択する。
    4. Web プロジェクト・フィーチャー 」をクリックして、「Faces 基本コンポーネントの追加」と「Faces Client Framework の追加」を選択し、「OK」をクリックする。
    5. EGL で作業をしている場合は、以下の手順で JSF ページを作成してください。
      1. 新規 EGL Web プロジェクトの WebContent フォルダーを右クリックする。
      2. 「新規」 -> 「その他」 -> 「Faces JSP ファイル」を選択する。
      eglintdebug.jar ファイルと eglintdebugsupport.jar ファイルが プロジェクトに追加されます。
    6. 更新したい既存の Faces プロジェクトごとに以下を実行する。
      1. プロジェクト・エクスプローラーで既存のプロジェクトを展開して、 WebContent/WEB-INF/lib/ フォルダー内のファイルを表示する。このディレクトリーにある 以下の JAR ファイルをすべて見つけて削除します。
        • eglintdebug.jar (EGL のみ)
        • eglintdebugsupport.jar (EGL のみ)
        • fda.jar (EGL のみ)
        • fdaj.jar (EGL のみ)
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • odc-jsf.jar
      2. WebContent/WEB-INF/faces-config.xml ファイルを見つけて開く。 以下のエレメントが まだこの構成ファイルにない場合、追加します。
        	<lifecycle>
        		<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
        	</lifecycle>
        	
        	<application>
        		<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
        		<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
        	</application>
        
      3. 削除した JAR ファイルについて、JSF601 プロジェクトの WebContent/WEB-INF/lib ディレクトリーから同じ名前の JAR ファイルをコ ピーし、同じ場所のオリジナル・プロジェクトに貼り付ける。構成によっては、これらすべての JAR ファ イルがプロジェクトに含まれている必要はありません。したがって、オリジ ナル・プロジェクトになかった特定の JAR ファイルはコピーしないでください。
      4. オリジナル・プロジェクトの web.xml デプロイメント記述子を開き、 構成に以下を追加する。
        	<context-param>
        		<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
        		<param-value>true</param-value>
        	</context-param>	<context-param>
        		<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
        		<param-value>true</param-value>
        	</context-param>
        
      5. オリジナル・プロジェクトでデータ・アクセスのために WebSphere Data Object (WDO) を使用していた場合は、以下の追加ステップを実行する。
        1. オリジナル・プロジェクトで、「ファイル」 -> 「新規」 -> 「Faces JSP ファイル」をクリック して、新しい一時 Faces JSP ファイルを作成する。
        2. パレットのデータ・ドロワーからリレーショナル・レコード・リスト・コンポーネントを ページにドラッグする。
        3. 任意の接続とデータ・ソースを選出して、「終了」をクリックする。 選択されるデータは重要ではありません。このプロセスによりこのプロジェクトで WDO の使用 を継続するために必要な構成が生成されます。
        4. 一時 JSP ファイルを削除する。
      6. EGL で作業をしている場合 は、 それぞれの EGL Web プロジェクトの名前を右クリックし、 「生成」をクリックする。その後、自動的にプロジェクトを ビルドしているのでない場合は、「プロジェクト」 -> 「すべてビルド」をクリックします。
    7. JSF601 Web プロジェクトを削除する。

    Web プロジェクトでの Faces Client ランタイム・リソースの更新

    WebSphere Studio Application Developer V5.1.x に元々付属 していた JavaServer Faces Client ランタイム・リソースは、 Rational Application Developer V6.0.1 用に更新されました。 この旧製品バージョンで作成された Web プロジェクトでの開発を継続したい場合は、 Faces Client ランタイム・リソースを最新レベルに更新することをお勧めします。

    Rational Application Developer V6.0.1 では、 Faces Client ランタイム・リソースの更新は、古いリソースが含まれた Web プロジェクトがイン ポートされるか、古いリソースが含まれたワークスペースが開かれたときに自動的に行われます。 WebSphere Studio Application Developer V5.1.x から Rational Application Developer V6.0.1 に Web プロジェクト をインポートするかワークスペースを開いた後で、Faces Client ランタイム・リソースを最新レベ ルに更新するように指示するプロンプトが表示されます。

    ランタイム・リソースを自動的に更新する

    Web プロジェクトに対して Faces Client ランタイム ・リソースを自動的に更新するには以下のようにします。

    1. Faces Client コンテンツが含まれた Web プロジェクト (またはワークスペース) を WebSphere Studio Application Developer V5.1.x からインポートする。 「プロジェクトのマイグレーション」ウィンドウが開きます。
      注:
      「プロジェクトのマイグレーション」ウィンドウが開かない場合は、自動ビルドの設定がお そらく無効になっています。 プロジェクト・エクスプローラーで Web プロジェクトを右クリックして、 「ビルド」 -> 「プロジェクト」を選択します。これにより、プロジェ クトの再ビルド・プロセスが実行されて、「プロジェクトのマイグレーション」ウィンドウが開き ます。
    2. Faces Client コンテンツが含まれた他の Web プロジェクトがワークスペース内にある場合 は、「アップグレードの必要がある他のプロジェクトにこの選択 を適用する」チェック・ボックスを選択すると、すべての Web プロジェクトが更新される。
    3. 次のいずれかをクリックする。
    4. Web プロジェクト内の「Java Resources」 -> 「JavaSource」フォルダーから、 com.ibm.dynwdo4jsmediators.<client-data-name> という命名規則に従ったすべてのクライ アント・データ・メディエーター・クラス・パッケージを削除する。 com.ibm.dynwdo4jsmediators という名前のパッケージは削除しないでください。 このパッケージには、メディエーターを再生 成するのに使用される、プロジェクト内のクライアント・データのメタデータ (ecore ファイルと emap ファイル) が含まれています。
    5. Web プロジェクト内の「Java Resources」 -> 「JavaSource」フォルダーから、 OdysseyBrowserFramework.properties ファイルを開いて、EMAP_FILESECORE_FILES のエントリーを削除する。
    6. 「クライアント・データ」ビュー内のデータ・オブジェクトごとに以下を実行する。
      1. 右クリックして「構成」を選択する。
      2. 拡張」タブで、「サーバー・ サイド・データから再生成する (Regenerate from server-side data)」をクリックして、そのデータ・オブジェクトのすべての メディエーターを再生成する。

    ランタイム・リソースを手動で更新する

    Web プロジェクトに対して Faces Client ランタイム・リソースを手動で更新するには、以下のようにします。

    1. Web プロジェクトでの Faces ランタイム・リソースの更新』の『ランタイム・リソースを手動で更新 する』のステップを実行する。
    2. 上記の『ランタイム・リソースを自動的に更新する』セクショ ンのステップ 4 から 6 を実行する。

    Faces Client コンポーネントが含まれたプロジェクトのターゲット・サーバーを WebSphere Application Server V5.1 から V6.0 に 変更するときには問題が発生する可能性があります。

    Faces Client コンポーネントが含まれたプロジェクトのタ ーゲット・サーバーを WebSphere Application Server V5.1 から V6.0 に変更すると、次の 2 つの問題が発生する可能性があります。

    自動化された Diff ハンドラーおよびプロセッサーにアップグレードする

    現在は Diff プロセッサーおよびハンドラーは自動生成されます。Faces Client コンポーネントの Diff ハンドラーおよびプロセッサーを WebSphere Studio V5.1.x で作成した場合は、そのコードを廃棄して、次のように自動的に生成されるプロセッ サーとハンドラーを使用することをお勧めします。

    1. Web プロジェクト内の各クライアント・データ・オブジェクトで新しい Diff ハンドラーと プロセッサーを生成する。
      1. クライアント・データ・オブジェクトを選択して右クリックし、「構成」を選択する。
      2. 拡張」タブで「すべて再生成」をクリックする。
    2. 生成されたプロセッサーとハンドラーは自動的に呼び出されるため、Diff プロセッ サーとハンドラーを呼び出すために作成したコードを除去する。このコードが使用されていた場所の 典型的な例は、次のような「コマンド・ボタン」コンポーネントの「コマンド」イベントです。
      String Diff = getClientData1().getDiffStr();
      if (DiffProcessor.Synch(getRoot(), Diff) == true)
       return "";
      return "failure";
      
    3. 作成した古いカスタム・ハンドラーおよびプロセッサーに対応するファイルを Web プロジェクトから除去する。

    V5.1.x 用に作成されたカスタム Diff ハンドラーおよびプロセッサーを保持する

    これは推奨されませんが、 V5.1.x のカスタム Diff ハンドラーおよびプロセッサーを保持する必要があると判断した場合は、これらを V6.0 で機能させるためには変更が必要になります。その理由は、DiffHandler インターフェースと DiffInfo クラスが変更されているためです。

    V6.0 での Faces Client コンポーネントの変更点


    Struts Web プロジェクトのマイグレーション

    WebSphere Studio V5.1.x で作成した Struts Web プ ロジェクトについては、EAR プロジェクト を WebSphere Application Server V6.0 で実行するためには、この Web プロジェクトのデプロイメント記述子に小さな変更を加える必要があります。また、既存の Struts 1.0.2 Web プロジェクトまたは Struts 1.1 ベータ (2 または 3) Web プロジェクトを Struts 1.1 に手動で 変換することもお勧めします。

    既存の Struts Web プロジェクトのデプロイメント記述子を変更する

    Struts プロジェクトを WebSphere Studio v5.x で作成した場合、この Web プロジェクトのデプロイメント記述子内の config パラメーター (<param-name>config</param-name>) は WEB-INF/struts-config.xml に設定されます。 WebSphere Application Server V6.0 では、このパラ メーターの先頭に "/" が配置されている必要があります。 WebSphere Studio V5.1.x で作成された Struts Web プロジェクトを WebSphere Application Server V6.0 で実行した場合は、EAR プロジェクトの開始時に java.net.MalformedURLException 例外が発生する可能性があります。

    注:
    Rational Application Developer V6.0 では、新しい Struts プロジェクトが作成されると "/" が自動的に追加されますが、WebSphere Studio V5.1x からマイグレーションする場 合は "/" を手動で追加する必要があります。

    WebSphere Studio v5.1.x で作成された Struts Web プロジェクトの デプロイメント記述子を V6.0 で修正するには、以下のステップに従います。

    1. プロジェクト・エクスプローラーで Struts Web プロジェクトを開く。
    2. プロジェクト・エクスプローラーでその Web プロジェクトの Web「デプロイメント記述子」ファイルをダブルクリックする。 Web デプロイメント記述子エディターが開きます。
    3. ソース」タブをクリックして「ソース」 ページを開く。
    4. 次の行を変更する。

      <param-value>WEB-INF/struts-config.xml</param-value> (この行は <servlet></servlet> タグ内に 配置されています)

      変更後

      <param-value>/WEB-INF/struts-config.xml</param-value>

    5. Web デプロイメント記述子を保管する。

    これにより、EAR プロジェクトの再始動時に java.net.MalformedURLException 例外が発生 しなくなります。

    Struts 1.1 ベータ Web プロジェクトを Struts 1.1 に変換する

    WebSphere Studio V5.1.x では、Struts ランタイム・ライブラリー は、V5.0.x の Struts 1.1 ベータ (2 または 3) から Struts 1.1 (最終) にステップアップさ れました。 既存の Struts 1.1 ベータ (2 または 3) Web プロジェクトがある場合に、これらのプロジ ェクトを Struts 1.1 (最終) に変換したい場合は、手動で変換できます。 (: Struts 1.1 ベータ (2 または 3) ・プロジェクトを Struts 1.1 に変換することは必 須ではありません。)

    Struts 1.1 ベータ (2 または 3) プロジェクトを Struts 1.1 に変換するには、以下のよ うにします。

    1. Struts 1.1 ベータ・プロジェクトを Rational Application Developer V6.0 ワークスペースにロードす る。
    2. 例えば Struts11 という名前の新しい Struts 1.1 Web プロジェクトを作成する。 この一時プロジェクトを作成する理由は、実際のプロジェクトを変換する際に必要となる Struts 1.1 ランタイム・ファイルへの便宜的なアクセスを可能にするためです。 完了したらこのプロジェクトを削除できます。
    3. Struts 1.1 に変換したい Struts 1.1 ベータ・プロジェクトごとに以下を実行する。
      1. 次の JAR ファイルをプロジェクトの Web Content/WEB-INF/lib ディレクトリーから削除する。
        • commons-*.jar
        • struts.jar
      2. 次の JAR ファイルを Struts11/WebContent/WEB-INF/lib ディレクトリーからプロジェクト の Web Content/WEB-INF/lib ディレクトリーにコピーする。
        • commons-*.jar
        • struts.jar
      3. struts-*.tld というタグ・ライブラリー記述子 (TLD) ファイルをプロジェクトの Web Content/WEB-INF ディレクトリーから削除する。
      4. struts-*.tld という TLD ファイルを Struts11/WebContent/WEB-INF ディレクトリーから プロジェクトの Web Content/WEB-INF ディレクトリーにコピーする。

    Struts 1.0.2 Web プロジェクトを Struts 1.1 に変換する

    WebSphere Studio V5.1.x (および V5.0.x) では、Struts サポートを Web プロジェクトに追加する際には、Struts 1.0.2 を選択するというオプションがありました。既存の Struts 1.0.2 Web プロジェクトがある場合に、これらのプロジェクトを Struts 1.1 に変換 したい場合は、これらを手動で変換できます。 (: Struts 1.1 ベータ (2 または 3) ・プロジェクトを Struts 1.1 に変換することは必 須ではありません。)

    Struts 1.0.2 プロジェクトを Struts 1.1 に変換するには、以下のようにします。

    1. Struts 1.0.2 プロジェクトを Rational Application Developer V6.0 ワークスペースにロードす る。
    2. 例えば Struts11 という名前の新しい Struts 1.1 Web プロジェクトを作成する。 この一時プロジェクトを作成する理由は、実際のプロジェクトを変換する際に必要となる Struts 1.1 ランタイム・ファイルへの便宜的なアクセスを可能にするためです。 完了したらこのプロジェクトを削除できます。
    3. Struts 1.1 に変換したい Struts 1.0.2 プロジェクトごとに以下を実行する。
      1. struts.jar ファイルをプロジェクトの Web Content/WEB-INF/lib ディレクトリーから削除する。
      2. 次の JAR ファイルを Struts11/WebContent/WEB-INF/lib ディレクトリーからプロジェクト の Web Content/WEB-INF/lib ディレクトリーにコピーする。
        • commons-*.jar
        • struts.jar
        • jarkarta-oro.jar
      3. struts-*.tld というタグ・ライブラリー記述子 (TLD) ファイルをプロジェクトの Web Content/WEB-INF ディレクトリーから削除する。
      4. struts-*.tld という TLD ファイルを Struts11/WebContent/WEB-INF ディレクトリーから プロジェクトの Web Content/WEB-INF ディレクトリーにコピーする。

    V6.0 でのデバッガーの変更

    Rational Application Developer V6.0 では デバッグ・ツールに多くの変更があります。 マイグレーション後、これらのツールをプロジェクトで使用する場合、 この変更に注意する必要があります。設定の変更または復元が必要な場合があります。

    ワークスペースおよび起動構成のマイグレーション

    WebSphere Studio Application Developer からの V5.1.x ワークスペース が Rational Application Developer V6.0 で開かれたとき、 そのワークスペースと関連した以下のデバッガー起動構成は自動的にマイグレーションされません。

    デバッグ・ビュー

    ストレージ・ビューとストレージ・マッピング・ビュー は最早存在しません。それらのビューは、メモリー・ビューとメモリー・レンダリング・ビューに置換されました。

    XSLT デバッガー

    XSLT デバッガー は V6.0 で変更され、そのビューとアクションの多くでかなりの変更がありました。 詳しくは、インフォメーション・センターにある XSLT デバッガー文書を参照してください。

    XSLT デバッガーの最も大きな変更の 1 つは、 Rational Application Developer V6.0 と共にインストールされる JRE に対する依存です。 WebSphere Studio Application Developer V5.1.x から ワークスペースをマイグレーションした場合、 そのワークスペースに対する XSLT デバッグ・セッションを起動する前に、 インストール済み JRE が正しいロケーションを指すように変更する必要があります。 このためには、次のいずれかのアクションを実行することができます。


    WDO から SDO へのマイグレーション

    WebSphere Data Objects (WDO) リレーショナル・レコード またはリレーショナル・レコード・リストを使用した WebSphere Application Server V5.1 をターゲットとする Web プロジェクトでコードを作成した場合は、 これらのアプリケーションのターゲットを WebSphere Application Server V6.0 に変更すると、Service Data Objects (SDO) リレーショナル・レコード およびリレーショナル・レコード・リストを使用することになります。WDO から SDO へのマイグレーションは、 アプリケーションのターゲット・サーバーを WebSphere Application Server V5.1 から WebSphere Application Server V6.0 に変更したときに自動的に行われます。

    ターゲット・サーバーを変更する方法は 2 つあります。

    ターゲット・サーバーの変更方法および J2EE マイグレーション・ウィザードの使用方法 のヘルプ・トピックは、Rational Application Developer のオンライン・ヘルプにあります。

    互換性の考慮事項

    WDO から SDO へのマイグレーションの後に型の衝突エラーが 発生することがある

    WDO を使用するプロジェクトが SDO ベースのプロジェクトに マイグレーションされた後、SDO データを既存の WDO データのある既存の JSP ページに 追加すると、型の衝突エラーが発生することがあります。これは、既存の WDO アクセス Bean と独立型の SDO API の混合が原因です。例えば、JSP の Java ソース・ファイル上で次のような コンパイル・エラーが発生することがあります。

    The import com.ibm.websphere.sdo.mediator.exception.MediatorException collides with another imported type
    

    これらの型の衝突エラーは、以下のようにして訂正できます。

    1. 衝突する import 文を Java ソース・ファイルから除去する。前述の例を使用して、 次の import 文をソース・ファイルから除去する。
      import com.ibm.websphere.wdo.mediator.exception.MediatorException;
      
    2. その型を参照して完全修飾クラス名を使用する Java ソース・ファイルを変更する。前述の例を基に、 型 MediatorExceptioncom.ibm.websphere.wdo.mediator.exception.MediatorException に変更する必要があります。 例えば、
      catch ( MediatorException e1 ) {
      

      として書かれたソース・コードは、

      catch ( com.ibm.websphere.wdo.mediator.exception.MediatorException e1 ) {
      

      に変更する必要があります。

    ターゲット・サーバーを V5.1 から V6.0 (WDO から SDO) に 変更した後の Web プロジェクトの変更

    ターゲット・サーバーが V5.1 から V6.0 に 変更されると、自動的に以下の変更が行われます。

    サーバー・ターゲットを V6.0 から V5.1 (SDO から WDO) に変更した後の Web プロジェクトへの変更

    ターゲット・サーバー が V6.0 から V5.1 に変更されると、自動的に以下の変更が行われます。

    アプリケーションの J2EE レベルを 1.3 から 1.4 に 変更した後の Web プロジェクトへの変更

    サーバー・ターゲットを WebSphere Application Server V6.0 に変更することにより WDO から SDO にマイグレーションするために 発生する変更のほかに、アプリケーションの J2EE 仕様レベルを 1.3 から 1.4 に変更すると、 JavaServer Page (JSP) のタグ・ライブラリー (taglib) 参照が、 WDO、JSTL 1.0 タグ・ライブラリーから SDO、JSTL 1.1/jsp 2.0 タグ・ライブラリーを 使用するように更新されます。以下の表は、J2EE 1.3 から J2EE 1.4 に移動した場合の JSP taglib 参照の変更を示したものです。


    表 1. J2EE 1.3 および J2EE 1.4 での JSP taglib 参照

    J2EE 1.3 taglib (WDO) J2EE 1.4 taglib (SDO)
    http://www.ibm.com/websphere/wdo/core http://www.ibm.com/websphere/sdo/core
    http://java.sun.com/jstl/core http://java.sun.com/jsp/jstl/core
    http://java.sun.com/jstl/fmt http://java.sun.com/jsp/jstl/fmt
    http://java.sun.com/jstl/xml http://java.sun.com/jsp/jstl/xml
    http://java.sun.com/jstl/sql http://java.sun.com/jsp/jstl/sql

    V6.0 の EGL 予約語

    Rational Application Developer には、 エンタープライズ開発言語 (EGL) の新規予約語があります。

    以下に新規予約語をリストします。

    V6.0 ワークスペースにインポートされてビルドされ、 これらの予約語を変数またはパーツ名として使用する WebSphere Studio V5.1.x からの EGL プログラムには、 次のメッセージのタグが付きます:IWN.SYN.2002.e 39/2 Syntax error on input "variableName" ("variableName" の入力で構文エラー)。この問題は変数名を変更することで訂正できます。


    第 2 章 Rational Application Developer V6.0 の Web プロ ジェクトに対する Faces ランタイム・リソースの更新

    Rational Application Developer V6.0 に元々付属 していた JavaServer Faces ランタイム・リソースと JavaServer Faces Client ランタイム・リソース は、Rational Application Developer V6.0.1 用に更新されました。 この旧製品バージョンで作成された Web プロジェクトでの開発を継続したい場合は、Faces ラ ンタイム・リソースと Faces Client ランタイム・リソースを最新レベルに更新することをお勧めします。

    Rational Application Developer V6.0.1 では、 Faces および Faces Client ランタイム・リソースの更新は、古い Faces または Faces Client ランタイム・リソースが含まれた Web プロジェクトがインポートされるか、古い Faces または Faces Client ランタイム・リソースが含まれたワークスペースが開かれたときに自動的に 行われます。 Rational Application Developer V6.0 から Rational Application Developer V6.0.1 に Web プロジェクトを インポートするかワークスペースを開いた後で、これらのランタイム・リソースを最新レベルに更新 するように指示するプロンプトが表示されます。

    ランタイム・リソースを自動的に更新する

    Web プロジェクトに対して Faces および Faces Client ランタイム・リソースを自動的に更新するには、以下のようにします。

    1. Faces または Faces Client コンテンツが含まれた Web プロジェクト (またはワークスペー ス) を Rational Application Developer V6.0 からインポートする。 「プロジェクトのマイグレーション」ウィンドウが開きます。
      注:
      「プロジェクトのマイグレーション」ウィンドウが開かな い場合は、自動ビルドの設定がおそらく無効になっています。 プロジェクト・エクスプローラーで Web プロジェクトを右クリックして、 「ビルド」 -> 「プロジェクト」を選択します。これにより、プロジェクトの再ビルド・プロセスが 実行されて、「プロジェクトのマイグレーション」ウィンドウが開き ます。
    2. Faces または Faces Client コンテンツが含まれた他の Web プロジェクトがワークスペース 内にある場合は、「アップグレードの必要がある他のプロジェクトにこの選択を適用す る」チェック・ボックスを選択すると、すべての Web プロジェクトが更新される。
    3. 次のいずれかをクリックする。

    ランタイム・リソースを手動で更新する

    Web プロジェクトに対して Faces および Faces Client ランタイム・リソースを手動で更新するには、以下のようにします。

    1. JSF601 という名前の新しい Web プロジェクトを作成する (または EGL で 作業をしている場合は JSF601 という名前の新しい EGL Web プロジェクトを作成する)。このプロジェクトは、最新ラン タイム・リソースのソースとしてのみ使用し、更新の完了後には削除できます。
    2. プロジェクト・エクスプローラーで JSF601 プロジ ェクトを右クリックし、メニューから「プロパティー」を選択する。
    3. Web プロジェクト・フィーチャー」をクリックして、「Faces 基本コンポーネントの追加」と「Faces Client Framework の追加」を選択し、「OK」をクリックする。
    4. EGL で作業をしている場合は、以下の手順で JSF ページを作成してください。
      1. 新規 EGL Web プロジェクトの WebContent フォルダーを右クリックする。
      2. 「新規」 -> 「その他」 -> 「Faces JSP ファイル」を選択する。
      eglintdebug.jar ファイルと eglintdebugsupport.jar ファイルが プロジェクトに追加されます。
    5. 更新したい既存の Faces プロジェクトごとに以下を実行する。
      1. プロジェクト・エクスプローラーで既存のプロジェクトを展開して、 WebContent/WEB-INF/lib/ フォルダー内のファイルを表示する。このディレクトリーにある 以下の JAR ファイルをすべて見つけて削除します。
        • eglintdebug.jar (EGL のみ)
        • eglintdebugsupport.jar (EGL のみ)
        • fda6.jar (EGL のみ)
        • fdaj6.jar (EGL のみ)
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • odc-jsf.jar
      2. 削除した JAR ファイルについて、JSF601 プロジェクトの WebContent/WEB-INF/lib ディレクトリーから同じ名前の JAR ファイルをコ ピーし、同じ場所のオリジナル・プロジェクトに貼り付ける。構成によっては、これらすべての JAR ファ イルがプロジェクトに含まれている必要はありません。したがって、オリ ジナル・プロジェクトになかった特定の JAR ファイルはコピーしないでくだ さい。
      3. EGL で作業をしている場合 は、 それぞれの EGL Web プロジェクトの名前を右クリックし、 「生成」をクリックする。その後、自動的にプロジェクトを ビルドしているのでない場合は、「プロジェクト」 -> 「すべてビルド」をクリックします。
    6. JSF601 Web プロジェクトを削除する。

    第 3 章 Rational Application Developer V6.0 Application Developer V6.0 のポートレット・プロジェクトに対する Faces ランタイム・リソースの更新

    Rational Application Developer V6.0 に付属していた JavaServer Faces ランタイム・リソースと JavaServer Faces Client ランタイム・リソースは、Rational Application Developer V6.0.1 用に更新されました。 この旧製品バージョンで作成されたポートレット・プロジェクトでの開発を継続したい場合は、 Faces ランタイム・リソースと Faces Client ランタイム・リソースを最新レベルに更新することをお勧 めします。

    Rational Application Developer V6.0.1 では、Faces および Faces Client ランタイム・リソースの更新は、古い Faces または Faces Client ランタイム・リソースが含まれたポートレット・プロジェクトやワークスペースが、インポートされたり、開かれたりしたときに自動的に行われます。Rational Application Developer V6.0 から Rational Application Developer V6.0.1 にポートレット・プロジェクトをインポートするかワークスペースを開くと、これらのランタイム・リソースを最新レベルに更新するように指示するプロンプトが表示されます。

    ランタイム・リソースを自動的に更新する

    ポートレット・プロジェクトに対して Faces および Faces Client ランタイム・リソースを自動的に更新するには、以下のようにします。

    1. aces または Faces Client コンテンツが含まれたポートレット・プロジェクト (またはワークスペース) を、 Rational Application Developer V6.0 からインポートする。 「プロジェクトのマイグレーション」ウィンドウが開きます。
      注:
      「プロジェクトのマイグレーション」ウィンドウが開かな い場合は、自動ビルドの設定がおそらく無効になっています。 プロジェクト・エクスプローラーで、ポートレット・プロジェクトを右クリックして、 「ビルド」 -> 「プロジェクト」を選択します。これにより、プロジェクトの再ビルド・プロセスが 実行されて、「プロジェクトのマイグレーション」ウィンドウが開きます。
    2. Faces または Faces Client コンテンツが含まれた他のポートレット・プロジェクトがワー クスペース内にある場合は、「アップグレードの必要がある他のプロジェクトにこの選択を適用す る」チェック・ボックスを選択すると、すべてのポートレット・プロジェクトが更新される。
    3. 次のいずれかをクリックする。
    4. ポートレット固有の Faces ランタイム・リソースである jsf-portlet.jar と jsf-wp.jar を更新するには、以下の手動更新ステップを実行する必要がある。

    ランタイム・リソースを手動で更新する

    ポートレット・プロジェクトに対して Faces および Faces Client ランタイム・リソースを手動で更新するには、以下のようにします。

    1. JSFP601 という名前の新しいポートレット・プロジェクトを作成する。このプロジェクトは、最新ランタ イム・リソースのソースとしてのみ使用し、更新の完了後には削除できます。
    2. プロジェクト・エクスプローラーで JSFP601 プロジ ェクトを右クリックし、メニューから「プロパティー」を選択する。
    3. Web プロジェクト・フィーチャー」をクリックして、 「ポートレット・プロジェクト用の Faces Client Framework の 追加」を選択し、「OK」をクリックする。
    4. 更新したい既存の Faces ポートレット・プロジェクトごとに以下を実行する。
      1. プロジェクト・エクスプローラーで既存のプロジェクトを展開して、 WebContent/WEB-INF/lib/ フォルダー内のファイルを表示する。このディレクトリーにある 以下の JAR ファイルをすべて見つけて削除します。
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.jar
        • odc-jsf.jar
      2. 削除した JAR ファイルについて、JSFP601 プロジェクトの WebContent/WEB-INF/lib ディレクトリーから同じ名前の JAR ファイルをコ ピーし、同じ場所のオリジナル・プロジェクトに貼り付ける。構成によっては、これらすべての JAR ファ イルがプロジェクトに含まれている必要はありません。したがって、オリジ ナル・プロジェクトになかった特定の JAR ファイルはコピーしないでくださ い。
        • ポートレット・プロジェクトで IBM(R) ポート レット API または個人リンク・コンポーネントを使用している場合は、jsf-wp.jar ファイルをオ リジナル・プロジェクトにコピーしてください。
        • odc-jsf.jar ファイルをコピーする場合は、odc-jsf-portlet.jar ファイルもコピーしてください。
    5. JSFP601 ポートレット・プロジェクトを削除する。

    第 4 章 J2EE プロジェクトのマイグレーション

    J2EE マイグレーション・ウィザードは、 Rational Application Developer V6.0 で、J2EE プロジェクトを J2EE 1.4 仕様レベルにマイグレーションするよう更新されました。 J2EE マイグレーション・ウィザードはすべての J2EE モジュール・タイプで、 J2EE 1.2 と 1.3 仕様両方からの J2EE 1.4 仕様レベルへのマイグレーションをサポートしています。

    J2EE 1.3 および 1.2 仕様レベルの成果物を J2EE 1.4 仕様レベルに マイグレーションすることについて詳しくは、「J2EE 1.3 から 1.4 仕様レベルへのマイグレーション」および 「J2EE 1.2 から 1.4 仕様レベルへのマイグレーション」を参照してください。

    注:
    J2EE マイグレーション・ウィザード を使用する前に、以下のステップを実行するよう強くお勧めします。

    以下のようにして J2EE マイグレーション・ウィザードにアクセスできます。

    1. J2EE パースペクティブの「J2EE 階層」ビューで、 マイグレーションしたいエンタープライズ・アプリケーション・プロジェクトを 右マウス・ボタンでクリックする。
    2. ポップアップ・メニューから 「マイグレーション」 -> 「J2EE マイグレーション・ウィザード」の順に選択する。
    3. J2EE マイグレーション・ウィザードの「ようこそ」ページの指示に従って、 マイグレーション・プロセスを進める。

    注:

    J2EE マイグレーション・ウィザードの使用方法について詳しくは、 オンライン・ヘルプを参照してください。ウィザードの変更については、 「Rational Application Developer V6.0 での J2EE マイグレーション・ウィザードの変更」に説明があります。

    J2EE 1.3 および 1.2 仕様レベルを J2EE 1.4 にマイグレーションした場合の成果物の変更について詳しくは、 「J2EE 1.3 から 1.4 仕様レベルへのマイグレーション」および 「J2EE 1.2 から 1.4 仕様レベルへのマイグレーション」を参照してください。


    セキュア Web サービスのマイグレーション

    セキュア Web サービスは、Web サービスが J2EE 1.3 から J2EE 1.4 にマイグレーションされるときに J2EE マイグレーション・ウィザード によってマイグレーションが行われません。セキュア Web サービスのマイグレーションには 手動ステップが必要です。

    J2EE のマイグレーション後に、以下の手順でセキュア・バインディングと 拡張ファイルを手動で J2EE 1.4 にマイグレーションする必要があります。

    1. webservices.xml ファイルをダブルクリックして Web サービス・エディターを開く。
    2. バインディング構成」タブを選択して、 バインディング・ファイルを編集する。
    3. 要求コンシューマー・バインディング構成の詳細」 および「応答生成プログラム・バインディング構成の詳細」という新規セクションの下に 必要なバインディング構成をすべて追加する。
    4. 拡張」タブを選択して拡張ファイルを編集する。
    5. 要求コンシューマー・サービス構成の詳細」および 「応答生成プログラム・サービス構成の詳細」という新規セクションの下に 必要な拡張構成をすべて追加する。
    6. 保管してエディターを終了する。

    J2EE 1.3 から 1.4 仕様レベルへのマイグレーション

    J2EE プロジェクトは J2EE 1.3 から J2EE 1.4 仕様レベルに マイグレーションすることができます。このセクションでは、J2EE プロジェクトの各タイプごとに、 J2EE マイグレーション・ウィザードにより J2EE 1.3 から J2EE 1.4 に マイグレーションされる成果物について説明します。

    Enterprise JavaBean プロジェクト (EJB 2.0 から EJB 2.1)

    J2EE マイグレーション・ウィザードは、 エンタープライズ Bean デプロイメント記述子の、J2EE 1.3 仕様レベルの EJB リソースから J2EE 1.4 へのマイグレーションをサポートします。ステートレス・セッション Bean およびメッセージ駆動型 Bean が J2EE 1.4 にマイグレーションされます。

    セッション Bean のマイグレーション

    J2EE マイグレーション・ウィザードは、 ステートレス・セッション Bean に Service endpoint interface を設定することにより、 J2EE 1.3 の EJB プロジェクトの webservices.xml 記述子に service endpoint interfaces (SEI) として定義されているステートレス・セッション Bean を 1.4 仕様レベルに マイグレーションします。

    J2EE 1.4 仕様では、セッション bean が Web サービスのエンドポイントとして 使用される場合、SEI がステートレス・セッション Bean に定義されている 必要があります。EJB JAR ファイルのマイグレーション中、 EJB プロジェクト内のすべてのセッション Bean では、EJB プロジェクトの webservices.xml 記述子で 使用されている名前にサービス・エンドポイントが設定されます。以下は、 J2EE 1.4 仕様レベルへのマイグレーションの 前と後で EJB プロジェクトのメタデータがどのように変化するかについて例を 示したものです。

    J2EE 1.3 の EJB プロジェクト: マイグレーション前、 Web サービス・エンドポイントとして使用されるステートレス・セッション Bean を持つ webservices.xml 記述子

    <?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>
                <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>
    

    前の例の <service-endpoint-interface> タグと <service-impl-bean> タグは、マイグレーション前、 J2EE 1.3 仕様レベルの webservices 記述子のサービス・エンドポイントとして ステートレス・セッション Bean "EchoEJB" を定義しています。

    J2EE 1.4 の EJB プロジェクト: マイグレーション・プロセスで作成されたサービス・エンドポイント・インターフェースを 持つ同じステートレス・セッション Bean "EchoEJB" の EJB デプロイメント記述子

    <?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>
    

    前の例の <service-endpoint> タグは、 マイグレーション後、"EchoEJB" を J2EE 1.4 仕様レベルのサービス・エンドポイントとして定義しています。

    メッセージ駆動型 Bean のマイグレーション

    J2EE マイグレーション・ウィザードは、 EJB 2.0 から EJB 2.1 メッセージ駆動型 Bean へのマイグレーションをサポートします。

    メッセージ駆動型 Bean は、Java Message Service (JMS) からの非同期メッセージの処理をサポートするために、EJB 2.0 で導入さ れました。EJB 2.1 仕様は、JMS だけでなく、あらゆるメッセージング・システムをサポートできるように、 メッセージ駆動型 Bean の定義を拡張しました。

    注:
    EJB 2.0 仕様レベルから EJB 2.1 にマイグレーションさ れて、WebSphere Application Server バージョン 6 にデプロイされたメッセージ駆動型 Bean は 、リスナー・ポートの代わりに、Java Connector Architecture (JCA) 1.5 リソース・アダプター に対してデプロイされる必要があります (WebSphere Application Server バージョン 5 の場合と 同様です)。EJB 2.1 メッセージ駆動型 Bean で JCA アダプターを使用するには、デプロイメント記述 子エディターを使用して WebSphere バインディングの設定を変更する必要があります。 『JCA アダプターを使用するための EJB 2.1 メッセージ駆動型 Bean の構成』を参照してください。

    マイグレーションされる EJB 2.0 メッセージ駆動型 Bean の成果物は以下の通りです。

    EJB 2.0 メッセージ駆動型 Bean エレメントの一部は、 activation-config プロパティーに置換されました。 メッセージング・サービスを記述するために activation-config プロパティーで使用される プロパティー名と値は、使用されるメッセージ・サービスのタイプによって異なります。 ただし、EJB 2.1 は JMS ベースのメッセージ駆動型 Bean に対して固定された プロパティーのセットを定義します。

    以下の例は、EJB 2.0 のサンプル Bean の エレメントが EJB 2.1 でどのように表示されるかを比較したものです。

    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>
    	     <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 仕様レベルにマイグレーションされて、WebSphere Application Server バージョン 6 にデプロイされたメッセージ駆動型 Bean は、リスナー・ポートの代わりに、 Java Connector Architecture (JCA) 1.5 リソース・ア ダプターに対してデプロイされる必要があります。

    次のステップでは、JCA アダプターを使用するように EJB 2.1 メッセージ駆動型 Bean のデプ ロイメント記述子を変更する方法を説明します。

    1. プロジェクト・エクスプローラーで EJB プロジェクトを開く。
    2. プロジェクト・エクスプローラーでその EJB プロジェクトの 「デプロイメント記述子 (Deployment Descriptor)」フ ァイルをダブルクリックする。 EJB デプロイメント記述子エディターが開きます。
    3. Bean」タブをクリックして 「Bean」ページを開く。
    4. EJB プロジェクト内の EJB 2.1 メッセージ駆動型 Bean ごとに、以下を実行する。
      1. 「Bean」ページの左側にある Bean のリストで、EJB 2.1 メッセージ駆動型 Bean を選択する。
      2. WebSphere バインディング」の ヘッダーの下で「JCA アダプター」ボタンを選択する。
      3. 以下のバインディング・デプロイメント・プロパティーを指定する。
        1. ActivationSpec JNDI 名

          このメッセージ駆動型 Bean をデプ ロイするのに使用される J2C 活動化仕様の JNDI 名を入力します。 この名前は、 WebSphere Application Server に対して定義する J2C 活動化仕様の名前と一致する必要があります。

        2. ActivationSpec 許可別名

          JCA リソース・アダプターへの接続を 認証するために使用される J2C 認証別名の名前です。 J2C 認証別名により、JCA リソース・アダプターへの新しい接続の作成を認証するのに使用される ユーザー ID とパスワードが指定されます。

        3. 宛先 JNDI 名

          メッセージ駆動型 Bean が JNDI 名前空間で JMS 宛先を検索するのに使用する JNDI 名を入力します。

    5. 変更を保管して、デプロイメント記述子エディターを閉じる。

    Web プロジェクト (サーブレット・レベル 2.3 からサーブレット・レベル 2.4)

    Web デプロイメント記述子の成果物は、 J2EE 1.3 レベル Web プロジェクトが J2EE 1.4 にマイグレーションされるときに J2EE マイグレーション・ウィザードによってマイグレーションされます。

    以下の Web アプリケーション成果物がマイグレーションされます。

    認証制約

    J2EE 1.4 には、languagevalue という 2 つの属性を持つ Description オブジェクトが組み込まれています。 この Description オブジェクトは J2EE 1.3 にはありませんでした。 description は認証制約の属性でした。したがって、Web デプロイメント記述子の成果物が J2EE 1.4 にマイグレーションされると、Description オブジェクトの value は認証制約の description 属性から取られます。

    セキュリティー制約

    同様に、J2EE 1.3 では description はセキュリティー制約の属性でした。J2EE 1.4 では、 languagevalue という属性を持つ 新規 Description オブジェクトがあります。 したがって、Description オブジェクトの value は セキュリティー制約の description 属性から取られます。

    Web アプリケーション

    J2EE 1.3 仕様レベルの ContextParam オブジェクト の description ストリング属性は、J2EE 1.4 では ParamValue の Description オブジェクトに移動されました。

    J2EE 1.3 の TagLib オブジェクトは、J2EE 1.4 では JSPConfig オブジェクトに移動されました。JSPConfig オブジェクトは、 1.3 では Web root オブジェクトに属していました。

    コネクター・プロジェクト (JCA 1.0 から JCA 1.5)

    J2EE マイグレーション・ウィザードは、J2EE Connector Architecture (JCA) 1.0 記述子 の成果物を JCA 1.5 にマイグレーションします。マイグレーションされた成果物は、 OutboundResourceAdaptor と ConnectionDefinition という 2 つの新規オブジェクトとして、ResourceAdaptor オブジェクトのエレメントに 関連付けられます。これらはコネクター・プロジェクトの J2EE 1.4 仕様レベルの ResourceAdaptor オブジェクトに追加されました。

    以下はマイグレーション済みエレメントのマッピングについての説明です。

    Web サービス (J2EE 1.3 から J2EE 1.4)

    J2EE 1.4 仕様では、新規 JAX-RPC 1.0 API を介した Web サービスへのサポートが追加されました。

    JAX-RPC API は以下を通じてサービス・エンドポイントをサポートします。

    J2EE 1.4 仕様は、J2EE 仕様 (JSR 109) に対する Web サービスを サポートします。JSR 109 は Web サービスのデプロイメント要件を定義して、 JAX-RPC プログラミング・モデルを使用します。

    以下の Web サービス成果物が J2EE マイグレーション・ウィザードを使用してマイグレーションされます。

    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 での修飾名は、XML ネームスペースを使用する XMLSchema QName タイプを 基にしています。

    以下では各 Web サービス・デプロイメント記述子の マイグレーションについてさらに詳しく説明します。


    J2EE 1.2 から 1.4 仕様レベルへのマイグレーション

    J2EE モジュールは J2EE 1.2 仕様レベルから J2EE 1.4 に マイグレーションすることができます。このセクションでは、J2EE プロジェクトで J2EE マイグレーション・ウィザードにより J2EE 1.2 から J2EE 1.4 仕様レベルに マイグレーションされる成果物について説明します。

    J2EE マイグレーション・ウィザードの使用法について詳しくは、 「第 4 章, J2EE プロジェクトのマイグレーション」を参照してください。

    Enterprise JavaBeans プロジェクトのマイグレーション (EJB 1.1 から EJB 2.1)

    このセクションでは、EJB 1.1 から EJB 2.1 仕様レベルへの EJB プロジェクトのマイグレーションについて説明します。

    EJB 1.1 から EJB 2.1 への EJB プロジェクトのマイグレーションでは、 container-managed persistence (CMP) Entity Bean のマイグレーションが行われます。

    J2EE 1.3 と J2EE 1.4 仕様レベルの間で Entity Bean に変更はありません。 EJB 1.1 から EJB 2.1 仕様レベルへの CMP Entity Bean のマイグレーションは、 EJB 1.1 から EJB 2.0 への CMP Entity Bean のマイグレーションと同じ方法で 実行されます。container-managed Entity Bean を EJB 1.1 から EJB 2.x 仕様レベルにマイグレーションするには、以下のステップが必要です。

    1. EJB EJB プロジェクトを EJB 1.1 から EJB 2.x に変換する。
    2. EJB コードを EJB 1.1 から EJB 2.x にマイグレーションする。
    3. ユーザー定義の EJB 1.1 参照を EJB 2.x のローカル参照にマイグレーションする。

    EJB 1.1 から EJB 2.x へのプロジェクトの変換

    EJB 1.1 プロジェクトは、J2EE マイグレーション・ウィザードを使用して EJB 2.x プロジェクトに変換することができます。

    あるいは、オリジナルの EJB 1.1 プロジェクトを保持したい場合は、 新規の 2.x プロジェクトを作成し、既存のプロジェクト JAR ファイルを そこにインポートすることができます (「ファイル」 -> 「インポート」 -> 「EJB JAR」)。

    このプロジェクトは EJB 2.x プロジェクトですが、既存の (あるいは インポートされた) EJB 1.1 container-managed persistence (CMP) Entity Bean は EJB 1.1 Bean のままとなります。すなわち、CMP Entity Bean は EJB 2.x に 変換されません。

    J2EE マイグレーション・ウィザードは EJB 2.x プロジェクト内の エンタープライズ Bean を 1.1 から 2.x にマイグレーションします (1.1 CMP Entity Bean を 2.x にマイグレーションするように選択した場合は、2.x プロジェクト内の すべての Bean をマイグレーションする必要があります。ただし、これらのマイグレーションされた 2.x Bean には選んでローカル・クライアント・ビューを追加することができます)。

    注:
    マップされた関連がある場合は、その関連自体に対して EJB 2.x の 関連が作成されますが、その関連の役割マップは無効になります。妥当性検査を実行すると エラーが発生します。これを回避するためには、最初にマッピング・エディターを開いて マップを保管してください。 役割マップが除去されます。その後、もう一度妥当性検査を実行して、 役割を再マップすることができます。

    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 もサポートします)。

    1. CMP 1.1 Bean については、各 CMP フィールドを getXXX および setXXX 抽象メソッドと置換します (Bean クラスは抽象である必要があります)。
    2. CMP については、基本キーの getXXX および setXXX 抽象 メソッドを作成します。
    3. CMP 1.1 ファインダー・メソッドについては、各ファインダー・メソッドごとに EJBQL (EJB 照会言語) メソッドを作成します。
      注:
      Rational Application Developer V6.0 では、 EJB 照会言語に以下の制限があります。
      • 他の EJB へのリレーションで構成されたキーを持つ EJB を使用する EJB 照会言語による照会は 無効とされ、デプロイメント時にエラーが発生します。
      • IBM EJB 照会言語サポートはいくつかの制限を緩和したり、 DB2 機能を さらに追加するなど、さまざまな方法で EJB 2.x 仕様を拡張します。各種ベンダー・データベース間や EJB デプロイメント・ツール間の移植を検討する場合は、 「EJB 2.x 仕様」の第 11 章にある指示に従って、 すべての EJB 照会言語クエリーを慎重に作成する必要があります。
    4. CMP 1.1 ファインダーについては、java.util.Enumeration の代わりに java.util.Collection を戻します。
    5. CMP 1.1 Bean については、ejbCreate() 内、およびコード内のどこでも、 this.field = value のすべてのオカレンスを setField(value) に変更します。
    6. 非アプリケーション例外の例外処理 (ロールバックの振る舞い) を更新します。
    7. アプリケーション例外の例外処理 (ロールバックの振る舞い) を更新します。
    8. ejbCreate 内のアプリケーション固有のデフォルト値の CMP 設定をすべて更新します (EJB 1.1 コンテナーは前のアプリケーション固有のデフォルトを上書きする ejbCreate を呼び出す前にすべてのフィールドを汎用のデフォルト値に 設定してしまうため、グローバル変数を使用しないで行います)。

    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 マイグレーション・ウィザードを使用して実行されません 。 以下のステップに従ってローカル参照をセットアップしてください。

    1. デプロイメント記述子エディターの「参照」ページで既存の EJB リモート参照を削除する。
    2. デプロイメント記述子エディターの「参照」ページで EJB ローカル参照を追加する。

    プロジェクト構造のマイグレーション中にマージされるメソッド・エレメント

    J2EE マイグレーション・ウィザードを使用したプロジェクト構造のマイグレーション中、 すべての Bean で同じタイプのメソッド・エレメント (セキュリティー ID、 コンテナー・トランザクション、メソッド許可、アクセス・インテント、および分離レベルなど) がマージされ、 論理的にグループ化されます。

    プロジェクト構造のマイグレーション前と後のメソッド・エレメントのサンプル。

    以下はプロジェクト構造のマイグレーション前の、 デプロイメント記述子エディターのソース・ページでのメソッド許可のサンプルです。

    		<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>
    				</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>
    				<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 レベル・アクセス・インテントを使用することをお勧めします。

    Web プロジェクト (サーブレット・レベル 2.2 からサーブレット・レベル 2.4)

    Web デプロイメント記述子の成果物は、J2EE 1.2 Web プロジェクトを J2EE 1.4 仕様レベルにマイグレーションするときに、J2EE マイグレーション・ウィザード によってマイグレーションされます。

    以下の Web アプリケーション成果物がマイグレーションされます。

    認証制約

    J2EE 1.4 には、languagevalue という 2 つの属性を持つ Description オブジェクトが組み込まれています。 この Description オブジェクトは J2EE 1.2 にはありませんでした。 description は認証制約の属性でした。したがって、Web デプロイメント記述子の成果物が J2EE 1.4 にマイグレーションされると、Description オブジェクトの value は認証制約の description 属性から取られます。

    セキュリティー制約

    同様に、J2EE 1.2 では description はセキュリティー制約の属性でした。J2EE 1.4 では、 languagevalue という属性を持つ 新規 Description オブジェクトがあります。 したがって、Description オブジェクトの value は セキュリティー制約の description 属性から取られます。

    Web アプリケーション

    J2EE 1.2 仕様レベルの ContextParam オブジェクト の description ストリング属性は、J2EE 1.4 では ParamValue の Description オブジェクトに移動されました。

    J2EE 1.2 の TagLib オブジェクトは、J2EE 1.4 では JSPConfig オブジェクトに移動されました。JSPConfig オブジェクトは、 1.2 では Web root オブジェクトに属していました。


    Rational Application Developer V6.0 での J2EE マイグレーション・ウィザードの変更

    Rational Application Developer V6.0 の J2EE マイグレーション・ウィザードに対して、すべての J2EE 仕様レベルに共通の変更が行われました。

    プロジェクト構造のマイグレーションはオプション

    WebSphere Studio V5.1.x から V5.1.2 までは、プロジェクト構造のマイグレーションは J2EE 仕様レベルのマイグレーションと同時に行われます。J2EE 仕様レベルをマイグレーションする場合、 プロジェクト構造のマイグレーションはオプションではありませんでした。

    Rational Application Developer V6.0 の J2EE マイグレーション・ウィザードでは、「プロジェクト構造体のマイグレーション」 は分離しており、「プロジェクト J2EE 仕様レベルのマイグレーション」 からのオプショナル選択です。J2EE 仕様レベルのマイグレーションと プロジェクト構造のマイグレーションは、独立して実行することができます。

    ターゲット・サーバーが必要

    Rational Application Developer V6.0 の場合、上位の J2EE 仕様レベルにマイグレーションする新規および 既存の J2EE プロジェクトでは、プロジェクトにターゲット・サーバーを設定する必要があります。 サーバー・ターゲット設定は、V6.0 で J2EE プロジェクトにどのようにクラスパスが設定されるかを決定する デフォルトのメカニズムです。ターゲット・サーバーの設定方法および J2EE マイグレーション・ウィザードの使用法について詳しくは、 オンライン・ヘルプを参照してください。


    第 5 章 Rational Application Developer V6.0 での Portal Tools のマイグレーション

    Portal Toolkit V5.0.2.2 プロジェクトは、Portal Toolkit ワークスペースをマイグ レーションするか、SCM (ソース・コード管理) システムからプロジェクトをロードするか、または プロジェクト交換フィーチャーを使用してプロジェクトをインポートすることにより、自動的に Rational Application Developer V6.0 Portal Tools にマイグレーション されます。Portal Toolkit の前のバージョンから マイグレーションする場合は、ポートレット・プロジェクトを WAR ファイルにエクスポートし、 その WAR ファイルを Rational Application Developer V6.0 の Portal Tools にインポートする必要があります。

    ポータル・アプリケーションをマイグレーションする前に、 Rational Application Developer V6.0 の Portal Tools 機能をインストールする必要があります。 「インストール・ガイド 」を参照してください。

    注:
    ポートレット・プロジェクトの後方互換性はサポートされていません。

    自動マイグレーションは、 WebSphere Studio V5.1.2 に組み込まれている Portal Toolkit V5.0.2.2 で作成されたプロジェクトでのみサポートされています。マイグレーションに ついて詳しくは、「第 1 章, WebSphere Studio V5.1、5.1.1、または 5.1.2 からのマイグレーション」を参照してください。

    ポートレット・プロジェクト がエンタープライズ・アプリケーション・プロジェクトと関連している場合は、 EAR プロジェクトに適切なターゲット・サーバーを設定する必要があります。ターゲット・サーバーは、 「サーバー・プロパティー」ページ (「プロパティー」 -> 「サーバー」) で設定できます。

    Portal Toolkit V5.0.2.2 プロジェクトのマイグレーション中、 いくつかの追加変更が行われます。

    Portal Toolkit の前のバージョンからマイグレーションする場合は、 以下の手順で、Rational Application Developer V6.0 の Portal Tools にポートレット・プロジェクトを手動でマイグレーションする必要があります。

    1. 既存プロジェクトを WAR ファイルにエクスポートする。 Portal Toolkit の前のバージョンで、それぞれのプロジェクトを ソース・ファイルと共に WAR ファイルにエクスポートします。
      1. プロジェクトを右クリックし、「エクスポート」を選択する。
      2. WAR ファイル」と 「ソース・ファイルのエクスポート」を選択し、 「終了」をクリックする。
    2. ポートレット WAR ファイルをインポートする。
      1. Rational Application Developer V6.0 の Portal Tools で空のポートレット・プロジェクトを新規作成する。
        1. 「ファイル」 -> 「新規」 -> 「プロジェクト」 -> 「ポータル」 -> 「ポートレット・プロジェクト (JSR 168)」を選択する。
        2. 「ポートレットの作成」を選択解除する。
        3. 「拡張を表示」をクリックする。
        4. WebSphere Portal 4.2 ポートレットを インポートする場合は、サーブレットのバージョンとして 2.2 を選択する。
        5. ターゲット・サーバーとして「WebSphere Portal v5.0」を選択し、 「終了」をクリックする。
      2. WAR ファイルを新規の空のポートレット・プロジェクトにインポートする。
        1. 「インポート」を選択する。
        2. 「WAR ファイル」を選択し、前述のステップ (前のバージョンの WAR ファイルにプロジェクトをエクスポートする) で エクスポートした WAR ファイル を指定する。
        3. 新しい空のポートレット・プロジェクトを選択する。
        4. 「警告を出さずに既存リソースを上書き」を選択する。
        5. 「上書きでプロジェクトを削除」は選択しない
    3. TLD ファイルを削除する。

      ポートレット TLD ファイルが存在する 場合は、プロジェクトから削除することをお勧めします。削除しないと、 プロジェクトを再ビルドしたときに警告メッセージを受け取ります。このファイルを残しておくと、 ポートレット・プロジェクトが WebSphere Portal にデプロイされて、 ポートレットの TLD ファイルがサーバーのファイルと異なる場合に問題が発生します。

    4. WebSphere Portal 4.2 ポートレットを マイグレーションする場合は、このマイグレーション済みポートレット・プロジェクトを WebSphere Portal 5.x にマイグレーションする必要があります。

    WebSphere Portal V4.2 ポートレットを V5.x に マイグレーションすることについて詳しくは、 「WebSphere Portal V4.2 ポートレットから V5.x へのマイグレーション」を参照してください。

    ポートレット・プロジェクトの Faces リソースのマイグレーションについて詳しくは、「ポートレット・プロジェクトでの Faces ランタイム・リソースの更新」 を参照してください。


    WebSphere Portal V4.2 ポートレットから V5.x へのマイグレーション

    Rational Application Developer V6.0 は、 WebSphere Portal V4.2 ポートレットの開発をサポートしていません。WebSphere Portal V4.2 ポートレット・プロジェクトを V5.x にマイグレーションする必要があります。

    WebSphere Portal V4.2 用に作成されたポートレットの多くは、 WebSphere Portal V5.x でそのまま変更せずに実行されます。いくつかのポートレット 4.2.x API は 現在「使用すべきではない」とマークされていますが、引き続き WebSphere Portal V5.x で使用できます。

    注:
    マイグレーションされたポートレット・アプリケーション・プロジェクトは後方互換ではありません。

    WebSphere Portal V4.2 のポートレット・アプリケーションを V5.x にマイグレーションするには、以下のステップを実行してください。

    1. Portal V4.2 ポートレット・プロジェクトを Portal V5.x ポートレット・プロジェクト にマイグレーションします。
      1. マイグレーションしたいポートレット・アプリケーション・プロジェクト を右クリックする。
      2. 「プロパティー」 -> 「ポートレット API」を選択して「ポートレット API」ページを開く。
      3. 「ポートレット API レベル」ドロップダウン・リストから 「WebSphere Portal バージョン 5.x」を選択する。
      4. OK」をクリックすると、自動的に以下の変更が行われる。
        • ポートレット API のタグ・ライブラリー記述子 (TLD) ファイルが存在する場合、除去される。
        • Web レベルが 2.2 から 2.3 に変更される。
        • WebSphere Portal JRE コンテナーおよび WebSphere Portal ランタイム・ターゲット・コンテナーが動的に ポートレット特定のクラスパス・エントリーを追加するため、それらが除去される。
    2. ポートレット・プロジェクトがエンタープライズ・アプリケーション・プロジェクトと 関連している場合は、EAR プロジェクトの J2EE レベルを J2EE 1.3 にマイグレーションすることをお勧めします。 WebSphere Portal V5.x 用に設計されたポートレット・アプリケーションは、J2EE レベル 1.3 仕様に 準拠しています。
      注:
      エンタープライズ・アプリケーション・プロジェクトを J2EE 1.3 にマイグレーションする前に、「第 4 章, J2EE プロジェクトのマイグレーション」 をお読みください。J2EE マイグレーション・ウィザードの使用法については、オンライン・ヘルプを参照してください。
      1. マイグレーションされたポートレット・プロジェクトがエンタープライズ・アプリケーション・プロジェクトと しか関連付けられていない場合は、以下のことを実行する。
        1. ワークベンチのすべてのエディターを閉じる。
        2. マイグレーションされたポートレット・プロジェクトが関連したエンタープライズ・アプリケーション・プロジェクトを 右クリックする。
        3. 「マイグレーション」 -> 「J2EE マイグレーション・ウィザード」を選択し、 「次へ」をクリックする。
        4. J2EE バージョン 1.3」と 「WebSphere Portal」をターゲット・サーバーとして選択する。
        5. 終了」をクリックする。
      2. 他にエンタープライズ・アプリケーション・プロジェクトに関連した ポートレット・プロジェクトがある場合は、 マイグレーションされたポートレット・プロジェクトを除去して、 それを別のエンタープライズ・アプリケーション・プロジェクトに追加する。
        1. マイグレーションされたポートレット・プロジェクトのモジュールを エンタープライズ・アプリケーション・プロジェクトから除去する。
          1. エンタープライズ・アプリケーション・プロジェクトを展開し、デプロイメント記述子を選択する。
          2. 「アプリケーションから開く」 -> 「デプロイメント記述子エディター」を選択する。
          3. 「モジュール」タブを選択する。エディターの「モジュール」ページで、 マイグレーションされたポートレット・プロジェクトの WAR ファイルを選択します。
          4. 「除去」をクリックする。
          5. 「ファイル」 -> 「保管」を選択して変更を保管する。
        2. 新規エンタープライズ・アプリケーション・プロジェクトを作成し、 それにポートレット・プロジェクトを追加する。
          1. 「ファイル」 -> 「新規」 -> 「プロジェクト」を選択する。
          2. 「すべてのウィザードを表示 (Show All Wizards)」チェック・ボックスを選択する。
          3. J2EE を展開し、「エンタープライズ・アプリケーション・プロジェクト」を選択する。
          4. プロジェクトの「名前」フィールドに入力し、 「J2EE バージョン 1.3」と「WebSphere Portal」をターゲット・サーバーとして選択し、 「次へ」をクリックする。
          5. 「EAR モジュール・プロジェクト」ページで、 マイグレーション済みポートレット・プロジェクトを選択し、 「終了」をクリックする。

    これで、ポートレット・プロジェクトが WebSphere Portal V5.x にマイグレーションされました。


    ポートレット・プロジェクトでの Faces ランタイム・リソースの更新

    WebSphere Studio Application Developer V5.1.2 に付属していた JavaServer Faces ランタイム・リソースは、Rational Application Developer V6.0.1 用に更新されました。 この旧製品バージョン用の Portal Toolkit 5.0.2.2 で作成されたポートレット・プロジェクト での開発を継続したい場合は、Faces ランタイム・リソースを最新レベルに更新することをお勧めします。

    Rational Application Developer V6.0.1 では、Faces ランタイム・リソースの更新は、古いリソースが含まれたポートレット・プロジェクトがインポー トされるか、古いリソースが含まれたワークスペースが開かれたときに自動的に行われます。Portal Toolkit 5.0.2.2 で作成した、WebSphere Studio Application Developer V5.1.x 用のポートレット・プロジェクトを Rational Application Developer V6.0.1 にインポートすると、Faces ランタイム・リソースを最新レベルに更新するように指示するプロンプトが表示されます。

    ランタイム・リソースを自動的に更新する

    ポートレット・プロジェクトに対して Faces ランタイム・リソースを自動的に更新するには、以下のようにします。

    1. Faces コンテンツが含まれたポートレット・プロジェクトを WebSphere Studio Application Developer V5.1.x からインポートする。 「プロジェクトのマイグレーション」ウィンドウが開きます。
      注:
      「プロジェクトのマイグレーション」ウィンドウが開かな い場合は、自動ビルドの設定がおそらく無効になっています。 プロジェクト・エクスプローラーで、ポートレット・プロジェクトを右クリックして、 「ビルド」 -> 「プロジェクト」を選択します。これにより、プロジェクトの再ビルド・プロセスが 実行されて、「プロジェクトのマイグレーション」ウィンドウが開きます。
    2. Faces コンテンツが含まれた他のポートレット・プロジェクトがワークスペース内にあ る場合は、「アップグレードの必要がある他のプロジェクトにこの選択を適用する」チェック・ボックスを選択すると、すべてのポートレット・プロジェクトが更新される。
    3. 次のいずれかをクリックする。
    4. ポートレット固有の Faces ランタイム・リソースである jsf-portlet.jar と jsf-wp.jar を更新するには、以下の手動更新ステップを実行する必要がある。
    注:
    Faces Client コンポーネントが含まれた Faces JSP を作成した場合は 、Faces Client コンポーネント・ランタイム・リソースを別個に最新レベルに更新す る必要があります。「Web プロジェクトでの Faces Client ランタイム・リソースの更新」 を参照してください。

    ランタイム・リソースを手動で更新する

    ポートレット・プロジェクトに対して Faces ランタイム・リソースを手動で更新するには、以下のようにします。

    1. Faces コンテンツが含まれた既存のポートレット・プロジェクトを Rational Application Developer V6.0.1 ワークスペースにインポートする。
    2. 2 ページ目で「Faces ポートレット」オプションを選択して 、JSFP601 という名前の新規ポートレット・プロジェクトを作成する。このプロジェクトは、 最新ランタイム・リソースのソースとしてのみ使用し、更新の完了後には削除できます。
    3. プロジェクト・エクスプローラーで JSFP601 プロジェクトを右クリックし、 メニューから「プロパティー」を選択する。
    4. Web プロジェクト・フィーチャー」をクリックして、 「ポートレット・プロジェクト用の Faces Client Framework の 追加」を選択し、「OK」をクリックする。
    5. 更新したい既存の Faces プロジェクトごとに以下を実行する。
      1. プロジェクト・エクスプローラーで既存のプロジェクトを展開して、 WebContent/WEB-INF/lib/ フォルダー内のファイルを表示する。このディレクトリーにある 以下の JAR ファイルをすべて見つけて削除します。
        • jsf-api.jar
        • jsf-ibm.jar
        • jsf-impl.jar
        • jsf-portlet.jar
        • odc-jsf.jar
      2. WebContent/WEB-INF/faces-config.xml ファイルを見つけて開く。 以下のエレメントが まだこの構成ファイルにない場合、追加します。
        	<lifecycle>
        		<phase-listener>com.ibm.faces.webapp.ValueResourcePhaseListener</phase-listener>
        	</lifecycle>
        	
        	<application>
        		<variable-resolver>com.ibm.faces.databind.SelectItemsVarResolver</variable-resolver>
        		<variable-resolver>com.ibm.faces.application.WPPortletVariableResolver</variable-resolver>
        		<property-resolver>com.ibm.faces.databind.SelectItemsPropResolver</property-resolver>
        	</application>
        
        注:
        ポートレット・プロジェクトが JSR 168 API を使用している場合は、 com.ibm.faces.application.WPPortletVariableResolver ではなく、 com.ibm.faces.application.PortletVariableResolver を指定してください。
      3. 削除した JAR ファイルについて、JSFP601 プロジェクトの WebContent/WEB-INF/lib ディレクトリーから同じ名前の JAR ファイルをコ ピーし、同じ場所のオリジナル・プロジェクトに貼り付ける。構成によっては、これらすべての JAR ファイルがプロジェクトに含まれている必要はありません。したがって、オリジナル・プロジェクト になかった特定の JAR ファイルはコピーしないでください。
        • ポートレット・プロジェクトで IBM ポート レット API または個人リンク・コンポーネントを使用している場合は、jsf-wp.jar フ ァイルをオリジナル・プロジェクトにコピーしてください。
        • odc-jsf.jar ファイルをコピーする場合は、odc-jsf-portlet.jar ファイルもコピーしてください。
      4. オリジナル・プロジェクトの web.xml デプロイメント記述子を開き、 構成に以下を追加する。
        	<context-param>
        		<param-name>com.ibm.ws.jsf.JSP_UPDATE_CHECK</param-name>
        		<param-value>true</param-value>
        	</context-param>	<context-param>
        		<param-name>com.ibm.ws.jsf.LOAD_FACES_CONFIG_AT_STARTUP</param-name>
        		<param-value>true</param-value>
        	</context-param>
        
    6. JSFP601 ポートレット・プロジェクトを削除する。

    第 6 章 WebSphere テスト環境の変更

    Rational Application Developer V6.0 では、製品に組み込まれる WebSphere Application Server テスト環境が、 WebSphere Studio Application Developer の前の エディションに組み込まれていたテスト環境から変更されました。

    以下は、Rational Application Developer V6.0 での WebSphere Application Server テスト環境の変更内容の要約です。

    以下の表は、WebSphere Studio Application Developer および Rational Application Developer の異なるバージョンに 組み込まれている WebSphere Application Server テスト環境のレベルを示したものです。

    表 2. WebSphere Studio Application Developer および Rational Application Developer の WebSphere Application Server テスト環境


    WebSphere Application Server V4.x AE WebSphere Application Server V5.x Base WebSphere Application Server Express 5.x WebSphere Application Server V5.x Portal WebSphere Application Server V6.0
    WebSphere Studio Application Developer V5.1 V4.0.6 V5.0.2 V5.0.2 N/A N/A
    WebSphere Studio Application Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419、V5.1 V5.0.2 & V5.1 N/A N/A
    WebSphere Studio Application Developer V5.1.2 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419、V5.1.0.3 V5.0.2 & V5.1.0.3 V5.0.2.3 Base + WebSphere Portal V5.0.2.1 N/A
    Rational Application Developer V6.0 N/A V5.0.x、V5.1.1 V5.0.2 & V5.1.1 V5.0.2.6 Base + WebSphere Portal V5.0.2.2、V5.1.1 Base + WebSphere Portal 5.1 V6.0

    著作権および特記事項