第 1 章 WebSphere Studio V5.1、5.1.1、または 5.1.2 からのマイグレーション
第 2 章 Rational Application Developer V6.0 の Web プロ ジェクトに対する Faces ランタイム・リソースの更新
第 5 章 Rational Application Developer V6.0 での Portal Tools のマイグレーション
この文書では、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 からマイグレーションするには、 以下のようにします。
注: ワークスペースのマイグレーション中、「問題 」ダイアログ・ボックスが開いて 「ワークベンチのレイアウトを復元できません。理由: ワークベンチの復元中に 問題が発生しました 」というメッセージが表示されます。このエラー・メッセージは、ワークスペースのマイグレーションの成功には何の影響もありません。 エラー・ダイアログ・ボックスの「詳細」ボタンをクリックして 復元できなかったパースペクティブの名前をメモしてから、 「OK」をクリックしてダイアログ・ボックスを閉じてください。
パースペクティブを復元するには、以下のようにします。
注:
重要:
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 ファイルに自動的に追加されます。 この情報を直接編集または削除しないでください。
この互換性メタデータが あるかぎり、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 でロードした後、 以下の手動ステップが必要です。
<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"/>
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 で 編集することができます。
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 との互換性を 除去するには、以下のようにします。
互換性の除去操作が実行されると、エンタープライズ・アプリケーション・プロジェクト とそのエンタープライズ・アプリケーション・プロジェクトの下にネストされたすべての モジュールとユーティリティー・プロジェクトが、 WebSphere Studio Application Developer V5.1.x と後方互換ではなくなります。
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 ランタイム ・リソースを自動的に更新するには、以下のようにします。
ランタイム・リソースを手動で更新する
Web プロジェクトに対して Faces ランタイム・リソー スを手動で更新するには、以下のようにします。
<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>
<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 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 ランタイム ・リソースを自動的に更新するには以下のようにします。
ランタイム・リソースを手動で更新する
Web プロジェクトに対して Faces Client ランタイム・リソースを手動で更新するには、以下のようにします。
Faces Client コンポーネントが含まれたプロジェクトのターゲット・サーバーを WebSphere Application Server V5.1 から V6.0 に 変更するときには問題が発生する可能性があります。
Faces Client コンポーネントが含まれたプロジェクトのタ ーゲット・サーバーを WebSphere Application Server V5.1 から V6.0 に変更すると、次の 2 つの問題が発生する可能性があります。
例えば、現行ページに 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
自動化された Diff ハンドラーおよびプロセッサーにアップグレードする
現在は Diff プロセッサーおよびハンドラーは自動生成されます。Faces Client コンポーネントの Diff ハンドラーおよびプロセッサーを WebSphere Studio V5.1.x で作成した場合は、そのコードを廃棄して、次のように自動的に生成されるプロセッ サーとハンドラーを使用することをお勧めします。
String Diff = getClientData1().getDiffStr(); if (DiffProcessor.Synch(getRoot(), Diff) == true) return ""; return "failure";
V5.1.x 用に作成されたカスタム Diff ハンドラーおよびプロセッサーを保持する
これは推奨されませんが、 V5.1.x のカスタム Diff ハンドラーおよびプロセッサーを保持する必要があると判断した場合は、これらを V6.0 で機能させるためには変更が必要になります。その理由は、DiffHandler インターフェースと DiffInfo クラスが変更されているためです。
生成された 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 クラスは以下のように変更されました。
public class DiffInfo { public char getCrud() public DataObject getCurrent() public String getEClassName() public DataObject getOriginal() public String getPropertyName() public DiffInfo getParent() }
V6.0 での Faces Client コンポーネントの変更点
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 例外が発生する可能性があります。
WebSphere Studio v5.1.x で作成された Struts Web プロジェクトの デプロイメント記述子を V6.0 で修正するには、以下のステップに従います。
<param-value>WEB-INF/struts-config.xml</param-value> (この行は <servlet></servlet> タグ内に 配置されています)
変更後
<param-value>/WEB-INF/struts-config.xml</param-value>
これにより、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.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 に変換するには、以下のようにします。
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 が正しいロケーションを指すように変更する必要があります。 このためには、次のいずれかのアクションを実行することができます。
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
これらの型の衝突エラーは、以下のようにして訂正できます。
import 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 に 変更されると、自動的に以下の変更が行われます。
サーバー・ターゲットを 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 |
Rational Application Developer には、 エンタープライズ開発言語 (EGL) の新規予約語があります。
以下に新規予約語をリストします。
V6.0 ワークスペースにインポートされてビルドされ、 これらの予約語を変数またはパーツ名として使用する WebSphere Studio V5.1.x からの EGL プログラムには、 次のメッセージのタグが付きます:IWN.SYN.2002.e 39/2 Syntax error on input "variableName" ("variableName" の入力で構文エラー)。この問題は変数名を変更することで訂正できます。
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 ランタイム・リソースを自動的に更新するには、以下のようにします。
ランタイム・リソースを手動で更新する
Web プロジェクトに対して Faces および Faces Client ランタイム・リソースを手動で更新するには、以下のようにします。
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 ランタイム・リソースを自動的に更新するには、以下のようにします。
ランタイム・リソースを手動で更新する
ポートレット・プロジェクトに対して Faces および Faces Client ランタイム・リソースを手動で更新するには、以下のようにします。
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 マイグレーション・ウィザードの使用方法について詳しくは、 オンライン・ヘルプを参照してください。ウィザードの変更については、 「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 サービスが J2EE 1.3 から J2EE 1.4 にマイグレーションされるときに J2EE マイグレーション・ウィザード によってマイグレーションが行われません。セキュア Web サービスのマイグレーションには 手動ステップが必要です。
J2EE のマイグレーション後に、以下の手順でセキュア・バインディングと 拡張ファイルを手動で J2EE 1.4 にマイグレーションする必要があります。
J2EE プロジェクトは J2EE 1.3 から J2EE 1.4 仕様レベルに マイグレーションすることができます。このセクションでは、J2EE プロジェクトの各タイプごとに、 J2EE マイグレーション・ウィザードにより J2EE 1.3 から J2EE 1.4 に マイグレーションされる成果物について説明します。
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 メッセージ駆動型 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>
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 のデプ ロイメント記述子を変更する方法を説明します。
このメッセージ駆動型 Bean をデプ ロイするのに使用される J2C 活動化仕様の JNDI 名を入力します。 この名前は、 WebSphere Application Server に対して定義する J2C 活動化仕様の名前と一致する必要があります。
JCA リソース・アダプターへの接続を 認証するために使用される J2C 認証別名の名前です。 J2C 認証別名により、JCA リソース・アダプターへの新しい接続の作成を認証するのに使用される ユーザー ID とパスワードが指定されます。
メッセージ駆動型 Bean が JNDI 名前空間で JMS 宛先を検索するのに使用する JNDI 名を入力します。
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 オブジェクトに追加されました。
以下はマイグレーション済みエレメントのマッピングについての説明です。
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 サービス・デプロイメント記述子の マイグレーションについてさらに詳しく説明します。
webservices.xml デプロイメント記述子 は、J2EE Web サービスを含む Web プロジェクトと EJB プロジェクトにあります。<wsdl-port> エレメントと <soap-header> エレメント の両方に修飾名が含まれており、そのコンテンツが J2EE 1.4 フォーマットに マイグレーションされます。
たとえば、<wsdl-port> がマイグレーション 前、次のように表記されている場合、
<wsdl-port> <namespaceURI>http://addressbook.webservice</namespaceURI> <localpart>AddressBook</localpart> </wsdl-port>
マイグレーション後は、<wsdl-port> は 次のように表されます。
<wsdl-port xmlns:pfx="http://addressbook.webservice">pfx:AddressBook</wsdl-port>
接頭部 "pfx" は、マイグレーションされるすべての修飾名のネームスペース接頭部として使用されます。
webservicesclient.xml デプロイメント記述子は、 J2EE Web サービス・クライアントを含む J2EE 1.3 Web プロジェクト、EJB プロジェクト、およびアプリケーション・クライアント・プロジェクト にあります。J2EE 1.3 から 1.4 へのマイグレーション中、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" は、マイグレーションされるすべての修飾名のネームスペース接頭部として使用されます。
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 マイグレーション・ウィザードの使用法について詳しくは、 「第 4 章, J2EE プロジェクトのマイグレーション」を参照してください。
このセクションでは、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 仕様レベルにマイグレーションするには、以下のステップが必要です。
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 1.1 から EJB 2.x に変換されるプロジェクトについては、 既存の EJB 1.1 コードを EJB 2.x にマイグレーションするためのステップを実行する必要があります。
EJB 1.1 リレーションを作成すると、リモート・クライアント・ビューに 対して EJB 参照が作成されます。J2EE マイグレーション・ウィザード を使用した EJB 1.1 プロジェクトのマイグレーション中に、 これらの EJB 1.1 リレーションに対する EJB リモート参照は除去されて、 EJB ローカル参照に置換されます。 ユーザー定義の EJB 参照のローカル参照は、手動で再作成する必要があります。
ユーザー定義の EJB 参照の場合、 マイグレーションは J2EE マイグレーション・ウィザードを使用して実行されません 。 以下のステップに従ってローカル参照をセットアップしてください。
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>
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 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 マイグレーション・ウィザードの使用法について詳しくは、 オンライン・ヘルプを参照してください。
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 にポートレット・プロジェクトを手動でマイグレーションする必要があります。
ポートレット TLD ファイルが存在する 場合は、プロジェクトから削除することをお勧めします。削除しないと、 プロジェクトを再ビルドしたときに警告メッセージを受け取ります。このファイルを残しておくと、 ポートレット・プロジェクトが WebSphere Portal にデプロイされて、 ポートレットの TLD ファイルがサーバーのファイルと異なる場合に問題が発生します。
WebSphere Portal V4.2 ポートレットを V5.x に マイグレーションすることについて詳しくは、 「WebSphere Portal V4.2 ポートレットから V5.x へのマイグレーション」を参照してください。
ポートレット・プロジェクトの Faces リソースのマイグレーションについて詳しくは、「ポートレット・プロジェクトでの Faces ランタイム・リソースの更新」 を参照してください。
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 にマイグレーションするには、以下のステップを実行してください。
これで、ポートレット・プロジェクトが WebSphere Portal V5.x にマイグレーションされました。
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 ランタイム・リソースを自動的に更新するには、以下のようにします。
ランタイム・リソースを手動で更新する
ポートレット・プロジェクトに対して Faces ランタイム・リソースを手動で更新するには、以下のようにします。
<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>
<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>
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 テスト環境のレベルを示したものです。
| 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 |