IBM Rational Web 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 Web Developer V6.0 の Web プロ ジェクトに対する Faces ランタイム・リソースの更新

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

  • セキュア Web サービスのマイグレーション
  • J2EE 1.3 から 1.4 仕様レベルへのマイグレーション
  • Web プロジェクト (サーブレット・レベル 2.3 からサーブレット・レベル 2.4)
  • コネクター・プロジェクト (JCA 1.0 から JCA 1.5)
  • Web サービス (J2EE 1.3 から J2EE 1.4)
  • J2EE 1.2 から 1.4 仕様レベルへのマイグレーション
  • Web プロジェクト (サーブレット・レベル 2.2 からサーブレット・レベル 2.4)
  • Rational Web Developer V6.0 での J2EE マイグレーション・ウィザードの変更
  • 第 4 章 WebSphere テスト環境の変更



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

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

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

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

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

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

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

      注:

      重要:

    6. DB2(R) Net JDBC ドライバーは、 Rational Web Developer V6.0 ではサポートされていません。 DB2 Net JDBC ドライバーを使用して JDBC 接続を作成した場合は、 Rational Web Developer V6.0 で再接続できません。 サポートされる JDBC ドライバーの 1 つを使用するにように接続を変更する必要があります。 V6.0 でサポートされる JDBC ドライバーについて詳しくは、オンライン・ヘルプを 参照してください。
    7. Web または XML ファイル・コンテンツを、Shift_JIS 文字セットを使用し、 ベンダー選択文字を組み込んだ WebSphere Studio Site Developer V5.1.x からマイグレーションした場合は、代わりに Windows-31J 文字セットを指定する必要があります。
    8. WebSphere Studio Site Developer V5.1.x と共に ベンダーのプラグインをインストールした場合は、 V6.0 用の対応するプラグインを入手して再インストールする必要があります。
    9. エージェント・コントローラーが必要な機能を使用している場合は、 Rational Web Developer で提供されているバージョンを インストールしてアップグレードしてください。 詳しくは、「インストール・ガイド 」を参照してください。
    10. 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 Web Developer で開くと、 そのワークスペースは自動的にマイグレーションされます。ワークスペースをマイグレーションした後は、 WebSphere Studio Site Developer でそのワークスペースを開くことはできなくなります。 ただし、V6.0 ワークスペースのプロジェクトは、ソース・コード管理 (SCM) システム (例、Rational ClearCase(R)) を使用したり、プロジェクト交換を使ってプロジェクトをインポートおよびエクスポートしたり、 アーカイブのインポートとプロジェクトのエクスポートを通じて、引き続き WebSphere Studio V5.1.x と共用することができます。重要: Rational Web Developer V6.0 の Portal Tools にマイグレーションされる Portal Toolkit V5.0.2.2 の ポートレット・アプリケーシ ョンは後方互換にはなりません。

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

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

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

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

    Eclipse の考慮事項

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

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

    J2EE プロジェクトの互換性

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

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

    この互換性メタデータが あるかぎり、Rational Web 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 Web Developer V6.0 と WebSphere Studio Site Developer V5.1.x の両方で互換となる。 SCM システムに変更がコミットされた後は、J2EE プロジェクトは SCM システムを使用して V5.1.x と V6.0 の間で相互操作可能となります。
      注:
      ターゲット・サーバーが再び Rational Web Developer V6.0 に設定されると、 J2EE プロジェクトの互換性は失われて、再確立が必要になります。

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

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

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

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

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


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

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

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

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

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

    1. Faces コンテンツが含まれた Web プロジェクト (またはワークスペース) を WebSphere Studio Site 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 Web 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 Site Developer V5.1.x に元々付属 していた JavaServer Faces Client ランタイム・リソースは、 Rational Web Developer V6.0.1 用に更新されました。 この旧製品バージョンで作成された Web プロジェクトでの開発を継続したい場合は、 Faces Client ランタイム・リソースを最新レベルに更新することをお勧めします。

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

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

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

    1. Faces Client コンテンツが含まれた Web プロジェクト (またはワークスペース) を WebSphere Studio Site 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 Web 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 Web 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 Web 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 Web Developer V6.0 では デバッグ・ツールに多くの変更があります。 マイグレーション後、これらのツールをプロジェクトで使用する場合、 この変更に注意する必要があります。設定の変更または復元が必要な場合があります。

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

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

    デバッグ・ビュー

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

    XSLT デバッガー

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

    XSLT デバッガーの最も大きな変更の 1 つは、 Rational Web Developer V6.0 と共にインストールされる JRE に対する依存です。 WebSphere Studio Site 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 Web 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 Web Developer には、 エンタープライズ開発言語 (EGL) の新規予約語があります。

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

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


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

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

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

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

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

    1. Faces または Faces Client コンテンツが含まれた Web プロジェクト (またはワークスペー ス) を Rational Web 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 章 J2EE プロジェクトのマイグレーション

    J2EE マイグレーション・ウィザードは、 Rational Web 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 Web 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 に マイグレーションされる成果物について説明します。

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

    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 Web Developer V6.0 での J2EE マイグレーション・ウィザードの変更

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

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

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

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

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

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


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

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

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

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

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


    WebSphere Application Server V4.x AE WebSphere Application Server V5.x Base WebSphere Application Server Express V5.x WebSphere Application Server V6.0
    WebSphere Studio Site Developer V5.1 V4.0.6 V5.0.2 V5.0.2 N/A
    WebSphere Studio Site Developer V5.1.1 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419、V5.1 V5.0.2 & V5.1 N/A
    WebSphere Studio Site Developer V5.1.2 V4.0.7 + PQ78374 V5.0.2 + PQ78374 +PQ78419、V5.1.0.3 V5.0.2 & V5.1.0.3 N/A
    Rational Web Developer V6.0 N/A V5.0.x、V5.1.1 V5.0.2 & V5.1.1 V6.0

    著作権および特記事項