IBM Rational Web Developer for Windows and Linux、バージョン 6.0 マイグレーション・ガイド
第 1 章 WebSphere Studio V5.1、5.1.1、または 5.1.2 からのマイグレーション
第 2 章 Rational Web Developer V6.0 の Web プロ ジェクトに対する Faces ランタイム・リソースの更新
第 3 章 J2EE プロジェクトのマイグレーション
第 4 章 WebSphere テスト環境の変更
この文書では、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 からマイグレーションするには、
以下のようにします。
- インストールの前に、「Eclipse V2.x
および WebSphere Studio V5.1.x との互換性」について読む。
WebSphere Studio V5.1.2 の Portal Toolkit
V5.0.2.2 から
マイグレーションされたポートレット・アプリケーション・プロジェクトでは
後方互換性はサポートされていませんのでご注意ください。
- WebSphere Studio V5.1.x ワークスペースをバックアップする。
- Rational Web Developer をインストールする。 1 枚目の製品 CD
のルートにある「インストール・ガイド 」(install.html
ファイル) を 参照してください。
- 推奨: デフォルトにより、 Rational Web Developer
を初めて開始すると、 rationalsdp6.0¥workspace
という名前のワークスペースを使用することを確認する プロンプトが表示される。
つまり、「ワークスペース・ランチャー (Workspace
Launcher)」ダイアログ・ボックスが、 ユーザーの WebSphere Studio
ワークスペースではないディレクトリーを指します。古いワークスペースを
マイグレーションする前に新規環境を探索するには、デフォルトを受け入れるか、
または Rational Web Developer を開始するときに
別の新規ディレクトリー名を指定してください。これは、例えば 1 つか 2
つのテスト・プロジェクトを作成する、 新機能について読む (「ヘルプ」
-> 「ようこそ」)、 いくつかの新規チュートリアル
(「ヘルプ」 -> 「チュートリアル・ギャラリー」)
を実行する、 またはいくつかの新規サンプルを試す (「ヘルプ」
-> 「サンプル・ギャラリー」)
といった場合に行うことができます。
- V6.0 にプロジェクトをマイグレーションする。WebSphere Studio
V5.1.x で作成したプロジェクトは、以下の手順で自動的に
V6.0 にマイグレーションされます。
- ワークスペースをマイグレーションする:V5.1.x
ワークスペースを永続
的にマイグレーションする準備ができたら、古いワークスペースで Rational Web
Developer
を開始する。進行標識は、プロジェクトが自動的にマイグレーションされていることを確認します。
注: ワークスペースのマイグレーション中、「問題
」ダイアログ・ボックスが開いて
「ワークベンチのレイアウトを復元できません。理由:
ワークベンチの復元中に 問題が発生しました
」というメッセージが表示されます。このエラー・メッセージは、ワークスペースのマイグレーションの成功には何の影響もありません。
エラー・ダイアログ・ボックスの「詳細」ボタンをクリックして
復元できなかったパースペクティブの名前をメモしてから、
「OK」をクリックしてダイアログ・ボックスを閉じてください。
パースペクティブを復元するには、以下のようにします。
- 「ウィンドウ」 -> 「パースペクティブを閉じる (Close
Perspective)」 を選択してパースペクティブを閉じる。
- 「ウィンドウ」 -> 「パースペクティブを開く (Open
Perspective)」 を選択してパースペクティブを再び開く。
- 注:
- WebSphere Studio V5.1.2 で EGL Web
パースペクティブを使用したエンタープライズ開発言語 (EGL) プロジ
ェクトの場合: このパースペクティブは Rational Web Developer
V6.0 では除去されました。 Rational Web Developer V6.0
では、すべての EGL プロジ
ェクトはこのパースペクティブがなくても安全にマイグレーションされます。 EGL Web
パースペクティブを使用した場合は、以下のことを実行してください。
- EGL Web パースペクティブを閉じる。
- 「設定」 (「ウィンドウ」 -> 「設定」) で EGL
機能を使用可能にする。EGL 機能の
使用可能化について詳しくは、オンライン・ヘルプを参照してください。
- 「ウィンドウ」 ->
「パースペクティブを開く」を選択し、 Web
パースペクティブを選択する。
- SCM (ソース・コード管理)
システムからロードされたプロジェクトをマイグレ ーションする: SCM
システムに存在する WebSphere Studio 5.1.x
のプロジェクトは、 Rational Web Developer にロードされたと きに自動的に
V6.0 にマイグレーションされます。
- プロジェクト交換を使用してインポートされたプロジェクトをマイグレーション
する: WebSphere Studio V5.1.2 または
V5.1.1
からエクスポートされて、プロジェクト交換フィーチャーを使用して Rational Web
Developer V6.0 にインポート されたプロジェクトは、自動的に V6.0
にマイグレーションされます。 プロジェクト交換フィーチャーは、 WebSphere Studio
V5.1.2 で使用可能であり、 V5.1.1
ではオプションのプラグインでした。
注:
- V6.0 にマイグレーションされるそれぞれの V5.1.x
プロジェクトごとに、 マイグレーション・プログラムは自動的に
.compatibility ファイルを V6.0 の
プロジェクト・フォルダーに追加します。このファイルは、 WebSphere Studio
V5.1.x
との後方互換性の目的で使用されます。このファイルを編集または削除しないでください。
詳しくは、「WebSphere Studio V5.1.x
との互換性」のセクションを 参照してください。
重要:
- マイグレーション中のワークスペースと関連したデバッグ起動構成がある場合、
一部の起動構成が自動的にマイグレーションされませんので注意してください。マイグレーション済み
ワークスペースに起動構成を復元する方法については、 「V6.0 でのデバッガーの変更」を参照してください。
- マイグレーション済みワークスペース内のプロジェクトで XSLT デバッガーまたは
EGL デバッ ガーを使用した場合は、 Rational Web Developer V6.0
と共にインストールされる Java ランタイム環境 (JRE) を変更する必要があります。
この変更方法について詳しくは、「V6.0 でのデバッガーの変更」を 参照してください。
- V6.0
にマイグレーションされた、エンタープライズ開発言語を使用して開発された
プログラムがある場合は、バージョン 6.0 に EGL
用の新規予約語がある点に注意してください。これらの予約語を変数またはパーツ名として使用している場合は、
それを変更する必要があります。「V6.0 の EGL 予約語」を参照してください。
- DB2(R) Net JDBC ドライバーは、 Rational Web Developer V6.0
ではサポートされていません。 DB2 Net JDBC ドライバーを使用して JDBC
接続を作成した場合は、 Rational Web Developer V6.0 で再接続できません。
サポートされる JDBC ドライバーの 1
つを使用するにように接続を変更する必要があります。 V6.0
でサポートされる JDBC ドライバーについて詳しくは、オンライン・ヘルプを
参照してください。
- Web または XML ファイル・コンテンツを、Shift_JIS 文字セットを使用し、
ベンダー選択文字を組み込んだ WebSphere Studio Site Developer
V5.1.x からマイグレーションした場合は、代わりに Windows-31J
文字セットを指定する必要があります。
- WebSphere Studio Site Developer V5.1.x と共に
ベンダーのプラグインをインストールした場合は、 V6.0
用の対応するプラグインを入手して再インストールする必要があります。
- エージェント・コントローラーが必要な機能を使用している場合は、 Rational
Web Developer で提供されているバージョンを
インストールしてアップグレードしてください。
詳しくは、「インストール・ガイド 」を参照してください。
- VisualAge Generator からマイグレーションするには、 「VisualAge
Generator からエンタープライズ開発言語 (EGL)
へのマイグレーション・ガイド 」を参照してください。
この文書は、オンライン・ヘルプの「インストールとマイグレーション」セクションの
ヘルプ・トピック「VisualAge Generator から EGL
マイグレーション・ガイドへのアクセス」 の下に PDF 形式で置いてあります。
最新コピーは、 http://www.ibm.com/developerworks/rational/library/egldoc.html
から入手できます。
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
と互換となり共用することができます。
- マイグレーション・ツールによって作成された
.project ファイルと .compatiblity ファイルに
追加される互換性メタデータを変更する。
- これらのプロジェクトから
.compatibility ファイルを削除する。
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 でロードした後、 以下の手動ステップが必要です。
- .classpath ファイルを持つ J2EE プロジェクトごとに
.classpath ファイルを開く。
- .classpath
ファイルから以下のクラスパス・エントリーを削除し、ファイルを保管して閉じる。
-
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/
org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/WebSphere v5.1 JRE"/>
-
<classpathentry kind="con"
path="com.ibm.wtp.server.java.core.container/
com.ibm.etools.websphere.runtime.core.runtimeTarget.v51/was.base.v51"/>
- 必ず「J2EE
設定」ページでサーバー・ターゲット・サポートが使用可能になっていることを
確認する。「ウィンドウ」 -> 「設定」 ->
「J2EE」を選択し、 「サーバー・ターゲット・サポート」の下で
「サーバー・ターゲット・サポートを使用可能にする」が
選択されていることを確認します。
- プロジェクトを右クリックし、 「プロパティー」 ->
「J2EE」を選択する。
- プロジェクトのランタイム・ターゲットの対応するターゲット・サーバー
(例えば、JDK 1.4 ランタイム環境を使用する WebSphere Application Server
V5.1) を選択して、 「OK」をクリックする。
- 選択されたターゲット・サーバーは、 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 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 との互換性を
除去するには、以下のようにします。
- エンタープライズ・アプリケーション・プロジェクトを右クリックし、
ポップアップから「互換性の除去」メニュー・オプションを選択する。
- エンタープライズ・アプリケーション・プロジェクトとそのプロジェクトの下に
ネストされたすべてのモジュールとユーティリティー・プロジェクトの後方互換性の除去について
確認を求めるダイアログが表示される。
- 「はい」をクリックして、互換性の除去操作を継続する。
互換性の除去操作が実行されると、エンタープライズ・アプリケーション・プロジェクト
とそのエンタープライズ・アプリケーション・プロジェクトの下にネストされたすべての
モジュールとユーティリティー・プロジェクトが、 WebSphere Studio Site Developer
V5.1.x と後方互換ではなくなります。
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 ランタイム
・リソースを自動的に更新するには、以下のようにします。
- Faces コンテンツが含まれた Web プロジェクト (またはワークスペース) を
WebSphere Studio Site Developer V5.1.x からインポートする。
「プロジェクトのマイグレーション」ウィンドウが開きます。
- 注:
- 「プロジェクトのマイグレーション」ウィンドウが開かない場合は、自動ビルドの設定が
おそらく無効になっています。 プロジェクト・エクスプローラーで Web
プロジェクトを右クリックして、 「ビルド」 ->
「プロジェクト」を選択します。これにより、プロジェクトの再ビルド・プロセスが
実行されて、「プロジェクトのマイグレーション」ウィンドウが開き ます。
- Faces コンテンツが含まれた他の Web
プロジェクトがワークスペース内にある場合
は、「アップグレードの必要がある他のプロジェクトにこの選択を適用する」チェック・ボックスを選択すると、すべての
Web プロジェクトが更新される。
- 次のいずれかをクリックする。
- 更新を自動的に完了するには、「適用する」をクリックする。
- 更新を延期するには、「後で適用する」をクリックする。
「後で適用する」の選択後にランタイム・リソースを自動的に更新
するには、Web プロジェクトを再ビルドする前に、Web プロジェクトを閉じ
てから再び開くかワークベンチを再始動する必要があります。
自動ビルドを無効にしている場合は、Web プロジェクトを右クリックして
「プロジェクトのビルド」を選択します。
- ランタイム・リソースをバックレベルのままにするには、「適用しない」をクリックする。
「適用しない」を選択してバックレベルのランタイム・リソースを
意図的に保持した場合は、これらのランタイム・リソースを更新するように指示するプロンプトは再表示されません。
今後は、これらのランタイム・リソースが必要な場合は、これらを手動で更新する必要があります。
- 注:
- Faces Client コンポーネントが含まれた Faces JSP を作成した場合は、Faces
Client
コンポーネント・ランタイム・リソースを別個に最新レベルに更新する必要があります。「Web プロジェクトでの Faces Client ランタイム・リソースの更新」を参照してください。
ランタイム・リソースを手動で更新する
Web プロジェクトに対して Faces ランタイム・リソー
スを手動で更新するには、以下のようにします。
- Faces コンテンツが含まれた既存の Web プロジェクトを Rational Web Developer
V6.0.1 ワークスペースにインポー トする。
- JSF601 という名前の新しい Web プロジェクトを作成する (または
EGL で 作業をしている場合は JSF601 という名前の新しい EGL Web
プロジェクトを作成する)。
このプロジェクトは、最新ランタイム・リソースのソースとしてのみ使用し、更新の完了後には削除できます。
- プロジェクト・エクスプローラーで JSF601
プロジェクトを右クリックし、
メニューから「プロパティー」を選択する。
- 「Web プロジェクト・フィーチャー 」をクリックして、「Faces
基本コンポーネントの追加」と「Faces Client Framework
の追加」を選択し、「OK」をクリックする。
- EGL で作業をしている場合は、以下の手順で JSF
ページを作成してください。
- 新規 EGL Web プロジェクトの WebContent フォルダーを右クリックする。
- 「新規」 -> 「その他」 -> 「Faces
JSP ファイル」を選択する。
eglintdebug.jar ファイルと
eglintdebugsupport.jar ファイルが
プロジェクトに追加されます。
- 更新したい既存の Faces プロジェクトごとに以下を実行する。
- プロジェクト・エクスプローラーで既存のプロジェクトを展開して、
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
- 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>
- 削除した JAR ファイルについて、JSF601 プロジェクトの
WebContent/WEB-INF/lib ディレクトリーから同じ名前の JAR ファイルをコ
ピーし、同じ場所のオリジナル・プロジェクトに貼り付ける。構成によっては、これらすべての
JAR ファ イルがプロジェクトに含まれている必要はありません。したがって、オリジ
ナル・プロジェクトになかった特定の JAR ファイルはコピーしないでください。
- オリジナル・プロジェクトの 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>
- オリジナル・プロジェクトでデータ・アクセスのために WebSphere Data Object
(WDO) を使用していた場合は、以下の追加ステップを実行する。
- オリジナル・プロジェクトで、「ファイル」 ->
「新規」 -> 「Faces JSP ファイル」をクリック
して、新しい一時 Faces JSP ファイルを作成する。
- パレットのデータ・ドロワーからリレーショナル・レコード・リスト・コンポーネントを
ページにドラッグする。
- 任意の接続とデータ・ソースを選出して、「終了」をクリックする。
選択されるデータは重要ではありません。このプロセスによりこのプロジェクトで WDO
の使用 を継続するために必要な構成が生成されます。
- 一時 JSP ファイルを削除する。
- EGL で作業をしている場合 は、 それぞれの EGL Web
プロジェクトの名前を右クリックし、
「生成」をクリックする。その後、自動的にプロジェクトを
ビルドしているのでない場合は、「プロジェクト」 ->
「すべてビルド」をクリックします。
- JSF601 Web プロジェクトを削除する。
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 ランタイム
・リソースを自動的に更新するには以下のようにします。
- Faces Client コンテンツが含まれた Web プロジェクト (またはワークスペース)
を WebSphere Studio Site Developer V5.1.x からインポートする。
「プロジェクトのマイグレーション」ウィンドウが開きます。
- 注:
- 「プロジェクトのマイグレーション」ウィンドウが開かない場合は、自動ビルドの設定がお
そらく無効になっています。 プロジェクト・エクスプローラーで Web
プロジェクトを右クリックして、 「ビルド」 ->
「プロジェクト」を選択します。これにより、プロジェ
クトの再ビルド・プロセスが実行されて、「プロジェクトのマイグレーション」ウィンドウが開き
ます。
- Faces Client コンテンツが含まれた他の Web
プロジェクトがワークスペース内にある場合
は、「アップグレードの必要がある他のプロジェクトにこの選択
を適用する」チェック・ボックスを選択すると、すべての Web
プロジェクトが更新される。
- 次のいずれかをクリックする。
- 更新を自動的に完了するには、「適用する」をクリックする。
- 更新を延期するには、「後で適用する」をクリックする。
「後で適用する」の選択後にランタイム・リソースを自動的に更新
するには、Web プロジェクトを再ビルドする前に、Web
プロジェクトを閉じてから再び開くかワークベンチを再始動 する必要があります。
自動ビルドを無効にしている場合は、Web プロジェクトを右クリックして
「プロジェクトのビルド」を選択します。
- ランタイム・リソースをバックレベルのままにするには、「
適用しない」をクリックする。
「適用しない」を選択してバックレベルのランタ
イム・リソースを意図的に保持した場合は、これらのランタイム・リソースを更新するように指示するプロンプトは再表
示されません。
今後は、これらのランタイム・リソースが必要な場合は、これらを手動で更新する必要があります。
- Web プロジェクト内の「Java Resources」 ->
「JavaSource」フォルダーから、
com.ibm.dynwdo4jsmediators.<client-data-name>
という命名規則に従ったすべてのクライ
アント・データ・メディエーター・クラス・パッケージを削除する。
com.ibm.dynwdo4jsmediators
という名前のパッケージは削除しないでください。
このパッケージには、メディエーターを再生
成するのに使用される、プロジェクト内のクライアント・データのメタデータ (ecore
ファイルと emap ファイル) が含まれています。
- Web プロジェクト内の「Java Resources」 ->
「JavaSource」フォルダーから、
OdysseyBrowserFramework.properties
ファイルを開いて、EMAP_FILES と ECORE_FILES
のエントリーを削除する。
- 「クライアント・データ」ビュー内のデータ・オブジェクトごとに以下を実行する。
- 右クリックして「構成」を選択する。
- 「拡張」タブで、「サーバー・ サイド・データから再生成する
(Regenerate from server-side
data)」をクリックして、そのデータ・オブジェクトのすべての
メディエーターを再生成する。
ランタイム・リソースを手動で更新する
Web プロジェクトに対して Faces Client
ランタイム・リソースを手動で更新するには、以下のようにします。
- 『Web プロジェクトでの Faces ランタイム・リソースの更新』の『ランタイム・リソースを手動で更新
する』のステップを実行する。
- 上記の『ランタイム・リソースを自動的に更新する』セクショ
ンのステップ 4 から 6 を実行する。
Faces Client
コンポーネントが含まれたプロジェクトのターゲット・サーバーを WebSphere
Application Server V5.1 から V6.0 に
変更するときには問題が発生する可能性があります。
Faces Client コンポーネントが含まれたプロジェクトのタ ーゲット・サーバーを
WebSphere Application Server V5.1 から V6.0 に変更すると、次の 2
つの問題が発生する可能性があります。
- すでに生成されているクライアント・データのメディエーター・クラスがコンパイルされなくな
る。これらのメディエーター・クラスは、以下のステップに従って JSP
ごとに再生成する必要があり ます。
- ルートの Java ソース・フォルダーにある
OdysseyBrowserFramework.properties ファイルを開く。
将来の利用のために内容を保管します。
- OdysseyBrowserFramework.properties ファイルで、Web プロジェクト内の
Faces クライアン ト・データが含まれた JSP ごとに、EMAP_FILES プロパティーと
ECORE_FILES プロパティーに対する <client-data-name>.ecore
エントリーと <client-data-name>.emap エントリーを検索する。
- JSP
上のクライアント・データの一致するエントリーのみを保持し、他のすべてのエントリーを削除する。
例えば、現行ページに ACCOUNT というクライアント・データ
があり、プロパティー・ファイルに次のような項目がある場合:
EMAP_FILES=com¥¥ibm¥¥dynwdo4jsmediators/account.emap com¥¥ibm¥¥dynwdo4jsmediators/orders.emap
項目から
com¥¥ibm¥¥dynwdo4jsmediators/orders.emap
を削除します。すると、
この項目は次のように表示されます。
EMAP_FILES=com¥¥ibm¥¥dynwdo4jsmediators/account.emap
- プロパティー・ファイルを保管する。
- JSP 内のクライアント・データ・オブジェクトを選択して右クリック
し、「構成」を選択する。
- 「拡張」タブで「すべて再生成」をクリックする。
これにより、現行の JSP
上のすべてのクライアント・データに必要なすべての成果物が再生成されま す。
- Web プロジェクト内のクライアント・データが含まれた JSP ごとにステップ 2
から 6 を繰り返す。
- クライアント・データ・メディエーター・クラスを再生成した後でも、コンパイルされ
ないメディエーター・クラスがまだいくつか残ります。これらは、V6.x の
Service Data Object (SDO) で使用されなくなったスキ
ーマ・エレメントのメディエーターであり、*_DataGraphSchema_wdo4js_*.java
および *_RootDataObject_wdo4js_*.java という命名規則に従っています。
これらのコンパイル・エラーを回避するためには、Web
プロジェクトからこれらのメディエーター・クラス を削除してください。
- 更新が正常に完了した後、OdysseyBrowserFramework.properties
ファイルのオ リジナルの内容を復元します。
- プロジェクトのターゲット・サーバーを WebSphere Application Server
V6.0 に変更した後、 WDO にバインドされたツリー・ビューの Faces Client
コンポーネントをサーバー上で実行できない。 この問題の回避策は、すべての
className タグが WDO DataObject クラスではなく SDO DataObject
クラスを使用するように、JSP のソース・ビューを変更することです。
例えば、account という名前の WDO については次のようにします。
- ルート・オブジェクトについて、className タグを
className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)"
から
className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)"
に変更する。
- すべての下位ノードについて、className タグを
className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)"
から
className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)"
に変更する。 ここで、ACCOUNT はデータ・ノードの名前です。
自動化された Diff
ハンドラーおよびプロセッサーにアップグレードする
現在は Diff プロセッサーおよびハンドラーは自動生成されます。Faces Client
コンポーネントの Diff ハンドラーおよびプロセッサーを WebSphere Studio
V5.1.x
で作成した場合は、そのコードを廃棄して、次のように自動的に生成されるプロセッ
サーとハンドラーを使用することをお勧めします。
- Web プロジェクト内の各クライアント・データ・オブジェクトで新しい Diff
ハンドラーと プロセッサーを生成する。
- クライアント・データ・オブジェクトを選択して右クリックし、「構成」を選択する。
- 「拡張」タブで「すべて再生成」をクリックする。
- 生成されたプロセッサーとハンドラーは自動的に呼び出されるため、Diff
プロセッ
サーとハンドラーを呼び出すために作成したコードを除去する。このコードが使用されていた場所の
典型的な例は、次のような「コマンド・ボタン」コンポーネントの「コマンド」イベントです。
String Diff = getClientData1().getDiffStr();
if (DiffProcessor.Synch(getRoot(), Diff) == true)
return "";
return "failure";
- 作成した古いカスタム・ハンドラーおよびプロセッサーに対応するファイルを Web
プロジェクトから除去する。
V5.1.x 用に作成されたカスタム Diff
ハンドラーおよびプロセッサーを保持する
これは推奨されませんが、 V5.1.x のカスタム Diff
ハンドラーおよびプロセッサーを保持する必要があると判断した場合は、これらを
V6.0 で機能させるためには変更が必要になります。その理由は、DiffHandler
インターフェースと DiffInfo クラスが変更されているためです。
- DiffHandler インターフェースは以下のように変更されました。
- ハンドル・メソッドは DiffException に加え、Exception を throw
するようになった。
- フレームワークはオブジェクトを検索するために新しい find
メソッドを使用する。
- デバッグに新規 getId メソッドが使用され、フレームワークが
オブジェクトの値を印刷することができる。
生成された DiffHandler により find および getId
メソッドが内部で使用される。 カスタム DiffHandler
については、このインターフェースに準拠させるためだけに
空のメソッドをインプリメントすることができます。それらのメソッドは、
フレームワークによって呼び出されません。
DiffHandler インターフェースは、
以下のようになりました。
public interface DiffHandler
{
public void handle(DiffInfo Diff) throws DiffException, Exception;
public Object find (DiffInfo Diff) throws DiffException, Exception;
public String getId (DiffInfo Diff, boolean Original);
}
- DiffInfo クラスが以下のように変更されました。
- ArrayList getAncestors() メソッドは DiffInfo getParent()
メソッドに置換されました。このメソッドは再帰的方法で
祖先ツリーの各オブジェクトの情報に容易にアクセスする方法を提供します。
- getCurrent() および getOriginal() メソッドは、EObject オブジェクトではなく
DataObject オブジェクトを戻すようになりました。DataObject
オブジェクトを使用するように
コードを変更することは必須ではありません。しかし、DataObject
インターフェースの方が EObject
よりもより簡単で直感的に使用できます。既存のコードに対して、容易に DataObject
オブジェクトを EObject オブジェクトに cast することができます。
- このオブジェクトが適用されるプロパティー名を識別するために、 新規メソッド
String getPropertyName() が追加されました。これは、例えば特定のクラスに
同じ型の 2 つのプロパティーがある場合に重要です。以前の DiffInfo クラスでは、
コードは 2 つのプロパティー間を区別することができませんでした。
DiffInfo クラスは以下のように変更されました。
public class DiffInfo
{
public char getCrud()
public DataObject getCurrent()
public String getEClassName()
public DataObject getOriginal()
public String getPropertyName()
public DiffInfo getParent()
}
- 注:
- DiffInfo クラスは公用の使用ではサポートされなくなりました。 その理由は Diff
プロセッサーとハンドラーが自動的に生成されるようになったためです。古い
ハンドラーを保持するのは一時的なソリューションでしかなく、
自動化されたハンドラーを使用するよう強くお勧めします。
V6.0 での Faces Client コンポーネントの変更点
- WebSphere Application Server V6.0 のサポート。
- WebSphere Application Server V6.0 での Service Data Object (SDO)
のサポート。
- EGL データがクライアント・データとしてサポートされるようになりました。
- Diff プロセッサーとハンドラーが自動生成されます。
- 次のコンポーネントに対する新規イベントが追加されました。
- TabbedPanel: onInitialPageShow
- Tree: onNodeExpand、onNodeCollapse、onExpand、onCollapse
- DataGrid: onPage、onSort、onFilter
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
で修正するには、以下のステップに従います。
- プロジェクト・エクスプローラーで Struts Web プロジェクトを開く。
- プロジェクト・エクスプローラーでその Web プロジェクトの
Web「デプロイメント記述子」ファイルをダブルクリックする。 Web
デプロイメント記述子エディターが開きます。
- 「ソース」タブをクリックして「ソース」 ページを開く。
- 次の行を変更する。
<param-value>WEB-INF/struts-config.xml</param-value>
(この行は <servlet></servlet> タグ内に
配置されています)
変更後
<param-value>/WEB-INF/struts-config.xml</param-value>
- 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
に変換するには、以下のよ うにします。
- Struts 1.1 ベータ・プロジェクトを Rational Web Developer
V6.0 ワークスペースにロードす る。
- 例えば Struts11 という名前の新しい Struts 1.1 Web
プロジェクトを作成する。
この一時プロジェクトを作成する理由は、実際のプロジェクトを変換する際に必要となる
Struts 1.1
ランタイム・ファイルへの便宜的なアクセスを可能にするためです。
完了したらこのプロジェクトを削除できます。
- Struts 1.1 に変換したい Struts 1.1
ベータ・プロジェクトごとに以下を実行する。
- 次の JAR ファイルをプロジェクトの Web Content/WEB-INF/lib
ディレクトリーから削除する。
- 次の JAR ファイルを Struts11/WebContent/WEB-INF/lib
ディレクトリーからプロジェクト の Web Content/WEB-INF/lib
ディレクトリーにコピーする。
- struts-*.tld というタグ・ライブラリー記述子 (TLD)
ファイルをプロジェクトの Web Content/WEB-INF ディレクトリーから削除する。
- 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
に変換するには、以下のようにします。
- Struts 1.0.2 プロジェクトを Rational Web Developer
V6.0 ワークスペースにロードす る。
- 例えば Struts11 という名前の新しい Struts 1.1 Web
プロジェクトを作成する。
この一時プロジェクトを作成する理由は、実際のプロジェクトを変換する際に必要となる
Struts 1.1
ランタイム・ファイルへの便宜的なアクセスを可能にするためです。
完了したらこのプロジェクトを削除できます。
- Struts 1.1 に変換したい Struts 1.0.2
プロジェクトごとに以下を実行する。
- struts.jar ファイルをプロジェクトの Web Content/WEB-INF/lib
ディレクトリーから削除する。
- 次の JAR ファイルを Struts11/WebContent/WEB-INF/lib
ディレクトリーからプロジェクト の Web Content/WEB-INF/lib
ディレクトリーにコピーする。
- commons-*.jar
- struts.jar
- jarkarta-oro.jar
- struts-*.tld というタグ・ライブラリー記述子 (TLD)
ファイルをプロジェクトの Web Content/WEB-INF ディレクトリーから削除する。
- struts-*.tld という TLD ファイルを Struts11/WebContent/WEB-INF
ディレクトリーから プロジェクトの Web Content/WEB-INF
ディレクトリーにコピーする。
Rational Web Developer V6.0 では
デバッグ・ツールに多くの変更があります。
マイグレーション後、これらのツールをプロジェクトで使用する場合、
この変更に注意する必要があります。設定の変更または復元が必要な場合があります。
ワークスペースおよび起動構成のマイグレーション
WebSphere Studio Site Developer からの V5.1.x ワークスペース
が Rational Web Developer V6.0 で開かれたとき、
そのワークスペースと関連した以下のデバッガー起動構成は自動的にマイグレーションされません。
- サーバーでのデバッグ:「サーバーでのデバッグ」アクションによって
以前に作成された起動構成は V6.0
にはマイグレーションされません。V6.0 でサーバーでの
デバッグのためのアプリケーションを起動するには、アプリケーションを再び選択して、
「サーバーでのデバッグ (Debug on
Server)」を選択します。これにより、
そのアプリケーションの新規起動構成が作成されます。
- サーバー接続: サーバー接続のために以前に作成された
WebSphere Application Server デバッグ起動構成は、 V6.0
にはマイグレーションされません。WebSphere Application Server
デバッグ起動構成は 最早存在しません。V6.0
でのデバッグのためにサーバー接続を実行するには、
「サーバーでのデバッグ」アクションを使用して、 5.x
では「WebSphere v5 サーバー接続」を作成し、 6.0 では「WebSphere
v6.0 サーバー」を作成します。
- SQLJ デバッガー: SQLJ デバッグ起動構成は最早存在せず、
以前作成された SQLJ 起動構成は V6.0
にマイグレーションされません。V6.0 での デバッグのために SQLJ
プログラムを起動するには、 Java Application 起動構成を使用します。
- ストアード・プロシージャー・デバッガー:以前に作成された
ストアード・プロシージャー・デバッガー起動構成は、 Rational Web Developer
V6.0 にマイグレーションされ、
「デバッグ起動構成」ダイアログ・ボックスで使用することができます。
マイグレーション後、「データ定義ビュー」のポップアップ・メニューで
「デバッグ」アクションを使用すると、新規起動構成が自動的に
作成されます。
- 注:
- ストアード・プロシージャーを含むワークスペースをマイグレーションし、
デバッグのためにそのストアード・プロシージャーを再ビルドした場合、
そのストアード・プロシージャーと関連したマイグレーション済み起動構成は機能しません。
- EGL デバッガー:ワークスペースのマイグレーション後、既存の
EGL デバッガー 起動構成について以下のステップを実行する必要があります。
- インストールされている Java ランタイム環境 (JRE) が正しい
ロケーションを指すように変更する。ワークスペースのマイグレーション後、
インストールされている JRE は前のバージョンの WebSphere Studio Site Developer
からの JRE を指します。 これを変更するには、以下のようにして新規 JRE
ロケーションを指してください。
- ワークベンチのメニューから「ウィンドウ」 ->
「設定」を選択する。
- 表示された「設定」ダイアログで、 Java ノード
を展開し、「インストール済み JRE」を選択する。
- 右側で、インストール済み JRE がこの製品の現行バージョンと共に
インストールされた JRE を指すように設定する。JRE のロケーションは、 Rational
Web Developer V6.0 の インストール・ディレクトリーの
¥eclipse¥jre サブディレクトリーです。
- 起動する前に、「起動構成」で「ソース」タブを 選択する
(これを行わないと、「ソースが見つからない」というエラーが発生します)。
ソース・ロケーションを V5.1.x
ワークスペースの起動構成に追加している場合は、
これらのロケーションをマイグレーションされた起動構成に手動で追加し直す必要があります。
- コンパイル済み言語デバッガー:ワークスペースのマイグレーション後、
既存のコンパイル済み言語デバッガー起動構成について以下のステップを実行する必要があります。
- 「コンパイル済みアプリケーション」起動構成の
「システム環境」タブで環境変数を設定している場合は、
マイグレーションされた起動構成に手動でそれらを追加し直す必要があります。
- ソース・ロケーションを「コンパイル済みアプリケーション」
または「実行プロセスへの接続」起動構成に追加している場合は、
マイグレーションされた起動構成に手動でそれらを追加し直す必要があります。
デバッグ・ビュー
ストレージ・ビューとストレージ・マッピング・ビュー
は最早存在しません。それらのビューは、メモリー・ビューとメモリー・レンダリング・ビューに置換されました。
XSLT デバッガー
XSLT デバッガー は V6.0
で変更され、そのビューとアクションの多くでかなりの変更がありました。
詳しくは、インフォメーション・センターにある XSLT
デバッガー文書を参照してください。
XSLT デバッガーの最も大きな変更の 1 つは、 Rational Web Developer
V6.0 と共にインストールされる JRE に対する依存です。 WebSphere Studio
Site Developer V5.1.x から
ワークスペースをマイグレーションした場合、 そのワークスペースに対する XSLT
デバッグ・セッションを起動する前に、 インストール済み JRE
が正しいロケーションを指すように変更する必要があります。
このためには、次のいずれかのアクションを実行することができます。
- 以下のステップを実行して新規 JRE ロケーションを指すようにすることで、
ワークスペース全体の JRE を変更します。
- ワークベンチのメニューから「ウィンドウ」 ->
「設定」を選択する。
- 「設定」ウィンドウで、Java
ノードを展開し、「インストール済み JRE」を選択する。
- 右側で、インストール済み JRE がこの製品の現行バージョンと共に
インストールされた JRE を指すように設定する。JRE のロケーションは、 Rational
Web Developer V6.0 の インストール・ディレクトリーの
¥eclipse¥jre サブディレクトリーです。
- 「デバッグ起動構成」ダイアログ・ボックスからデバッグ・セッションを
起動する予定の場合は、新規 JRE ロケーションを指すようにすることで、 起動構成の
JRE を変更することができます。このためには、
「デバッグ起動構成」ダイアログ・ボックスで起動構成を開きます。「JRE」タブを選択し、
「代替 JRE」フィールドに新規 JRE ロケーションを指定します。
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 マイグレーション・ウィザードを使用した J2EE マイグレーション中に、
別のサーバーを使用するようにアプリケーションのターゲットを再設定することができます。
- 注:
- マイグレーションは、上位の J2EE 仕様レベルにしかできません。
ターゲット・サーバーの変更方法および J2EE
マイグレーション・ウィザードの使用方法 のヘルプ・トピックは、Rational Web
Developer のオンライン・ヘルプにあります。
互換性の考慮事項
- WDO アクセス Bean の公用アプリケーション・プログラミング・インターフェース
(API) に 書き込まれたコードはすべて V6.0 でサポートされます (ただし、
インプリメンテーション・クラスは SDO
ランタイムをターゲットとするように変更されています)。
- WebSphere Application Server V6.0 で生成された 新規コードは WDO
アクセス Bean を使用せず、代わりに純粋な SDO API 用のコードを生成します。
- V6.0
をターゲットにしている間にプロジェクトに対して生成されたコードは、 再び
V5.1
サーバーをターゲットにしてマイグレーションし直しても、そのサーバーでは稼働しません。
- V5.1 用に作成されたコードは、 ターゲットを V5.1
サーバーにすることにより、上位にマイグレーションしたり
後方にマイグレーションすることができます。
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
これらの型の衝突エラーは、以下のようにして訂正できます。
- 衝突する import 文を Java
ソース・ファイルから除去する。前述の例を使用して、 次の import
文をソース・ファイルから除去する。
import com.ibm.websphere.wdo.mediator.exception.MediatorException;
- その型を参照して完全修飾クラス名を使用する Java
ソース・ファイルを変更する。前述の例を基に、 型 MediatorException
を
com.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 に
変更されると、自動的に以下の変更が行われます。
- Java アーカイブ (JAR) ファイル wdo_web.jar および
wdo_jdbc_access.jar are がプロジェクトから除去されます。
- 以下の JAR ファイルがプロジェクトのクラスパスから除去されます。
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- sdo_web.jar ファイルと sdo_access_beans.jar ファイルが
プロジェクトに追加されます (SDO ランタイム JAR ファイルは自動的に V6.0
プロジェクトのクラスパスに追加されます)。
- JavaServer Pages Standard Tag Library (JSTL) 1.0 JAR ファイルが
プロジェクトから除去されます。(JSTL 1.1/JSP 2.0 JAR
ファイルは自動的に V6.0 プロジェクトのクラスパスに 追加されます)。
- 以下の import 文が、Java ソース・ファイル で変更されます。
- com.ibm.websphere.wdo.access.connections.ConnectionManager
は
com.ibm.websphere.sdo.access.connections.ConnectionManager
に変更されます。
- com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper
は
com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper
に変更されます。
サーバー・ターゲットを V6.0 から V5.1 (SDO から WDO)
に変更した後の Web プロジェクトへの変更
ターゲット・サーバー が V6.0 から V5.1
に変更されると、自動的に以下の変更が行われます。
- JAR ファイル sdo_web.jar と sdo_access_beans.jar が
プロジェクトから除去されます。
- JAR ファイル wdo_web.jar と wdo_jdbc_access.jar が
プロジェクトに追加されます。
- 以下の JAR ファイルがプロジェクトのクラスパスに追加されます。
- emf-runtime.jar
- emf-event.jar
- wdo-interface.jar
- wdo.jar
- jdbcmediator.jar
- wdo.xmlmediator.jar
- JSTL 1.0 JAR ファイルがプロジェクトに追加されます (JSTL
1.1/JSP 2.0 JAR が プロジェクトのクラスパスから除去されます)。
- 以下の import 文が Java ソース・ファイルで 変更されます。
- com.ibm.websphere.sdo.access.connections.ConnectionManager
は
com.ibm.websphere.wdo.access.connections.ConnectionManager
になります。
- com.ibm.websphere.sdo.mediator.jdbc.ConnectionWrapper
は
com.ibm.websphere.wdo.mediator.rdb.ConnectionWrapper
になります。
アプリケーションの 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
|
Rational Web Developer には、 エンタープライズ開発言語 (EGL)
の新規予約語があります。
以下に新規予約語をリストします。
- as
- isa
- like
- matches
- money
- openUI
- ref
- self
- string
- this
V6.0 ワークスペースにインポートされてビルドされ、
これらの予約語を変数またはパーツ名として使用する WebSphere Studio
V5.1.x からの EGL プログラムには、
次のメッセージのタグが付きます:IWN.SYN.2002.e
39/2 Syntax error on input "variableName" ("variableName"
の入力で構文エラー)。この問題は変数名を変更することで訂正できます。
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
ランタイム・リソースを自動的に更新するには、以下のようにします。
- Faces または Faces Client コンテンツが含まれた Web プロジェクト
(またはワークスペー ス) を Rational Web Developer V6.0
からインポートする。
「プロジェクトのマイグレーション」ウィンドウが開きます。
- 注:
- 「プロジェクトのマイグレーション」ウィンドウが開かな
い場合は、自動ビルドの設定がおそらく無効になっています。
プロジェクト・エクスプローラーで Web プロジェクトを右クリックして、
「ビルド」 ->
「プロジェクト」を選択します。これにより、プロジェクトの再ビルド・プロセスが
実行されて、「プロジェクトのマイグレーション」ウィンドウが開き ます。
- Faces または Faces Client コンテンツが含まれた他の Web
プロジェクトがワークスペース
内にある場合は、「アップグレードの必要がある他のプロジェクトにこの選択を適用す
る」チェック・ボックスを選択すると、すべての Web
プロジェクトが更新される。
- 次のいずれかをクリックする。
- 更新を自動的に完了するには、「適用する」をクリックする。
- 更新を延期するには、「後で適用する」をクリックする。
「後で適用する」の選択後にランタイム・リソースを自動的に更新
するには、Web プロジェクトを再ビルドする前に、Web プロジェクトを閉じ
てから再び開くかワークベンチを再始動する必要があります。
自動ビルドを無効にしている場合は、Web
プロジェクトを右クリックして「プロジェクトのビルド」を選択します。
- ランタイム・リソースをバックレベルのままにするには、「適用しない」をクリックする。
「適用しない」を選択してバックレベルのランタ
イム・リソースを意図的に保持した場合は、これらのランタイム・リソース
を更新するように指示するプロンプトは再表示されません。
今後は、これらのランタイム・リソースが必要な場合は、これらを手動で更新する必要があります。
ランタイム・リソースを手動で更新する
Web プロジェクトに対して Faces および Faces Client
ランタイム・リソースを手動で更新するには、以下のようにします。
- JSF601 という名前の新しい Web プロジェクトを作成する (または
EGL で 作業をしている場合は JSF601 という名前の新しい EGL Web
プロジェクトを作成する)。このプロジェクトは、最新ラン
タイム・リソースのソースとしてのみ使用し、更新の完了後には削除できます。
- プロジェクト・エクスプローラーで JSF601 プロジ
ェクトを右クリックし、メニューから「プロパティー」を選択する。
- 「Web プロジェクト・フィーチャー」をクリックして、「Faces
基本コンポーネントの追加」と「Faces Client Framework
の追加」を選択し、「OK」をクリックする。
- EGL で作業をしている場合は、以下の手順で JSF
ページを作成してください。
- 新規 EGL Web プロジェクトの WebContent フォルダーを右クリックする。
- 「新規」 -> 「その他」 -> 「Faces
JSP ファイル」を選択する。
eglintdebug.jar ファイルと
eglintdebugsupport.jar ファイルが
プロジェクトに追加されます。
- 更新したい既存の Faces プロジェクトごとに以下を実行する。
- プロジェクト・エクスプローラーで既存のプロジェクトを展開して、
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
- 削除した JAR ファイルについて、JSF601 プロジェクトの
WebContent/WEB-INF/lib ディレクトリーから同じ名前の JAR ファイルをコ
ピーし、同じ場所のオリジナル・プロジェクトに貼り付ける。構成によっては、これらすべての
JAR ファ イルがプロジェクトに含まれている必要はありません。したがって、オリ
ジナル・プロジェクトになかった特定の JAR ファイルはコピーしないでくだ さい。
- EGL で作業をしている場合 は、 それぞれの EGL Web
プロジェクトの名前を右クリックし、
「生成」をクリックする。その後、自動的にプロジェクトを
ビルドしているのでない場合は、「プロジェクト」 ->
「すべてビルド」をクリックします。
- JSF601 Web プロジェクトを削除する。
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 マイグレーション・ウィザードにアクセスできます。
- J2EE パースペクティブの「J2EE 階層」ビューで、
マイグレーションしたいエンタープライズ・アプリケーション・プロジェクトを
右マウス・ボタンでクリックする。
- ポップアップ・メニューから 「マイグレーション」 ->
「J2EE マイグレーション・ウィザード」の順に選択する。
- J2EE マイグレーション・ウィザードの「ようこそ」ページの指示に従って、
マイグレーション・プロセスを進める。
注:
- セキュア Web サービス (J2EE 1.3 から 1.4)
のマイグレーションには、
セキュア・バインディングおよび拡張ファイルの手動のマイグレーションが必要です。詳しくは、
「セキュア Web サービスのマイグレーション」を参照してください。
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 サービスが J2EE 1.3 から J2EE
1.4 にマイグレーションされるときに J2EE マイグレーション・ウィザード
によってマイグレーションが行われません。セキュア Web
サービスのマイグレーションには 手動ステップが必要です。
J2EE のマイグレーション後に、以下の手順でセキュア・バインディングと
拡張ファイルを手動で J2EE 1.4 にマイグレーションする必要があります。
- webservices.xml ファイルをダブルクリックして Web
サービス・エディターを開く。
- 「バインディング構成」タブを選択して、
バインディング・ファイルを編集する。
- 「要求コンシューマー・バインディング構成の詳細」
および「応答生成プログラム・バインディング構成の詳細」という新規セクションの下に
必要なバインディング構成をすべて追加する。
- 「拡張」タブを選択して拡張ファイルを編集する。
- 「要求コンシューマー・サービス構成の詳細」および
「応答生成プログラム・サービス構成の詳細」という新規セクションの下に
必要な拡張構成をすべて追加する。
- 保管してエディターを終了する。
J2EE プロジェクトは J2EE 1.3 から J2EE 1.4 仕様レベルに
マイグレーションすることができます。このセクションでは、J2EE
プロジェクトの各タイプごとに、 J2EE マイグレーション・ウィザードにより J2EE
1.3 から J2EE 1.4 に
マイグレーションされる成果物について説明します。
Web デプロイメント記述子の成果物は、 J2EE 1.3 レベル Web
プロジェクトが J2EE 1.4 にマイグレーションされるときに J2EE
マイグレーション・ウィザードによってマイグレーションされます。
以下の Web アプリケーション成果物がマイグレーションされます。
認証制約
J2EE 1.4 には、language と value という 2
つの属性を持つ Description オブジェクトが組み込まれています。 この Description
オブジェクトは J2EE 1.3 にはありませんでした。 description
は認証制約の属性でした。したがって、Web デプロイメント記述子の成果物が J2EE
1.4 にマイグレーションされると、Description オブジェクトの
value は認証制約の description 属性から取られます。
セキュリティー制約
同様に、J2EE 1.3 では description
はセキュリティー制約の属性でした。J2EE 1.4 では、 language
と value という属性を持つ 新規 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 オブジェクトに属していました。
J2EE マイグレーション・ウィザードは、J2EE Connector Architecture (JCA)
1.0 記述子 の成果物を JCA 1.5
にマイグレーションします。マイグレーションされた成果物は、
OutboundResourceAdaptor と ConnectionDefinition という 2
つの新規オブジェクトとして、ResourceAdaptor オブジェクトのエレメントに
関連付けられます。これらはコネクター・プロジェクトの J2EE 1.4
仕様レベルの ResourceAdaptor オブジェクトに追加されました。
以下はマイグレーション済みエレメントのマッピングについての説明です。
- 以下のエレメントは、ResourceAdaptor オブジェクトから
OutboundResourceAdaptor オブジェクトに移動されます。
- reauthenticationSupport
- transactionSupport
- 以下のエレメントは、ResourceAdaptor オブジェクトから ConnectionDefinition
オブジェクトに移動されます。
- managedConnectionFactoryClass
- connectionFactoryInterface
- connectionFactoryImplClass
- connectionInterface
- connectionImplClass
- outboundResourceAdaptor オブジェクトには、ConnectionDefinition
定義のリストが含まれています。以降、ConnectionDefinition は、
OutboundResourceAdaptor によって保持されている ConnectionDefinition
リストに追加されます。
- OutboundResourceAdaptor オブジェクトは、 ResourceAdaptor
オブジェクトに含まれます。
- AuthenticationMechanism オブジェクトは JCA 1.5
でいくつかの変更がありました。customAuthMechType エレメントが
authenticationMechanism に置換され、 authenticationType エレメントが
authenticationMechanism に置換されました。
- ResourceAdaptor オブジェクトの description 属性は Description
オブジェクトに置換され、 そこで description
属性ストリングが以下のオブジェクトの Description オブジェクトの
値エレメントに設定されます。
- SecurityPermission
- AuthenticationMechanism
- ConfigurationProperties
J2EE 1.4 仕様では、新規 JAX-RPC 1.0 API を介した Web
サービスへのサポートが追加されました。
JAX-RPC API は以下を通じてサービス・エンドポイントをサポートします。
- JAXR-RPC のサーブレット
- 直接 SOAP を持つサーブレット
- ステートレス・セッション Bean
J2EE 1.4 仕様は、J2EE 仕様 (JSR 109) に対する Web サービスを
サポートします。JSR 109 は Web サービスのデプロイメント要件を定義して、
JAX-RPC プログラミング・モデルを使用します。
以下の Web サービス成果物が J2EE
マイグレーション・ウィザードを使用してマイグレーションされます。
- Web サービス記述子
- Web サービス・クライアント記述子
- JAX-RPC マッピング記述子
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 サービス・デプロイメント記述子の
マイグレーションについてさらに詳しく説明します。
- Web サービス記述子 (webservices.xml)
webservices.xml デプロイメント記述子 は、J2EE Web サービスを含む Web
プロジェクトにあります。<wsdl-port> エレメントと
<soap-header> エレメント
の両方に修飾名が含まれており、そのコンテンツが J2EE 1.4 フォーマットに
マイグレーションされます。
たとえば、<wsdl-port> がマイグレーション
前、次のように表記されている場合、
<wsdl-port>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBook</localpart>
</wsdl-port>
マイグレーション後は、<wsdl-port> は
次のように表されます。
<wsdl-port xmlns:pfx="http://addressbook.webservice">pfx:AddressBook</wsdl-port>
接頭部 "pfx"
は、マイグレーションされるすべての修飾名のネームスペース接頭部として使用されます。
- Web サービス・クライアント記述子 (webservicesclient.xml)
webservicesclient.xml デプロイメント記述子は J2EE Web
サービス・クライアントを含む J2EE 1.3 Web
プロジェクト、およびアプリケーション・クライアント・プロジェクト
にあります。J2EE 1.3 から 1.4
へのマイグレーション中、webservicesclient.xml の
コンテンツはマイグレーションされ、プロジェクトのデプロイメント記述子に
移動されます。次のようなプロセスが発生します。
- Web プロジェクトの場合、webserivcesclient.xml のすべての
<service-ref> エレメントが web.xml の
<web-app> エレメントの下に移動される。
- アプリケーション・クライアント・プロジェクトの場合、
webservicesclient.xml 内のすべての <service-ref>
エレメント が、application-client.xml 内の
<application-client> エレメントの下に移動される。
- Webservicesclient.xml が削除される。
<service-qname> エレメントと
<soap-header> エレメントの両方に修飾名が含まれ、
そのコンテンツが J2EE 1.4
フォーマットにマイグレーションされます。たとえば、<service-qname>
がマイグレーション
前に次のように表記されている場合、
<service-qname>
<namespaceURI>http://addressbook.webservice</namespaceURI>
<localpart>AddressBookService</localpart>
</service-qname>
マイグレーション後は、<service-qname> は
次のように表されます。
<service-qname xmlns:pfx="http://addressbook.webservice">pfx:AddressBookService</service-qname>
接頭部 "pfx"
は、マイグレーションされるすべての修飾名のネームスペース接頭部として使用されます。
- JAX-RPC マッピング記述子
webservices.xml と webservicesclient.xml
デプロイメント記述子の 両方が 1 つ以上の JAX-RPC
マッピング・デプロイメント記述子を参照することができます。
webservices.xml ファイルでは、これらの参照はそれぞれの
<webservice-description> エレメントの下の
<jaxrpc-mapping-file> エレメントに含まれています。
webservicesclient.xml ファイルでは、これらの参照はそれぞれの
<service-ref> エレメントの下の
<jaxrpc-mapping-file> エレメントに含まれています。
J2EE 1.3 から 1.4 への
マイグレーション中、webservices.xml および webservicesclient.xml
で 参照されているすべての JAX-RPC マッピング・デプロイメント記述子が
マイグレーションされます。マイグレーションにはすべての修飾名を J2EE 1.4
フォーマットに マイグレーションすることが含まれます
(マイグレーション後の修飾名の例については、 前述の webservices.xmlと
webservicesclient.xml の セクションを参照してください)。
J2EE モジュールは J2EE 1.2 仕様レベルから J2EE 1.4 に
マイグレーションすることができます。このセクションでは、J2EE プロジェクトで
J2EE マイグレーション・ウィザードにより J2EE 1.2 から J2EE 1.4
仕様レベルに マイグレーションされる成果物について説明します。
J2EE マイグレーション・ウィザードの使用法について詳しくは、 「第 3 章, J2EE プロジェクトのマイグレーション」を参照してください。
Web デプロイメント記述子の成果物は、J2EE 1.2 Web プロジェクトを J2EE
1.4 仕様レベルにマイグレーションするときに、J2EE
マイグレーション・ウィザード によってマイグレーションされます。
以下の Web アプリケーション成果物がマイグレーションされます。
認証制約
J2EE 1.4 には、language と value という 2
つの属性を持つ Description オブジェクトが組み込まれています。 この Description
オブジェクトは J2EE 1.2 にはありませんでした。 description
は認証制約の属性でした。したがって、Web デプロイメント記述子の成果物が J2EE
1.4 にマイグレーションされると、Description オブジェクトの
value は認証制約の description 属性から取られます。
セキュリティー制約
同様に、J2EE 1.2 では description
はセキュリティー制約の属性でした。J2EE 1.4 では、 language
と value という属性を持つ 新規 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
マイグレーション・ウィザードに対して、すべての 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
マイグレーション・ウィザードの使用法について詳しくは、
オンライン・ヘルプを参照してください。
Rational Web Developer V6.0 では、製品に組み込まれる WebSphere
Application Server テスト環境が、 WebSphere Studio Site Developer の前の
エディションに組み込まれていたテスト環境から変更されました。
以下は、Rational Web Developer V6.0 での WebSphere Application
Server テスト環境の変更内容の要約です。
- WebSphere Application Server V4.x
サーバーはテスト環境ではサポートされなくなりました。ただし、 J2EE 1.2
仕様レベルのアプリケーションは、まだリモート V4.x サーバーでの
テストのために手動でエクスポートしてデプロイすることができます。
- WebSphere Application Server V6.0
サーバーがインストール可能なテスト環境として追加されました。これは実行中の
J2EE 1.4 仕様レベルのアプリケーションをサポートします。
以下の表は、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
|
著作権および特記事項