WebSphere Studio "Classic" から IBM WebSphere Studio Site Developer へのマイグレーション
第 1 章 WebSphere Application Server - Expressマイグレーション・ガイドの概要
第 3 章 IBM WebSphere Studio Site Developer バージョン 5.1 からのマイグレーション
第 4 章 IBM WebSphere Studio Site Developer バージョン 5 またはバージョン 5.0.1 からのマイグレーション
第 5 章 IBM WebSphere Studio Site Developer バージョン 4.0.x からのマイグレーション
第 6 章 WebSphere Studio "Classic" から IBM WebSphere Studio Site Developer へのマイグレーション
第 7 章 VisualAge for Java から IBM WebSphere Studio Site Developer へのマイグレーション
第 8 章 VisualAge for Java Visual Composition Editor から Visual Editor for Java へのマイグレーション
第 9 章 ビルド・セットアップ (ライブラリー、JAR、従属プロジェクト JAR、Ant ビルド)
IBM(R) WebSphere(R) Application Server - Express バージョン 5.1 では、以下からコードをマイグレーションできます。
WebSphere Application Server - Express 5.1 は、 WebSphere Application Server 5.1 と WebSphere Studio Site Developer 5.1.1 から構成されています。 以下の最初の章では、WebSphere Application Server - Express のサーバー・フィーチャーのマイグレーションについて説明します。マイグレーション・ガイドの残りの部分では、異なるバージョンの WebSphere Studio Site Developer からのコードのマイグレーションについて説明します。
サーバーのマイグレーションに関する重要な注記
ご使用のサーバー構成のマイグレーションは、管理コンソールを使用してサーバーを管理している場合にのみ意味があります。すなわち、通常は実稼動環境の場合です。このオペレーション・モードでは、サーバー構成とデプロイされたアプリケーションはサーバーの構成ディレクトリーに格納されます。 マイグレーション・プロセスでは、これらの構成ファイルおよびアプリケーション・ファイルをマイグレーションします。一方、WebSphere Studio Site Developer を使用してアプリケーションを構成し、リモート・サーバーにデプロイしている場合は、サーバー構成ファイルをマイグレーションする必要はありません。その理由は、構成ファイルおよびアプリケーション・ファイルはすべて、Studio Site Developer のワークスペースに維持されているからです。 ワークスペースは Studio Site Developer によってマイグレーションされます。このマイグレーションの後に、WebSphere Application Server - Express 5.1 サーバーの新しいインスタンスを定義し、Studio Site Developer からのアプリケーションの構成およびデプロイを続行することができます。
本書は、以下の章から構成されています。
WebSphere Studio "Classic" から IBM WebSphere Studio Site Developer へのマイグレーション
WebSphere Application Server - Express の使用に関する情報は、 「ご使用になる前に」ガイドおよびオンライン・ヘルプを参照してください。 WebSphere Application Server - Express をインストールする場合は、 その前に「インストール・ガイド」をお読みください。 WebSphere Application Server - Express を正しくインストールしたら、 「ご使用になる前に」ガイドを参照して、「ご使用になる前に」のチュートリアルに従ってください。 このチュートリアルでは、ワークベンチ、 Java(TM) 開発、および Web サービスについて学習します。チュートリアルを終了したら、このガイドを参照してご使用のリソースを WebSphere Application Server - Express にマイグレーションしてください。
このガイドは HTML バージョンと Acrobat PDF の両方のバージョンが /Readme のディレクトリーで使用可能です。 両方のバージョンは同一の情報内容です。ユーザーはどのような Web ブラウザーでも migrate.html をオープンすることができます。 migrate.pdf をオープンするには、Acrobat Reader ソフトウェアがインストール済みでなければなりません。これは www.adobe.com/products/acrobat/readstep2.html からダウンロードすることができます。
この「マイグレーション・ガイド」では、一貫して Windows(R) の規則を使用しています。例えば、Windows の「WS_Installdir¥」は Linux の「WS_Installdir/」に相当します。
本書の更新については、www.ibm.com/websphere/developer/zones/studio/transition.html を参照してください。
マイグレーションとは、既存の資料を利用する作業です。 マイグレーション作業およびツールは、製品とその前提条件をアップグレードし、可能な場合には 既存のアプリケーション・コンポーネントを再利用し、以前のバージョンから現行バージョンに 管理構成を移行する作業を支援します。
WebSphere Application Server 製品のマイグレーションとは、既存の環境とアプリケーションを利用して、 現在の製品バージョンと互換性のある状態にそれを変更することです。
製品のマイグレーション機能は、IBM WebSphere Application Server - Express バージョン 5.1 の マイグレーション・ツールによって提供されます。マイグレーション・ツールは、以下の製品からの マイグレーションをサポートしています。
製品のインストール・ウィザードは、前のバージョンの IBM WebSphere Application Server - Express を 検出し、Version 5.1 のインストールの間に、マイグレーション・ツールを実行できるようにします。IBM WebSphere Application Server Version 3.5 からマイグレーションするには、これらのツールを直接実行する必要があります。
マイグレーションのレッドブック
「Migrating to WebSphere V5: An End-to-End Migration Guide 」は、 レッドブックの Web サイト http://www.ibm.com/redbooks から 入手できます。レッドブックを探すには、文書番号 SG24-6910-00 を検索してください。レッドブックでは、 アプリケーションのマイグレーションの計画に関するさらに詳細な情報や、WebSphere Studio Application Developer の ツールとサンプルなど、この記事より広い範囲の情報が提供されています。
バージョン 3.5 のマイグレーション: J2EEモデルへの移行
V3.5.x を V5 にアップグレードすると、J2EE 仕様に基づくプラットフォームに移行します。J2EE 技術では、 アプリケーションの開発と作成が、アプリケーションの管理、デプロイメント、および管理から分離されます。V3.5 からの マイグレーションには、アプリケーションの構造、開発、およびデプロイメントの変更が伴います。
マイグレーション・ツールは、システム構成をマイグレーションし、J2EE セキュリティー役割マッピングなどの J2EE 成果物を作成することで、バージョン 3.5.x からバージョン 5 への移行を支援します。マイグレーション・ツールは、 バージョン 3.5.x の構成に基づいて、初期の J2EE エンタープライズ・アプリケーションを作成します。ただし、 アプリケーションの構造が大きく変更されたため、新しい環境でアプリケーションがどのように機能するのかを 正確に判別するために、開発ツールとデプロイメント・ツールを使用して、マイグレーション済みのアプリケーションを 慎重にテストおよび調整する計画を立ててください。
J2EE モデルでは、最終的なデプロイメント環境から独立して、アプリケーションを開発できます。このように作業が 分離されることで、初期開発環境から実働環境へのアプリケーションのプロモート、またはサーバー間での アプリケーションの移動が単純化されます。意図されているのは、アプリケーションのデプロイメント・パラメーター だけを変更し、アプリケーション・コードは変わらないようにすることです。
始める前に、WebSphere Application Server バージョン 5.1 製品をインストールするマシンに、既存の バージョンがインストールされているかどうかを判別する必要があります。前のバージョンがある場合は、 前のバージョンの構成およびアプリケーションを新しいバージョンにコピーするかどうか、 つまりマイグレーション するかどうかを計画しなければなりません。マイグレーションでは、 前のバージョンはアンインストールされません。以前のリリースは変わらずに機能します。前のバージョンを バージョン 5.1 のインストールと同時に実行する場合、2 つのバージョンは共存 する ことになります。両方のバージョンを同時に実行するには、ポートを競合しないように構成する必要が あります。マイグレーション操作はポートの定義をそのままマイグレーションするので、両方のバージョンで ポートの定義が同じになることに注意してください。WebSphere Application Server には、すべての マイグレーション機能を提供するマイグレーション・ツールが用意されています。マイグレーション・ツールは、 インストール・ウィザードから呼び出すことも、後で手動で呼び出すこともできます。
IBM WebSphere Application Server - Express V5.0.x から V5.1 へのマイグレーションは、だいたいにおいて ルーチン化されています。インストーラーを使用してマイグレーションを行えば、マイグレーション後のチューニングは ほとんど、またはまったく必要ありません。または、マイグレーション・ツールを手動で使用して V5.0.0、V5.0.1、 または V5.0.2 の構成データを保存し、V5.0.0、V5.0.1、または V5.0.2 をアンインストールしてから V5.1 を インストールした後、再びマイグレーション・ツールを使用して、構成データを復元することもできます。
全体として、IBM WebSphere Application Server V3.5 から IBM WebSphere Application Server - Express V5.1 への マイグレーションには、アプリケーションの構造、開発、およびデプロイメントに関する大幅な変更が 伴います。マイグレーション・ツールは、システム構成をマイグレーションし、以前のセキュリティー設定から J2EE セキュリティー役割へのマッピングなどの J2EE 成果物を作成することで、この移行を支援します。このような セキュリティー・マッピングにより、移行の間にマイグレーションされる資産へのアクセスが可能になります。マイグレーション・ツールは、 バージョン 3.5.x の構成に基づいて、初期の J2EE エンタープライズ・アプリケーションを作成します。ただし、 アプリケーション構造が大きく変更されたため、開発ツールとデプロイメント・ツールを使用して、マイグレーション後の アプリケーションを慎重にテストおよび微調整する必要があります。
マイグレーションでは、以下のファイルが backup ディレクトリーに保管されます。
このトピックでは、WebSphere Application Server で提供されているマイグレーション・ツールについて 説明します。マイグレーション・ツールはすべて、製品 CD-ROM の /migration ディレクトリーに 収められています。インストールする Application Server のバージョン用のマイグレーション・ツールを 使用することが重要です。ツールには、随時変更が加えられていきます。製品 CD-ROM に収められている ツールは、以前のリリースの Application Server を製品 CD-ROM のリリースにマイグレーションするために 必要な機能を備えています。CD-ROM のツールは、CD-ROM の製品に対応しています。Application Server の 以前のリリースのマイグレーション・ツールを使用すると、マイグレーションで問題が発生する可能性があります。
WASPreUpgrade.sh (または WASPreUpgrade.bat) スクリプトは、 以前のバージョンまたはリリースから Version 5.1 Application Server - Express に構成とアプリケーションを マイグレーションするための、マイグレーション・ツールです。
コマンド・ファイルは、インストール後のインストール・ルートの AppServer/bin サブディレクトリーに あります。CD の migration サブディレクトリーから直接使用することもできます。
構文
WASPreUpgrade backupDirectory currentWASDirectory
[adminNodeName]
[-nameServiceHost host_name [-nameServicePort port_number ]]
[-traceString trace_spec [-traceFile file_name ]]
パラメーター
最初の 2 つの引き数は必須であり、位置を変えることはできません。
以下の引き数がサポートされています。
ロギング
WASPreUpgrade ツールは、実行中のステータスを画面に表示します。また、さらに広範なロギング情報の セットを、backup ディレクトリーに 保管します。WASPreUpgrade.log ファイルの内容は、テキスト・エディターで 見ることができます。
WASPostUpgrade.sh (または WASPostUpgrade.bat) スクリプトは、 以前のバージョンまたはリリースから Version 5.1 Application Server - Express に構成とアプリケーションを マイグレーションするための、マイグレーション・ツールです。
コマンド・ファイルは、インストール・ルートの AppServer/bin ディレクトリーにあります。
WASPostUpgrade ツールは、マイグレーションされたすべてのアプリケーションを、バージョン 5.1 インストール の AppServer/installedApps ディレクトリーに インストールします。このツールでは、WASPreUpgrade ツールが作成したバックアップ・ディレクトリーにある アプリケーションもインストールされます。WASPreUpgrade ツールは、以前のバージョンまたはリリース の installedApps およびその他のディレクトリーからアプリケーションを コピーします。
構文
WASPostUpgrade backupDirectory
[-serverName server_name]
[-webModuleAdditionalClasspath classpath]
[-documentRootLimit number]
[-substitute "key1=value1[;key2=value2;[...]]"]
[-portBlock port_starting_number]
[-backupConfig true | false]
[-replacePorts true | false]
[[-traceString trace_spec [-traceFile file_name]]
パラメーター
最初の引き数は必須です。以下の引き数がサポートされています。
入力 XML データ・ファイルでは、置き換えられる各キーは $key$ と示されています。上の例の引き数 では、入力 XML ファイル中の $NODE_NAME$ はすべて admin_node に 置き換えられ、$APP_SERVER$ はすべて default_server に 置き換えられます。
置換ストリングにセミコロンが含まれる場合は、区切り文字の ";" と区別するために、$semiColon$ を 使用します。UNIX プラットフォームでは、置換ストリング内の各ドル記号 ($) に対してエスケープ文字を追加します (例 : \$semiColon\$)。
このパラメーターは、Advanced Edition バージョン 3.5.x から保管された構成に適用されます。
ロギング
WASPostUpgrade ツールは、実行中のステータスを画面に表示します。また、さらに広範なロギング情報の セットを、logs ディレクトリーに保管します。WASPostUpgrade.log ファイルの 内容は、テキスト・エディターで見ることができます。
このトピックでは、マイグレーションにおいて変更される部分について説明します。これには、常に、 スタンドアロン・マシンでの開発環境のようなシングル・マシンが含まれます。
マイグレーションされた Enterprise Bean に関する詳細な情報については、WASPostUpgrade.log ファイルを 分析してください。J2EE プログラミング・モデルでは、アプリケーションを作成およびデプロイする方法についての アーキテクチャーが指定されています。バージョン 3.5.x のアプリケーションはアーキテクチャーが異なる ので、WASPostUpgrade ツールはアプリケーションを再作成します。J2EE アプリケーションにおいてマイグレーションされる すべての Web リソースと Enterprise Bean が作成されます。また、バージョン 3.5.x インストールのすべての エンタープライズ・アプリケーションが、同じ名前で J2EE アプリケーションにマップされ、同じサーバーに デプロイされます。
WASPostUpgrade ツールは、エンタープライズ・アプリケーションに組み込まれていない Web リソースを、 サーバーの名前を含むデフォルトの J2EE アプリケーションにマップします。このツールは、Web アプリケーションを J2EE WAR ファイルにマップします。このツールは J2EE EAR ファイル内のリソースを結合し、それをバージョン 5 の 構成にデプロイします。
バージョン 3.5.x の datasources.xml ファイルを使用して、データ・ソース構成の 設定を追加できます。バージョン 3.5.x では、このファイルは properties ディレクトリーに 保管されています。マイグレーション・ツールは、ファイル内のプロパティーをデータ・ソースおよび JDBC ドライバーの 構成にマージすることで、既存の datasources.xml ファイルをマイグレーションします。
バージョン 3.5.x の enterprise-application エントリーはオプションです。このエントリーは、セキュリティー定義に 対してオブジェクトの集合をまとめて編成するために、最もよく使用されます。enterprise-application の Enterprise Bean と web-application の部分は、XML ファイルの他の部分にある対応するエントリーを指しています。各 enterprise-application は、 同じ名前を持つ J2EE アプリケーションを作成するために処理されます。Enterprise Bean および web-application の エントリーは、Enterprise Bean および Web アプリケーションの定義へのポインターとして使用されます。さらに、 これらのエントリーの詳細は J2EE アプリケーションを作成するために使用されます。
Enterprise Bean のファイルの場合、JAR-file の定義は、J2EE アプリケーションを再デプロイしたり、J2EE アプリケーションに 追加したりするための JAR ファイルを検出するために使用されます。Web-application の document-root エントリー は、Web-application 内で使用されるリソース (HTML、JSP ページなど) を検出するために使用されます。これらの ファイルは、J2EE アプリケーション内の WAR ファイルにコピーされます。Web-application の classpath エントリー は、J2EE アプリケーション内の WAR ファイルにコピーされるサーブレットおよび JAR ファイルを検出するために 使用されます。
エンタープライズ・アプリケーションは、バージョン 3.5.x からのマイグレーションの過程で作成されます。 これらは J2EE 1.2 互換のエンタープライズ・アプリケーションとして作成され、サーブレット 2.2 レベル および JSP 1.1 レベルのモジュールを含みます。これにより、最も直接的な互換性が提供され、 前のバージョンの WebSphere Application Server との相互運用が可能になります。
バージョン 3.5.x のセキュリティー許可モデルは、エンタープライズ・アプリケーションおよびメソッド・グループの 概念に基づいています。エンタープライズ・アプリケーションとメソッド・グループのクロス積が、WebSphere Application Server の許可になります。J2EE の仕様には、役割に基づく許可モデルが含まれています。
バージョン 3.5.x の WebSphere Application Server 許可モデルをバージョン 5 の役割ベースの許可モデルに 変換するため、マイグレーション・ツールは、WebSphere Application Server の許可からそのアプリケーション での新しい役割に対する 1 対 1 のマッピングを作成します。したがって、V3.5.x の各エンタープライズ・アプリケーション および各メソッド・グループに対し、マイグレーション・ツールはバージョン 5 の役割を作成します。 これらは、J2EE アプリケーションのデプロイメント・ディスクリプターに含まれています。 それぞれの役割で許可される対象は、J2EE アプリケーションのバインディングにある許可テーブルに 含まれています。
J2EE の仕様には、役割に基づく許可モデルが含まれています。WebSphere Application Server は、リソースに アクセスするための一連の許可を意味する役割を解釈します。Enterprise Bean メソッドの呼び出しの場合、 特定の Bean のメソッドにアクセスするための許可は、メソッド許可によって指定されます。このメソッド許可 は、Bean JAR ファイルのデプロイメント・ディスクリプター内の 1 つ以上の役割に関連付けられます。
Web リソースへのアクセスの場合は、Web URI にアクセスし、その URI の HTTP メソッドを呼び出す許可は、J2EE 仕様の Web リソース・コレクションおよびセキュリティー制約という形で指定されています。セキュリティー制約と Web リソース・コレクションは、Web アプリケーションの WAR ファイルのデプロイメント・ディスクリプターにあります。
バージョン 5 は、JSP 1.0 と 1.1 のオブジェクトを、JSP 1.2 のオブジェクトとして実行します。バージョン 5 が サポートするレベルは JSP 1.2 だけです。
バージョン 5 は、以前のバージョンのサーブレット・リダイレクターをサポートしません。マイグレーション・ツールは、 これらのオブジェクトを無視します。
バージョン 3.5.x の構成で SimpleFileServlet サーブレットが定義されている場合、このサーブレットは マイグレーションされません。マイグレーション・ツールは、Web モジュール・ファイル ibm-web-ext.xmi 内の FileServingEnabled 属性を true に設定します。
バージョン 3.5 の構成で InvokerServlet サーブレットが定義されている場合、このサーブレットは マイグレーションされません。マイグレーション・ツールは、Web モジュール・ファイル ibm-web-ext.xml 内の ServeServletsByClassnameEnabled 属性を true に設定します。
バージョン 3.5.x の構成で DefaultErrorReporter サーブレットが定義されている場合、このサーブレットは Web モジュール・ファイル web.xml にマイグレーションされます。マイグレーションでは、クラス名を設定するために 新しいパッケージが使用されます。
バージョン 3.5.x のサーブレット・エンジンのデフォルト・トランスポート・タイプは、Open Servlet Engine (OSE) です。バージョン 5 では OSE トランスポートがサポートされなくなったため、マイグレーション・ツールは、同じポート割り当てを使用して、 これらのトランスポートを HTTP トランスポートにマップします。ポートごとに VirtualHost エイリアスのエントリーを 手動で追加する必要があります。
このタスクで説明するように、インストール・ウィザードを使用して、または手動で、管理構成をマイグレーション できます。マイグレーションを手動で行う場合は、インストール・ウィザードのマイグレーション・パネルで マイグレーション・チェック・ボックスを選択しないでください。
以前のバージョンの WebSphere Application Server を使用している場合は、システム管理者が、アプリケーションや サーバーのさまざまな設定を、環境に合わせて微調整している可能性があります。このような設定を最大限の効率と 最小限の損失でマイグレーションする戦略を用意する必要があります。
手動での段階的マイグレーションは、マイグレーション・ツールを繰り返し呼び出し、そのたびに異なる構成ファイルを 指定することで実行できます。複数の構成ファイルを使用するのには、いくつかの理由があります。どのような理由で あっても、一度に 1 つの構成ファイルをマイグレーションすることで、次の構成ファイルに進む前に、アプリケーションを 段階的にテストすることができます。
マイグレーション・ツールを使用する前に、V5.x のリリース情報資料を参照して、以前のバージョンに 適用する必要のある修正を確認してください。以前のバージョンの修正を適用することで、マイグレーションに 使用するファイルにも修正が適用される場合があります。修正を適用することで、構成やアプリケーションを 可能な限り最も効率よくマイグレーションすることができます。
手動によるマイグレーションでは、インストール・ウィザードが提供する完全なマイグレーションよりさらに 段階的なマイグレーション方法が用意されています。IBM は、V3.5.x または V5.0.x の任意の版から WebSphere Application Server - Express 製品に管理構成をマイグレーションするための、一連の マイグレーション・ツールを提供しています。マイグレーションの全体的なプロセスは、WASPreUpgrade マイグレーション・ ツールを使用して現在の構成と必要なファイルをバックアップし、以前のリリースをアンインストールし、自動 マイグレーション・オプションを選択しないでバージョン 5 をインストールした後、WASPostUpgrade マイグレーション・ ツールを使用して以前のリリースの構成を復元するというものです。
構成データを WebSphere Application Server の基本ノードにマイグレーションする方法については、 以下のマイグレーション・シナリオのいずれかを選択してください。
マイグレーション・ツールを使用して、バージョン 3.5 の WebSphere Application Server からバージョン 5.1 の WebSphere Application Server - Express に構成データをマイグレーションできます。
通常は、WebSphere Application Server V5.1 のマイグレーション・ツール WASPreUpgrade および WASPostUpgrade を 使用して、同じ マシン上で V3.5 から V5.1 にアップグレードします。あるマシンの V3.5 構成を 別のマシンの WebSphere Application Server - Express V5.1 にマイグレーションするシナリオの場合は、 V3.5.x からリモート V5.1 マシンへのマイグレーション で説明されている代替手順を使用してください。
このトピックでは、V5.1 のマイグレーション・ツールを使用してマイグレーションを行う方法について説明します。
WASPreUpgrade ツールは、既存の V3.5 の構成を、migration-specific-backup ディレクトリーに 保管します。WASPostUpgrade ツールは、このディレクトリーを使用して、古い構成の設定を新しい V5.1 環境に追加します。
この作業のステップ
この CD には、migration/bin というディレクトリーがあります。このディレクトリー には、V5.1 をインストールしないで WASPreUpgrade ツールを実行するために使用できる特殊な環境が含まれています。
構成を migration-specific-backup ディレクトリーに保管します。
WASPreUpgrade /usr/tmp/migration-specific-backup /usr/websphere/appserver yourNodeName
既存の環境の管理サーバーが稼動していることを確認します。WASPreUpgrade ツールは、状況を画面に表示すると 共に、migration-specific-backup ディレクトリーのログ・ファイルに 記録します。ASCII 形式のログ・ファイルの名前は、WASPreUpgrade で始まり、日付のタイム・スタンプが含まれています。
WASPreUpgrade ツールは、既存の V3.5.x 構成に存在する以下のディレクトリーに含まれるすべてのファイルを、 バックアップ・ディレクトリーに保管します。
WASPreUpgrade ツールは、V3.5.x の /bin ディレクトリーから、選択された ファイルを保管します。また、V3.5.x のリポジトリーから既存の Application Server の構成をエクスポート します。WASPreUpgrade ツールは、XMLConfig を呼び出して、既存の V3.5 のリポジトリーを migration-specific-backup ディレクトリー の websphere_backup.xml ファイルにエクスポートします。
WASPreUpgrade ツールの実行中にエラーが発生する場合、エクスポート・ステップを正常に実行するためには、V3.5 の インストールに修正を適用する必要がある場合があります。該当する可能性のある最新の修正については、IBM の サポート・ページを参照してください。InfoCenter からこの情報を表示するには、IBM サポート・ページに リンクしている「サポート」をクリックして下さい。
マイグレーション・オプションが表示されても選択しないでください。
WASPostUpgrade の使用が終了するたびに、2 つのファイルで V5 のポート設定を検査します。
以前のバージョンの BOOTSTRAP_ADDRESS ポートが 900 の場合は、マイグレーションによって 7809 に マップされます。以前のバージョンの BOOTSTRAP_ADDRESS ポートが 900 ではない場合は、マイグレーションに よって、Advanced Edition マイグレーションでの server1 に、または Advanced Single Server Edition マイグレーション での実際のサーバー名に、マップされます。
WASPostUpgrade の処理では、以前のバージョンの HTTP Transport ポートが、バージョン 5 の server.xml ファイルに 追加されます。つまり、server1 には、共存パネルからと、以前のバージョンのデフォルト・ サーバー からの、重複する HTTP Transport ポート割り当てが含まれています。
WASPostUpgrade ツールは、WASPreUpgrade ツールによって作成された V3.5.x の構成情報を、V5.1 のインストールに マイグレーションします。V5.1 製品は J2EE プログラミング・モデルに準拠し、V3.5.x は準拠しないので、V3.5.x の 構成を V5.1 インストールに適用するには、大幅な変更が必要です。
V5.1 にはすでにサンプルと管理コンソール・アプリケーションがあるので、WASPostUpgrade ツールは、サンプル または管理コンソール・アプリケーションのマイグレーションを行いません。
WASPostUpgrade ツールは、デプロイされる各 Enterprise Bean に固有の詳細情報を、WASPostUpgrade.log ファイルに、 記録します。
マイグレーション後に WebSphere Application Server の構成を行って、マイグレーション・ツールの結果を 検査します。マイグレーションの途中で構成マッピングを使用して、マイグレーションの結果を検査することも できます。トピックには、マイグレーション・ツールがオブジェクトをマイグレーションする方法と、 検査が必要な項目についての詳細な説明があります。
マイグレーション・ツールを使用して、2 つのマシン間の手動マイグレーションを実行できます。
通常は、WebSphere Application Server - Express のマイグレーション・ツール WASPreUpgrade および WASPostUpgrade を 使用して、同じ マシン上で V3.5 から V5.1 にアップグレードします。
しかし、あるマシンの V3.5 構成を別のマシンの V5.1 にマイグレーションしなければならないシナリオが あります。このようなシナリオの 1 つとしては、新しいマシンに最新の V5.1 環境をインストールし、一方で 他のマシンにある既存の V3.5 構成をマイグレーションする必要があるような場合です。
このトピックでは、V5.1 のマイグレーション・ツールを使用してマイグレーションを行う方法について説明します。
WASPreUpgrade ツールは、既存の V3.5 の構成を、migration-specific-backup ディレクトリーに 保管します。WASPostUpgrade ツールは、このディレクトリーを使用して、古い構成の設定を新しい V5.1 環境に追加します。
この作業のステップ
この CD には、migration/bin というディレクトリーがあります。このディレクトリー には、V5.1 をインストールしないで WASPreUpgrade ツールを実行するために使用できる特殊な環境が含まれています。
V3.5 マシン上の migration-specific-backup ディレクトリーに、構成を保管します。
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver adminNodeName
既存の環境の管理サーバーが稼動していることを確認します。
WASPreUpgrade ツールは、状況を画面に表示すると 共に、/migration-specific-backup ディレクトリーのログ・ファイルに 記録します。ASCII 形式のログ・ファイルの名前は、WASPreUpgrade で始まり、日付のタイム・スタンプが含まれています。
WASPreUpgrade ツールは、V3.5.x の /bin ディレクトリーから、選択された ファイルを保管します。また、V3.5.x のリポジトリーから既存の Application Server の構成をエクスポート します。WASPreUpgrade ツールは、XMLConfig を呼び出して、既存の V3.5 のリポジトリーを migration-specific-backup ディレクトリー の websphere_backup.xml ファイルにエクスポートします。
WASPreUpgrade ツールの実行中にエラーが発生する場合、エクスポート・ステップを正常に実行するためには、V3.5 の インストールに修正を適用する必要がある場合があります。該当する可能性のある最新の修正については、IBM の サポート・ページを参照してください。InfoCenter からこの情報を表示するには、IBM サポート・ページに リンクしている「サポート」をクリックして下さい。
ファイルを新しいマシンにコピーするには、FTP、共用ストレージ、または他のメカニズムを使用します。
WebSphere Application Server - Express の V5.1 のマシンで、以下のステップを実行します。
このファイルをコピーするのは、次のステップで元のファイルを編集するためです。
ファイルを以下のように変更します。
元の V3.5 構成で使用していたものと同じノード名前を V5.1 マシンでも使用する場合は、名前を変更しません。 名前が異なる場合は、V3.5 のノード名が使用されているすべての箇所を、WebSphere Application Server V5.1 で 使用するノード名に変更する必要があります。ノード名は、ファイル中の複数の XML スタンザで 使用されています。すべての箇所が変更されないと、データを完全にマイグレーションすることができません。
構成ファイル内の複数の XML スタンザで、パス名が参照されています。同等のディレクトリーを作成しなければならない 場合であっても、V3.5 のディレクトリー構造の外部にあるファイルに対する参照を、新しいマシン上の同等の ディレクトリーに更新します。対応する環境を構成するということは、元のディレクトリーを V5.1 マシンにコピーする 必要がある場合があることを意味します。あるいは、適切なソフトウェアのインストールが必要になる場合があります。
パスの指定が、V5.1 を実行するマシン上で動作する形式と異なる場合は、修正する必要があります。たとえば、Windows プラットフォーム 上の V3.5 を Linux プラットフォーム上の V5.1 に移行する場合は、構成ファイルに含まれる Windows 固有の パスを、Linux のパス・スタイルを使用するように変更します。たとえば、"c:¥mystuff¥somepath" は "/opt/mystuff/somepath" に変更します。
ユーザー ID とパスワードが V5.1 マシンで使用されているものと異なる場合は、変更する必要があります。
エンコードされたパスワードを平文のパスワードに変更するには、<password>{xor}LCoxayht</password> を <password>mypassword</password> に 変更します。
構成では、新しいマシンに存在しない他のソフトウェア製品や構成が参照されている場合があります。たとえば、 古いマシンにはデータベースが存在する場合があります。V5.1 の構成では、おそらく、古いマシンのデータベースを まだ指し示す必要があります。このような場合は、V3.5 マシン上のデータベースを指すようにデータ・ソースを変更します。
V5.1 インストールのルート・ディレクトリーの AppServer/bin ディレクトリー にある WASPostUpgrade ツールを使用して、V5.1 の構成に V3.5 の構成を追加します。
WASPostUpgrade /opt/tmp/migration-specific-backup
WASPostUpgrade ツールは、デプロイされる各 Enterprise Bean に固有の詳細情報を、/migration-specific-backup/WASPostUpgrade.log ファイルに、 記録します。
V5.1 インストール・プログラムを使用して、WebSphere Application Server - Express V5.0.x から V5.1 に マイグレーションできます。
この作業のステップ
インストール・ルートの AppServer/bin ディレクトリーの stopServer.sh (または stopServer.bat) スクリプトを使用します。
stopServer.sh server1
サーバーを停止しなくても V5.0.x ノードをマイグレーションできます。ただし、構成をマイグレーションするには ノードが稼動している必要はありません。マイグレーション・ツールは、ノードが停止していても、すべての構成データを 取得できます。また、インストールしている V5.1 ノードを開始する前には、ノードを停止する必要があります。したがって、 現時点でノードを停止してもかまいません。
マイグレーション・オプションが表示されたら、それを選択します。
製品のインストールの最後で First Steps ツールが表示されたら、それを使用します。または、何らかの理由で First Steps ツールが表示されない場合は、手動でインストール検査テストを実行します。
V5.0.x サーバーのアンインストールは、いつでも都合のよいときに行うことができます。
マイグレーション・ツールを使用して、2 つのマシン間のマイグレーションを行うことができます。
始める前に
通常は、WebSphere Application Server V5.1 のマイグレーション・ツール WASPreUpgrade および WASPostUpgrade を 使用して、同じ マシン上で V5.0.x から V5.1 にアップグレードします。
しかし、あるマシンの V5.0.x 構成を別のマシンの V5.1 にマイグレーションしなければならないシナリオが あります。このようなシナリオの 1 つとしては、新しいマシンに最新の V5.1 環境をインストールし、一方で 他のマシンにある既存の V5.0.x 構成をマイグレーションする必要があるような場合です。
このシナリオでは、V5.1 のマイグレーション・ツールを使用してマイグレーションを実行する方法について説明します。
WASPreUpgrade ツールは、既存の V5.0.x の構成を、migration-specific-backup ディレクトリーに 保管します。WASPostUpgrade ツールは、このディレクトリーを使用して、古い構成の設定を新しい V5.1 環境に追加します。
この作業のステップ
この CD には、migration/bin というディレクトリーがあります。このディレクトリー には、V5.1 をインストールしないで WASPreUpgrade ツールを実行するために使用できる特殊な環境が含まれています。
V5.0.x マシン上の migration-specific-backup ディレクトリーに、構成を保管します。
WASPreUpgrade /opt/tmp/migration-specific-backup /opt/websphere/appserver
WASPreUpgrade ツールは、状況を画面に表示すると 共に、/migration-specific-backup ディレクトリーのログ・ファイルに 記録します。ASCII 形式のログ・ファイルの名前は、"WASPreUpgrade" で始まり、日付のタイム・スタンプが含まれています。
ファイルを新しいマシンにコピーするには、FTP、共用ストレージ、または他のメカニズムを使用します。
V5.1 インストールのルート・ディレクトリーの AppServer/bin ディレクトリー にある WASPostUpgrade ツールを使用して、V5.1 の構成に V5.0.x の構成を追加します。
WASPostUpgrade /opt/tmp/migration-specific-backup
WASPostUpgrade ツールは、デプロイされる各 Enterprise Bean に固有の詳細情報を、/migration-specific-backup/WASPostUpgrade.log ファイルに、 記録します。
以下の変更を行います。
ユーザー ID とパスワードが V5.0.x マシンで使用されているものと異なる場合は、変更する必要があります。
構成では、新しいマシンに存在しない他のソフトウェア製品や構成が参照されている場合があります。たとえば、 古いマシンにはデータベースが存在する場合があります。このような場合は、古いマシン上のデータベースを 指すようにデータ・ソースを変更します。
バージョン 5.1 がサポートしていないオペレーティング・システム上で稼動する WebSphere Application Server バージョン 3.5.x または バージョン 5.0.x をマイグレーションできます。
この作業のステップ
2 つのオプションがあります。バージョン 5.1 CD-ROM の platform_root の migration¥bin (または migration/bin) ディレクトリーからコマンドを実行します。または、CD-ROM の ディレクトリーのファイルを、ハード・ディスクに作成したディレクトリーにコピーしてもかまいません。
バージョン 3.5.x または 5.0.x のリリース、およびコマンドが構成ファイルおよび以前のバージョンから マイグレーションするアプリケーションを格納したバックアップ・ディレクトリーを確認します。コマンドの 構文については、WASPreUpgrade のトピックを参照してください。
バックアップ・ディレクトリーおよび構成ファイルの場所を確認します。
CD_drive:¥WASPreUpgrade backupDirectory filepath¥WebSphere¥AppServer yourNodeName
正常に処理が行われた場合はステップ 4 に進みます。何らかの理由で正常に処理が行われなかった場合は、 ステップ 2B から 2F を実行します。
以下の変数を変更します。
バックアップ・ディレクトリーおよび構成ファイルの場所を確認します。
yourMigrationDirectory¥WASPreUpgrade backupDirectory filepath¥WebSphere¥AppServer yourNodeName
可能であれば、システム名とパスワードも古いシステムと同じにします。マイグレーションしているアプリケーションに 関連するすべてのデータベース・ファイルを、以前のシステムと同じパスに配置します。一般に、 パスは変更しないようにします。ただし、バージョン 5.1 は、以前のバージョンと同じディレクトリーに インストールしないでください。パスと名前を変更する場合は、それに合わせて XML 構成ファイルを 変更します。このような変更は、以下の WASPostUpgrade コマンドを実行する前に 行う必要があります。
WASPreUpgrade コマンドによって作成されたバックアップ・ディレクトリー (および、 そのディレクトリー内にあるすべての非標準構成ファイル名) を指定します。コマンドの正しい構文に ついては、WASPostUpgrade のトピックを参照してください。
install_root¥bin¥WASPostUpgrade WAS_HOME¥migration
この章では、以下のマイグレーション・トピックを取り上げます。
IBM WebSphere Studio Site Developer バージョン 5.1.1 には、新しいサーバーのターゲット機能が追加されています。この機能はデフォルトでは使用不可になっており、「ウィンドウ (Window)」>「設定 (Preferences)」>「J2EE」を選択することにより、J2EE 設定ページでこの機能を使用可能にする必要があります。 サーバーのターゲット機能の機能詳細については、 IBM WebSphere Studio Site Developer 製品資料を参照してください。この機能が使用可能になっていれば、特定のアプリケーション・サーバーをターゲットとするオプションが使用できます。 このフィーチャーは、JDK 1.4 をサポートするためにインプリメントされたものです。これは、IBM WebSphere Studio Site Developer バージョン 5.1.1 に付属の WebSphere Application Server バージョン 5.1 用の JRE です。 サーバーのターゲット・サポートを利用する J2EE プロジェクトは、 IBM WebSphere Studio Site Developer の以前のバージョンとは後方互換性がありません。このため、IBM WebSphere Studio Site Developer の以前のバージョン (例えば、 IBM WebSphere Studio Site Developer バージョン 5.1、 IBM WebSphere Studio Site Developer バージョン 5.0.1) で作業するユーザーとは共用できません。 IBM WebSphere Studio Site Developer は、このフィーチャーとの後方互換性を使用可能にする方法を提供します。『使用可能にされたサーバーのターゲット・サポートとの後方互換性』 を参照してください。この非互換性の理由は、サーバーのターゲット機能が J2EE プロジェクトの .classpath ファイルを変更してしまい、WebSphere Application Server - Express の以前のバージョンは、新しい .classpath ファイルのエントリーを認識できない ためです。
サーバーのターゲット・サポートを使用可能にしておけば、サーバーのターゲットにされる J2EE プロジェクトは、ターゲット・サーバーを「ターゲット・サーバーの変更 (Modify Target Server)」ダイアログで選択可能な「ターゲット・サーバーを指定しない (No target server specified)」オプションに変更することによって、サーバーのターゲット・サポートを使用しないように戻すことができます。「ターゲット・サーバーの変更 (Modify Target Server)」ダイアログは、「リソース・ナビゲーター (Resource Navigator)」または「J2EE パースペクティブ (J2EE Perspective)」ビューの J2EE プロジェクトのポップアップ・メニューから起動します (「ターゲット・サーバー (Target Server)」>「変更 (Modify)」)。ターゲット・サーバーは、EAR、EJB、アプリケーション・クライアントおよびコネクター・プロジェクトの J2EE プロパティー・ページからでも「ターゲット・サーバーを指定しない (No target server specified)」に変更できます (「プロパティー (Properties)」>「J2EE」)。Web プロジェクトの場合は、ターゲット・サーバー設定は、「Web プロパティー (Web properties)」ページで行います (「プロパティー (Properties)」>「WEB」)。サーバー・ターゲットの変更機能の機能詳細については、 IBM WebSphere Studio Site Developer 資料を参照してください。「ターゲット・サーバーを使用しない (No target server specified)」オプションが使用されていると、.classpath ファイルは、 IBM WebSphere Studio Site Developer の以前のバージョンと互換性のあるスタイルに戻り、.server はプロジェクトから除去されます。
JDK 1.4 での変更により、ユーザーは、IBM WebSphere Studio Site Developer バージョン 5.1.1 で実行するページを生成する「データベース Web ページ (Database Web Pages)」ウィザードおよび「Java Bean Web ページ (Java Bean Web Pages)」ウィザードを使用して、Java パッケージを指定する必要があります。この問題は、View Bean テンプレートが「Java Bean Web ページ (Java Bean Web Pages)」ウィザードまたは IBM データベース・アクセス Java Bean マスター詳細パターンに使用されている場合に発生します。 また、作成中にパッケージを指定せずにこれらのウィザードで以前に生成されたページおよび .java ファイルが含まれるプロジェクトにも適用されます。以前に生成されたコードの場合は、.java ファイルをパッケージに移動します。次に、.jsp ファイルを更新し、インポート・ステートメントおよびクラス情報を更新します。プロジェクトの web.xml ファイルの場合は、サーブレット・クラスのエントリーを更新します。
この章では、以下のマイグレーション・トピックを取り上げます。
IBM WebSphere Studio Site Developer バージョン 5.1.1 は、新規 Eclipse ベース WebSphere Studio Workbench (WSWB) 2.1.2 に基づいています。バージョン 2.1.2 および 2.0.3 または 2.0.2 では、いくつかの相違点があります。この違いの詳細情報については、WS_Installdir¥eclipse¥readme ディレクトリー (ここで WS_Installdir は、 IBM WebSphere Studio Site Developer をインストールしたパス) にある README ファイルを参照してください。
IBM WebSphere Studio Site Developer バージョン 5.0 は、Eclipse ベース WSWB 2.0.2 に基づき、 IBM WebSphere Studio Site Developer バージョン 5.0.1 は、Eclipse ベース WSWB 2.0.3 に基づいていました。バージョン 2.0.2 と 2.0.3 には、大きな違いはありません。 IBM WebSphere Studio Site Developer バージョン 5.0.1 リリースは、 IBM WebSphere Studio Site Developer バージョン 5.0 の先頭にインストールされた更新マネージャーの修正パッケージでした。
既存の IBM WebSphere Studio Site Developer バージョン 5.0 のワークスペースを使用して、 IBM WebSphere Studio Site Developer バージョン 5.1.1 を初めて始動すると、バージョン 5.0 からのマイグレーション方法を示すダイアログ・ボックスが表示されます。「OK」をクリックしてバージョン 5.0 のワークスペースをマイグレーションするか、または「キャンセル (Cancel)」をクリックして IBM WebSphere Studio Site Developer が開始するのを停止します。
ワークスペースをマイグレーションしても、新しいプロジェクト・フィーチャーのメタデータは無視され、バージョン 5.0 で読み取ることができるため、そのワークスペースはバージョン 5.0 で使用できます。メタデータに影響を与えるか、またはプロジェクトの新しいプロジェクト・フィーチャーのメタデータを上書きするようなワークスペース内のプロジェクトに対して、バージョン 5.0 で変更を行うことはできません。
バージョン 5 またはバージョン 5.0.1 からの Java プロジェクトのマイグレーションは単純で自動的です。一度プロジェクトをバージョン 5.1.1 のワークスペースにロードすると、バージョン 5.1.1 の新規フィーチャーを使用しない限り、.classpath ファイルまたは .project ファイルにメタデータの変更は発生しません。
IBM WebSphere Studio Site Developer バージョン 5 および IBM WebSphere Studio Site Developer バージョン 5.1.1 を使用して、チーム・リポジトリー内のプロジェクトが開発者によってロードおよび操作される場合は、特別の管理が必要です。一般的な問題は、ワークスペース内のメタデータの存在、内容、そして解釈が特定のフィーチャーやプラグインに固有なものである場合があり、しかもバージョンごとに異なる点があります。ワークスペースの互換性は、すべての開発者が厳格に管理されたステップでその IBM WebSphere Studio Site Developer ワークスペースをアップグレードする場合にのみ保証されます。そのような場合、共用メタデータで問題は発生しません。しかし、ある開発者が IBM WebSphere Studio Site Developer バージョン 5.1.1 で作業している最中に、別の開発者が IBM WebSphere Studio Site Developer バージョン 5 で作業をした場合は、このような保証はありません。 この章は何をして何をすべきでないかのアドバイスを提供します。
標準的な障害モードは、 IBM WebSphere Studio Site Developer バージョン 5.1.1 ユーザーに通知されます。バージョン 5.1.1 メタデータは、バージョン 5 ユーザーが変更を保管し、そして更新済みのメタデータ・ファイルをリポジトリーにコミットすると失われます。 ここには間違いとなる可能性のあるケースを示します。
ここに、プロジェクトが IBM WebSphere Studio Site Developer バージョン 5.1.1 とバージョン 5 またはバージョン 5.0.1 のユーザーで共用される場合に監視し続ける作業のリストがあります。
このサポートは、 IBM WebSphere Studio Site Developer バージョン 5.1.1 に追加されています。リンクされたリソースについての情報は .project ファイルに記録されます。
推奨事項: 使用しない。 「ワークベンチ (Workbench)」>「リンクされたリソース (Linked Resources)」の設定ページを使用して、リンクされたリソースを使用不可にすることをお勧めします。
外部ツール・ビルダーについての情報は .project ファイルに記録されます。 バージョン 5 とバージョン 5.1.1 の間で変更された情報のフォーマット。バージョン 5.1.1 で作成または変更されたビルダーは、バージョン 5 ワークスペースでは理解されない新規のフォーマットを使います。 バージョン 5 で作成されたビルダーは古いフォーマットを使用し、バージョン 5.1.1 で継続して機能します。
推奨事項: 常にバージョン 5 ワークスペースから外部ツール・ビルダーを作成、または編集する。
追加されたサポート。この情報は .classpath ファイルに記録されます。
推奨事項: 排他パターンを指定しない。「Java」>「コンパイラー (Compiler)」>「ビルド・パス (Build Path)」の設定ページを使用して排他パターンを使用不可にすることをお勧めします。
追加されたサポート。この情報は .classpath ファイルに記録されます。
推奨事項: デフォルト (プロジェクト・ワイド) 出力フォルダー以外は何も指定しない。「Java」>「コンパイラー (Compiler)」>「ビルド・パス (Build Path)」の設定ページを使用して複数出力ロケーションを使用不可にすることをお勧めします。
ソース ZIP ファイルを Java ビルド・パス上の JAR ライブラリーに接続するとき、 ソース・ルート・パスのプレフィックスは自動的に推測されます。これはバージョン 5 から変更された点であり、ユーザー・インターフェースを使用して明示的に設定され、 .classpath ファイルに明示的に記録することができます。 このため、5.1.1 ワークスペースで作成された Java プロジェクトは接続されたソースを検出できない可能性があります。
バージョン 5 を使用してソース接続ルート・パスを指定します。 追加のソース接続の柔軟性がバージョン 5.1.1 で提供されています。 ユーザーはソース接続として JAR ファイルや ZIP ファイルの代わりにフォルダーを提供することができ、 また、ソースをクラス・ファイル・フォルダーに接続することもできます。この機能はバージョン 5 では使用できません (バージョン 5.1.1 情報は無視されるため)。
クラスパス・コンテナーを使用する PDE が追加されています。クラスパス・コンテナーは .classpath ファイルに記録されます。 もし PDE クラスパス・コンテナーが使用されると、そこではバージョン 5 ワークスペースが未解決のクラスパス項目を持つことになり、その結果大部分の Java の能力 (コンパイル、検索、実行、デバッグを含む) が期待通りの結果を生まないことになります。
推奨事項: クラスパス・コンテナーを使用するための「プラグインの開発 (Plug-in Development)」>「Java ビルド・パス・コントロール (Java Build Path Control)」 の設定ページ上の設定が、どの新規プラグイン (またはフラグメント) プロジェクトを作成する前にも、使用不可になっているようにする。
フォルダー名は「Java ソース (Java Source)」および「Web コンテンツ (Web Content)」です。新規 Web プロジェクト用のデフォルトのフォルダー名は、設定ページ (「ウィンドウ (Window)」>「設定 (Preferences)」>「Web ツール (Web Tools)」>「新規プロジェクト (New Project)」) を介して構成できます。 デフォルトの名前は、JavaSource と WebContent になりました。 デフォルト名は新規の Web プロジェクトのみに使用されます。このリリースより以前のバージョンで作成された Web プロジェクトは、古い名前のままで継続して機能します。 同じことが静的 Web プロジェクトについても言えます。
ユーザーが 4.0.x と 5.0 のプロジェクトのソース・フォルダー名をバージョン 5.1.1 で変更したいときは、ナビゲーター・ビューの「名前変更 (Rename)」ポップアップ・メニュー・アクションを使用します。「名前変更 (Rename)」 ポップアップ・メニュー・アクションはフォルダー名を名前変更し、 4.0.x と 5.0 Web プロジェクトへの Java ビルド・パスを修正します。
JavaSource フォルダーの場合、「名前変更 (Rename)」ポップアップ・メニュー・アクションは 「プロジェクト・ナビゲーター (Project Navigator)」ビューと「パッケージ (Packages)」ビューで作動します。WebContent フォルダーの場合は、「名前変更 (Rename)」ポップアップ・メニュー・アクションは「リソース・ナビゲーター (Resource Navigator)」ビューと「プロジェクト・ナビゲーター (Project Navigator)」ビューで作動します。
このリリースより以前のバージョンの Web プロジェクトを SCM リポジトリーに保管してからこのリリースにロードすると、ソース・フォルダーと webApplication フォルダーを持つ古い構造が保持されます。 どちらの構造も正しくビルドされます。
Struts ツール・ランタイムが、バージョン 5 内の時のバージョン 1.1 ベータ 2 からバージョン 1.1 にステップアップされました。 IBM WebSphere Studio Site Developer バージョン 5 (一般出荷版) では、ユーザーが Web プロジェクトを作成する際に、ユーザーのプロジェクトに Struts のサポートを追加するオプションが加えられました。ユーザーは Struts 1.0.2 または Struts 1.1 ベータ 2 のどちらかを選択できます。 IBM WebSphere Studio Site Developer バージョン 5.1.1 では、後者の選択は Struts 1.1 に置き換えられています。 IBM WebSphere Studio Site Developer バージョン 5 で Struts 1.1 ベータ 2 Web プロジェクトを作成した場合、そのプロジェクトを Struts 1.1 に変換することをお望みになるかもしれませんが、 Struts 1.1 ベータ 2 はまだサポートされているため、その必要はありません。もしユーザーが Struts 1.1 ベータ 2 Web プロジェクトをお持ちで、Struts 1.1 への変換をお望みの場合は以下を行ってください。
上記のすべての情報は、ユーザーが Struts 1.1 Beta 3 Web プロジェクトを IBM WebSphere Studio Site Developer バージョン 5.0.1 内から Struts 1.1 へ移動する場合に適用されます。
Web サービス・ツールに 2 つの新規 IBM WebSphere Application Server バージョン 5.0.2 ランタイム・プロトコルが追加されました。これは WebSphere Application Server バージョン 5.0.2 のみで実行されます。 IBM WebSphere Studio Site Developer バージョン 5.1.1 以降の必須のマイグレーションではなく、WebSphere Application Server バージョン 5.0.2 は新旧両方のランタイム・プロトコルをサポートします。 IBM WebSphere Studio Site Developer は、Web サービス成果物の 3 つのランタイム・プロトコルを生成およびデプロイします。すなわち、WebSphere Application Server バージョン 4.x およびバージョン 5.x で実行される古い "IBM SOAP" ランタイム・プロトコル、WebSphere Application Server バージョン 5.0.2 のみで実行される新しい "IBM WebSphere 5.0.2 runtime" ランタイム・プロトコル、そして WebSphere Application Server バージョン 5.0.2 のみで実行される新しい "Apache Axis 1.0" ランタイム・プロトコルです。
ユーザーはバージョン 5 プロジェクトと Web サービスに関連した EAR および WAR ファイルを、バージョン 5.1.1 で変更なしに再使用できるはずです。 Web サービスとクライアントを新規の IBM WebSphere 5.0.2 ランタイム・プロトコルに変換して、JSR 101、109、WS-I および WS-Security 標準を利用するためには、Web サービス・ウィザードを使用して再生成する必要があります。 物理的データ・ファイルは自動的に新規のロケーションに 移動しますが、Web サービス・エクスプローラーは、ユーザーの好みも継続して自動的に読みとります。
ワークスペースをバージョン 5 からマイグレーションするとき、「ワークベンチの復元で問題が発生しました (Problems occurred restoring workbench)」というポップアップ・エラー・メッセージを受けとります。このメッセージは、プロファイル・パースペクティブがマイグレーションの時点でオープンされていて、ヒープまたはインスタンス統計ビューがプロファイル・パースペクティブで可視の場合に現れます。これは、バージョン 5 で存在していた「ヒープ (Heap)」ビューも「インスタンス統計 (Instance Statistic)」ビューも除去されているからです。このメッセージは、プロファイル・パースペクティブがマイグレーションの時点でワークスペース内にオープンされている場合にも現れます。このエラー・メッセージは 「OK」をクリックして無視しても安全です。
バージョン 5 で作成されたカスタマイズしたテンプレートを使用するためには、 ユーザーはカスタマイズしたテンプレートをロードし、それをデータベースに再接続して 保管する必要があります。 次回、ユーザーが保管したカスタマイズされたテンプレートを再ロードすると接続が検査されます。
このリリースで作成された生成済みの J2EE 1.2 成果物は、 IBM WebSphere Studio Site Developer バージョン 4.0.3 では読み取れない可能性がありますが、バージョン 4.0.3 テスト環境では実行されます。バージョン 4.0.3 ではテンプレート・ウィザードが入っていなかったので、 そのバージョンへの後方互換性は維持されません。
Web プロジェクト設定で Java ソース・フォルダーが「Java Source」と名付けられ、Web コンテンツ・フォルダーが「Web Content」と名付けられると、 このリリースで生成されたテンプレート・アプリケーションをバージョン 5 で実行できます。
この章では、 IBM WebSphere Studio Site Developer バージョン 4.0.x から バージョン 5 へのマイグレーションについて説明します。
プロジェクトを IBM WebSphere Studio Site Developer バージョン 4.0.x から バージョン 5 へマイグレーションするために使用できるメソッドが、2 つ用意されています。
バージョン 4 からバージョン 5 へのマイグレーションは、 バージョン 5 が WebSphere Application Server バージョン 4 へまだビルドおよびデプロイできるため、 プロジェクト J2EE レベルを自動的には変更しません。 Web プロジェクトを含むすべての J2EE プロジェクト・タイプは、 IBM WebSphere Studio Site Developer で 使用可能な J2EE マイグレーション・ウィザードを使ってマイグレーションすることができます。 J2EE マイグレーション・ウィザードにアクセスするためには、J2EE タイプ・プロジェクトを右マウス・ボタンでクリックし、 次に「マイグレーション (Migrate)」 >「J2EE マイグレーション・ウィザード (J2EE Migration Wizard)」 を選択します。
以下は、バージョン 4.0.x 以降に行われた機能拡張の一部をリストしたものです。
WebSphere InfoCenter [www.ibm.com/software/webservers/appserv/doc/v40/aes/infocenter/index.html] には、 以下の情報があります。
「Migrating to WebSphere V5.0 An End-to-End Migration Guide」はバージョン 3.5 およびバージョン 4.0 からバージョン 5.0 へマイグレーションするための良い情報源です [www.redbooks.ibm.com/pubs/pdfs/redbooks/sg246910.pdf]。
WebSphere Application Server のダウンロード・ページ [www14.software.ibm.com/webapp/download/product.jsp?s=p&id=TDUN-49EVRT&type =s&dt=DIAGNOSTIC+TOOL] には、ユーザーのアプリケーションの変換を支援するツールがあります。
プロジェクトが循環依存関係を持っていれば、バージョン 5 はビルド・エラーを報告します。「ウィンドウ (Window)」>「設定 (Preferences)」>「Java」>「コンパイラー (Compiler)」 とすすみ、「ビルド・パス (Build Path)」タブを選択して、「ビルド・パス・エラーでビルドの打ち切り (Abort building on build path errors)」チェック・ボックスを選択解除できます。 これにより以降はビルドが停止されることはなく、「タスク (Task)」ビューに 1 つまたは複数のビルドの「循環依存関係 (circular dependency)」エラーが (ビルドがそれ以外の点で正常な状態であっても) 依然として表示されるので、注意してください。この場合、ユーザーは、「その他 (Other)」タブを使ってこれらの「エラー (errors)」を「注意 (warnings)」に変更し、その後 「循環依存 (Circular Dependencies)」ドロップダウンの設定を変更することが可能です。
IBM WebSphere Studio Site Developer バージョン 5 では、バージョン 4.0.3 から内部プロジェクト構造が 変更されています。バージョン 5 J2EE 1.2 Web WAR は、Java ソースと一緒にエクスポートされる ときに、 IBM WebSphere Studio Site Developer バージョン 4 にインポートされ、ソース・コード・フォルダーは自動的に正しい名前に 変換され、ビルドも正常に行われます。バージョン 4 プロジェクトがバージョン 5 にインポートされるとき、ソース・コード・フォルダーは自動的に正しい名前に変換されるため、Web プロジェクトは依然として WebSphere Application Server バージョン 4 上で正しく同様に実行されます。 フォルダー名の変更について詳しくは、『IBM WebSphere Studio Site Developer の Web プロジェクトの構造』を参照してください。
IBM WebSphere Studio Site Developer バージョン 5 の Web プロジェクトの内部構造は、 以前の IBM WebSphere Studio Site Developer バージョン 4.0.x の場合とは異なります。 この違いは、J2EE 1.2 と J2EE 1.3 の違いとは関係なく、むしろツールの使いやすさの違いによるものです。
バージョン 4 では、Web プロジェクトはデフォルトで 動的 Web プロジェクトであって、「ナビゲーター (Navigator)」ビューに「ソース (source)」フォルダーおよび「webApplication」フォルダーを持つ形で表示されました。 バージョン 5 では、動的 Web プロジェクトを作成すると、 「ソース (source)」フォルダー ではなく「Java ソース (Java Source)」フォルダーに、 「webApplication」フォルダーではなく「Web コンテンツ (Web Content)」フォルダーに表示されます。
しかし、バージョン 4 の Web プロジェクトを SCM リポジトリーに保管してからバージョン 5 にロードすると、 「ソース (source)」フォルダーと「webApplication」フォルダーを持つ古い構造のまま表示されます。 どちらの構造もバージョン 5 で正しくビルドされます。
バージョン 5 では、動的 Web プロジェクトだけでなく静的プロジェクトも作成することができます。
静的 Web プロジェクトは、HTML、Java スクリプト、イメージ、テキストなどの静的リソースのみを含み、動的コンテンツを含みません。静的 Web プロジェクトは従来の HTTP Web サーバー上で実行され、サービスを受けていて Web アプリケーション・サーバーを必要としません。
動的 Web プロジェクトは静的リソースのほかに、サーブレット、JSP、フィルター、関連付けられたメタデータのような動的 J2EE リソースを含みます。 動的 Web プロジェクトを作成する場合、豊富なプロジェクト・リソースのセットを用いて開発を始められるように、カスケード・スタイル・シートと JSP タグ・ライブラリーを組み込むことができます。動的 Web プロジェクトはいつも Enterprise Application プロジェクトに組み込まれていて、Web Application Servers 上でのみ実行されます。
ワークスペースをバージョン 4.0.x から IBM WebSphere Studio Site Developer バージョン 5 へ 移動する場合は、この方法の使用をお勧めします。これがプロジェクト・ビルド・パスの情報を含む、 すべての情報をマイグレーションするための唯一の方法です。
ヒント: バージョン 4 では、ワークスペース・ディレクトリーが、デフォルトで、 インストール・ディレクトリーに入っていました。 バージョン 5 では、このデフォルトが、 「My Documents」ディレクトリー内の、「ワークスペース」と呼ばれるディレクトリーに変わりました。 作業を保管するロケーションをオーバーライドしたい場合は、ワークベンチを始動するときに、 コマンドの -data オプションを使用します。
ClearCase の場合: クリーンなバージョン 5 ワークスペースを使用して、各プロジェクトにロードするため、 「ファイル (File)」>「インポート (Import)」>「現在の WebSphere Studio 4.x ClearCase プロジェクトをワークスペースへ (Existing WebSphere Studio 4.x ClearCase Project into Workspace)」を選択する。
マイグレーション後の考慮事項:
The project was not built since it is involved in a cycle or has classpath problems. Missing required source folder: /MyHomePageExample403/source.
バージョン 4 EAR IBM アプリケーション拡張機能ファイルとサーバー構成ファイルは絶対パス参照を含んでいました。 それらをバージョン 5 へマイグレーションしてから、バージョン 5 のエディターで開く必要があります (エディターは絶対パス参照を新しい相対参照へ自動的に変更します)。
The IBM extensions file contains deprecated absolute paths. This can be auto-corrected and should be saved. This will remove the paths from the file, and only needs to be done once. Would you like to autocorrect?
IBM WebSphere Studio Site Developer の SCM プラグインを提供している SCM ベンダーは他にも何社かあります。www.ibm.com/software/ad/studioappdev/partners/scm.htmlのベンダー・リストを参照してください。 バージョン 4 プラグインを提供していたすべての SCM ベンダーは、それぞれの Ready for IBM WebSphere Studio software [www.developer.ibm.com/websphere/ready.html] 検証の一部として、従来のマイグレーション・ステップ (バージョン 4 から SCM リポジトリーへの保管、リポジトリーからバージョン 5 へのロード) がそれぞれのシステムでも機能することを確認します。
このアプローチは部分的にしかサポートされておらず、マイグレーションは不完全です。 ユーザー・インターフェース設定、デバッグ設定、およびほとんどの設定がすべて消失します。 プロジェクト名、プロジェクト・ソース・ファイル、 およびプロジェクト Java ビルド・パス (クラスパス) は保存されますが、 それ以外のものはすべて保証されません。このアプローチを使用するのは、SCM をサポートしていないシステムを使用している場合や、 プロジェクト・ビルド・パス情報の保存が不可欠な場合、つまり、 バージョン 4 からエクスポートしたプロジェクトをインポートするとそれらの情報が消失する場合に限ってください。 次の方法により、既存のバージョン 4.0.x のワークスペースを使用することができます。
EAR およびサーバー構成の絶対パス参照のマイグレーション後の除去で説明したマイグレーション後の指示がここでも適用されます。
IBM WebSphere Studio Site Developer バージョン 5 で バージョン 4.0 のワークスペースを開いてマイグレーションしようとすると、 次のような問題が発生することがあります。
JRE_LIB クラスパス変数を有効なロケーションに設定し直すには、以下のステップを実行します。「設定 (Preferences)」ウィンドウを最初に開くときは、値が正しいように見える場合であっても、この操作を実行してください。
この操作を行わないと、JRE_LIB の値が正しくなくなり、 Java ファイルに多くのビルド・エラーを生じさせる原因になる可能性があります。
一般的な検査として、他のすべてのクラスパス変数の値を調べてください。
Eclipse 1.0 と 2.0 の間で、チーム・サポートが大幅に変更されました。 プロジェクトをリポジトリーと共用する方式も変更されました。
デフォルトでは、プロジェクトはワークスペース・ディレクトリーに作成されます。 このデフォルトをオーバーライドしてプロジェクトを別の場所に作成する場合は、 ワークベンチを閉じる前にすべてのプロジェクトを開く必要があります。これにより、 そのプロジェクトの .project ファイルが適切なロケーションに書き込まれます。 ディレクトリーがワークスペースの外側にある閉じたプロジェクトを開くことができないと、 実際のプロジェクトをマスクするプロジェクトが作成され、そこには .project ファイルしか入りません。
現在設定されているすべての JSP ブレークポイントを除去して、 それらをマイグレーション済みバージョン 5 ワークスペース内に再設定する必要があります。
IBM WebSphere Studio Site Developer 4.0.3 のプロジェクトからリレーショナル・データをマイグレーションするには、以下のようにします。
リレーショナル・データの成果物が復元されます。
4.0.x から Web サービス・ファイルをインポートすると、以下のエラー・メッセージを受け取る場合があります。
Error The part 'result' has an invalid value 'anyElement' defined for its type. Type declarations must refer to valid values defined in a schema. Error The part 'return' has an invalid value 'findPatientResult' defined for its element. Element declarations must refer to valid values defined in a schema. Error The part 'response' has an invalid value 'findPatientResponse' defined for its element. Element declarations must refer to valid values defined in a schema.
このエラーの対応策は、以下のとおりです。
バージョン 5 の J2EE マイグレーション・ウィザードにアクセスするには以下のステップに従ってください。
この章では、WebSphere Studio バージョン 4.0 (アドバンスト版とプロフェッショナル版の両方) から IBM WebSphere Studio Site Developer にマイグレーションする方法を説明します。WebSphere Studio "Classic" バージョン 4.0 から IBM WebSphere Studio Site Developer バージョン 5.0 へのマイグレーションは、以下のステップから成っています。
WebSphere Studio "Classic" の拡張公開フィーチャー (ファイルを公開ステージにマップする機能) および Page Detailer フィーチャー (Web ページの分析) は IBM WebSphere Studio Site Developer では使用できません。 バージョン 4.0.x CD メディア・パックのその他のフィーチャーの一部も使用できません。 たとえば、Web ページを分析する Page Detailer フィーチャー、リッチ・メディア・タイプ用の HotMedia(R) フィーチャー、Voice XML エディター (WebSphere Everyplace(TM) ツールキットとポータル・ツールキットへ移されました)、パーベイシブ・デバイス用の DataBaseWizard がその例です。
WebSphere Studio のデータをマイグレーションする場合は、以下の制限事項に注意してください。
以下に説明するマイグレーション・プロセス中に、WebSphere Studio は、シングル・サーバー用のすべてのプロジェクト・ファイル (公開可能なものとソース) を収めた JAR ファイルを作成します。 「公開中 (Publishing)」ビューに表示される、デフォルト・サーバーのファイルはすべて、JAR ファイルにパッケージされます。 JAR ファイルは IBM WebSphere Studio Site Developer にインポートできます。
既存のプロジェクトをマイグレーションする場合、プロジェクトの公開情報とステージ情報は、すべてマイグレーション時に消失します。 ステージが複数のサーバーにまたがる場合は、デフォルト・サーバーに公開されるファイルしか保存されません。 したがって、マイグレーション用として、サーバーが 1 つだけの新しいステージを作成します。
現行のステージに複数のサーバーがある場合は、以下のステップを実行して、1 つのサーバーのみの「Migration」という新しいステージを作成します。
デフォルトの Web 構成記述子ファイル名は serverName_web.xml です。 ここでは、localhost_web.xml になります。 別のロケーションを指定しない限り、.xml ファイルは WEB-INF ディレクトリーに保管されます。
アプリケーションをテストする準備が整いました。 デフォルトのテスト・サーバーでアプリケーションをテストする場合は、以下のステップを実行してください。
デフォルト以外のサーバーランタイム環境でアプリケーションをテストする場合は、 オンライン・ヘルプで「サーバー・ツール (Server Tools)」フィーチャーを参照してください。
この章では、VisualAge(R) for Java プロフェッショナル版または VisualAge for Java エンタープライズ版を IBM WebSphere Studio Site Developer にマイグレーションする方法を説明します。
IBM のビジネス・パートナーである Instantiations, Inc. が配布している CodePro Studio という製品には、マイグレーション機能および共存機能があり、VisualAge for Java と WebSphere Application Server - Express の生産性を向上させます。
VisualAge for Java のユーザーがマイグレーションを開始できるように、Instantiations は、無料で利用制限のない VisualAge for Java を IBM WebSphere Studio Site Developer エクスポート機能に CodePro Studio の期間限定評価版の一部として提供しています。評価版は、www.instantiations.com/vaj-migrate. からダウンロードできます。
ファイルの完全双方向エクスポート/インポート、エクスポート/インポート・セットの作成、プロジェクトの同期化、
タスクの自動化など、インスタンス化の拡張マイグレーションと共存サポートの詳細については、
Instantiations, Inc. の Web ページ
www.instantiations.com/codepro/ws を参照してください。
以下に、VisualAge for Java からの変更点の一部をリストします。
以下のステップは、VisualAge for Java からマイグレーションする方法を示したものです。 その後で、それぞれのステップの実行方法を詳しく説明します。
VisualAge for Java リポジトリーからバージョン管理されたプロジェクトやリソースを 「まとめて」マイグレーションする方法はサポートされていません。VisualAge for Java ワークスペースにあるプロジェクトとリソースだけをマイグレーションできます。 バージョン管理されたプロジェクトやリソースは、まず VisualAge for Java ワークスペースに移動してから IBM WebSphere Studio Site Developer にマイグレーションする必要があります。
プロジェクトを JAR ファイルにエクスポートする場合は、以下のステップを実行してください。
IBM WebSphere Studio Site Developer を始動し、所要のプロジェクトを作成します。以下は、ファイルのインポート先となる IBM WebSphere Studio Site Developer プロジェクトの種類を決める場合に役立つ、一般的なマイグレーション・ガイドラインです。
アプリケーションでサーブレットを使用している場合は、web.xml ファイルでサーブレットと URL のマッピングを定義する必要があります。 以下のステップを実行してください。
以下の VisualAge for Java 設定を書き留め、 IBM WebSphere Studio Site Developer で設定してください。
プロジェクトのクラスパス
VisualAge for Java では、 「オプション (Options)」ウィンドウの「リソース (Resources)」ページ (「ウィンドウ (Window)」>「オプション (Options)」>「リソース (Resources)」) で、プロジェクトのクラスパスを設定します。プロジェクトを IBM WebSphere Studio Site Developer にマイグレーションした後でプロジェクトのクラスパスを設定するには、プロジェクトの「プロパティー (Properties)」ウィンドウを使用します (プロジェクトを右マウス・ボタンでクリックして、「プロパティー (Properties)」>「Java ビルド・パス (Java Build Path)」を選択します)。 「ライブラリー (Libraries)」タブをクリックします。 また、「設定 (Preferences)」ウィンドウでクラスパスの変数を設定することもできます (「ウィンドウ (Window)」>「設定 (Preferences)」>「Java」>「クラスパス変数 (Classpath Variables)」)。
リソース関連
ファイル・タイプと実行可能プログラムとの関連をセットアップすれば、 ワークベンチの外側にあるファイルをワークベンチの中から開くことができます。
VisualAge for Java では、「オプション (Options)」ウィンドウでリソース関連をセットアップします (「ウィンドウ (Window)」>「オプション (Options)」>「リソース (Resources)」>「リソース関連 (Resource Associations)」)。 リソース・ファイルを IBM WebSphere Studio Site Developer にマイグレーションした後にリソース関連をセットアップするには、「設定 (Preferences)」ウィンドウを使用します (「ウィンドウ (Window)」>「設定 (Preferences)」>「ワークベンチ (Workbench)」>「ファイル関連 (File Associations)」)。
コード・フォーマッター
VisualAge for Java では、「オプション (Options)」ウィンドウの「フォーマッター (Formatter)」ページで、コードのフォーマット・オプションをセットアップします (「ウィンドウ (Window)」>「オプション (Options)」>「コーディング (Coding)」>「フォーマッター (Formatter)」)。 コードを IBM WebSphere Studio Site Developer にマイグレーションした後にコードのフォーマット設定をセットアップするには、「設定 (Preferences)」ウィンドウを使用します (「ウィンドウ (Window)」>「設定 (Preferences)」>「Java」>「コード・フォーマッター (Code Formatter)」)。
WTE の構成
VisualAge for Java では、WebSphere 単体テスト環境と WebSphere Application Server ランタイムの設定は、VisualAgeInstalldir¥ide¥project_resources¥IBM WebSphere Test Environment¥properties ディレクトリー (VisualAgeInstalldir は、製品のインストール・ディレクトリー) の下のさまざまなプロパティー・ファイルに入っています。
例えば、session.xml プロパティー・ファイルで、<url-rewriting-enabled>true</url-rewriting-enabled> のようにプロパティーを true に変更して URL 再書き込みを使用可能にした場合、IBM WebSphere Studio Site Developer バージョン 4.0 テスト環境で、このプロパティーを構成できます。 (「サーバー (Server)」パースペクティブで、「サーバー構成 (Server Configuration)」ビューを開き、 利用したいサーバーを右マウス・ボタンでクリックし、「開く(Open)」 をクリックする。 「Web」タブをクリックして、「URL 再書き込みを使用可能にする (Enable URL rewrite)」チェック・ボックスを選択する。)
Java ファイルおよびプロジェクト・リソース・ファイル
プロパティー・ファイル default.servlet_engine には、 VisualAge for Java Web アプリケーションの <root-uri> コンテキスト・ルートが入っています。 IBM WebSphere Studio Site Developer で Web プロジェクトを作成する場合、「Web プロジェクトの作成 (Create a Web Project)」ダイアログに、このデータの「コンテキスト・ルート (Context root)」フィールドがあります。
ユーザーが自らカスタマイズした、VisualAgeInstalldir ¥ide¥project_resources¥IBM WebSphere Test Environment¥hosts¥default_host¥default_app¥servlets¥default_app.webapp などのファイル内の Web アプリケーション設定は、 IBM WebSphere Studio Site Developer 内の your_Web_project¥Web Content¥WEB-INF¥web.xml ファイルにマイグレーションする必要があります。例えば、default_app.webapp ファイルでサーブレット名とサーブレット・パスを変更した場合は、web.xml ファイルでも対応する変更を行います。
アプリケーションが Java プロジェクトの場合は、Java プロジェクトに対する標準の IBM WebSphere Studio Site Developer の実行 (Run) サポートまたはデバッグ (Debug) サポートだけを使用してそのアプリケーションをテストします。
アプリケーションが WebSphere Application Server を使用している場合は、組み込み WebSphere Application Server を使用してそのアプリケーションをテストします。 このためには、デフォルトのテスト・サーバーを作成して、始動する必要があります。 Web プロジェクトの場合は、メイン HTML ページを右マウス・ボタンでクリックし、 「サーバーで実行 (Run on Server)」を選択して、Web ブラウザーを起動します。
その他のタイプのプロジェクトのテスト方法については、オンライン・ヘルプを参照してください。
WebSphere Application Server をランタイム環境として使用している場合は、 IBM WebSphere Studio Site Developerの「サーバー・ツール (Server Tool)」フィーチャーを使用してアプリケーションをデプロイします。
IBM WebSphere Studio Site Developer プロジェクト (およびその関連する設定) は、開発者間で共用することができます。このためには、プロジェクトを IBM WebSphere Studio Site Developer のソフトウェア構成管理 (SCM) サーバーに保管してから、 IBM WebSphere Studio Site Developer の別のチーム・メンバーに取り出します。
IBM WebSphere Studio Site Developer バージョン 4.0 のチーム・サポートについては、www.ibm.com/websphere/developer/library/techarticles/0108_karasiuk/0108_karasiuk.htmlを参照してください。
また、 IBM WebSphere Studio Site Developer のチーム・サポートについては、「インストール・ガイド」やオンライン・ヘルプも参考になります。
この章では、VisualAge for Java の Visual Composition Editor フィーチャーで作成したアプリケーションを WebSphere Application Server - Express の Visual Editor for Java にマイグレーションする方法を説明します。
このステップはオプションですが以下の理由のため、(特に、アプリケーションが接続されている場合は) 強くお勧めします。
マイグレーションの前に拡張メタデータ情報を保管する方法:
これで、クラスを WebSphere Application Server - Express にインポートできる状態になりました。 前出の『第 7 章 VisualAge for Java から IBM WebSphere Studio Site Developer へのマイグレーション』を参照してください。 従来の Visual Composition Editor ソース・プログラムを WebSphere Application Server - Express にインポートしておけば、それらを Visual Editor for Java で保守することができます。
この章では、以下のマイグレーション・トピックを取り上げます。
関連事項の詳細については、J2EE クラス・ロードに関する資料 (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer.html) (J2EE モジュールとクラスパス)、および J2EE ユーティリティー JAR の開発に関する資料 (www.ibm.com/websphere/developer/library/techarticles/0112_deboer/deboer2.html) (J2EE モジュールの Java JAR) を参照してください。これらの資料は、詳細な技術的なバックグラウンドとアドバイスを提供します。
サード・パーティーの JAR ファイルを Web プロジェクト内で使用する場合は、 そのファイルを (JAR ファイルのまま) Web プロジェクトのライブラリー・フォルダーにインポートすることをお勧めします。 これは、JAR ファイルを手軽に使用する場合の、J2EE で定義された移植可能な唯一の方法であり、 別のサーバーにデプロイする場合に変更を加える必要がありません。
単一の Web プロジェクトで外部 JAR ファイルを使用するには、以下のステップを実行します。 JAR ファイルを複数の Web プロジェクトで使用する必要がある場合は、代わりに、『複数の Web プロジェクトでサード・パーティー JAR を使用するための推奨される方法』で説明しているステップを実行してください。
サード・パーティーの JAR を複数の Web プロジェクトで使用する場合は、 そのファイルを (JAR ファイルのまま) エンタープライズ・アプリケーション (EAR) プロジェクトにインポートすることをお勧めします。 これは、JAR ファイルを手軽に使用する場合の、J2EE で定義された移植可能な唯一の方法であり、 別のサーバーにデプロイする場合に変更を加える必要がありません。
外部 JAR ファイルを複数の Web プロジェクトで使用するには、 以下のステップを実行します。 JAR ファイルを単一の Web プロジェクトでしか使用する必要がない場合は、前のセクションのステップを実行します。
JAR ファイルを WebSphere Application Server - Express の外部に残したまま、 Java ビルド・パスとサーバー・インスタンスのクラスパスの両方に追加することもできます。 この方法を取ると、アプリケーションを簡単に移植できなくなるため、お勧めしません。 別のサーバーに移動した場合、そのサーバーのクラスパスを必ず更新しなければなりません。 また、クラス・ファイルが、 すでにそのサーバーのクラスパスに入っている (かつ、サーバーまたは他のアプリケーションに必要な) 他のバージョンの同様なクラス・ファイルと矛盾していないことも確認しなければなりません。 このアプローチをとる場合は、以下のステップを実行します。
WebSphere Application Server - Express の強力な自動ビルド・フィーチャーは、 複雑なマルチプロジェクト・ビルドでは、ビルド・パフォーマンスを低下させる可能性があります。 これらの自動ビルドを制御するにはいくつかの方法がありますが (例えば、従属ファイル、 アクティブおよび非アクティブ・プロジェクト、ソースまたは JAR フォーマットのプロジェクトなど)、 これらのオプションは非常に複雑なものになる可能性があります。 これらのオプションとビルド・パフォーマンスの最適化について説明した資料があります。 WebSphere Developer Domain の記事『Optimizing Multi-Project Builds in WebSphere Studio Application Developer』(www.ibm.com/websphere/developer/library/techarticles/0204_searle/searle.html) を参照してください。
Ant を WebSphere Application Server - Express で使用して実動ビルドを自動化することができます。 以下のことを説明した複数のセクションからなる資料があります。
WebSphere Developer Domain の記事『Using Ant with WebSphere Studio Application Developer』(www.ibm.com/websphere/developer/library/techarticles/0203_searle/searle1.html) を参照してください。
この章では、VisualAge for Java および WebSphere Studio "Classic" から WebSphere Application Server - Express IBM WebSphere Studio Site Developer へのマイグレーションの学習に役立つマイグレーションの例を紹介します。
説明
これは、VisualAge for Java バージョン 4.0 に付属の FindTheLeapYears というサンプルです。 詳細については、VisualAge for Java のオンライン・ヘルプ (「サンプル (Samples)」>「JSP/Servlet 開発環境 (JSP/Servlet Development Environment)」) を参照してください。
マイグレーションの概説
以下の手順に従って、VisualAge for Java から IBM WebSphere Studio Site Developer にサンプルをマイグレーションします。各ステップについては以降で詳しく説明します。
以下のステップを実行して、Java ソース・ファイルを LeapYear プロジェクト・ソース・ディレクトリーにインポートします。
以下のステップを実行して、リソース・ファイルを「WebContent」ディレクトリー下の 「LeapYear」プロジェクトにインポートする。
ソース/アプリケーション構造が若干変更されているので、アプリケーションに変更を加える必要があります。
これで、サンプルは IBM WebSphere Studio Site Developer にマイグレーションされました。あとは、 IBM WebSphere Studio Site Developer サーバー・プロジェクトを作成して、サンプルを WebSphere テスト環境でテストするだけです。
次に、サーバー構成に対して EAR プロジェクトを指定する必要があります。
説明
この例では、WebSphere Studio "Classic" バージョン 4.0.x を使用しなければなりません。
これから使用するサンプルは、YourCo サンプルです。 このサンプルにアクセスするには、オンライン・ヘルプを開きます (「ヘルプ (Help)」>「WebSphere Studio 4.0」>「方法 (How to)」>「サンプルの使用 (Work with the samples)」>「概要 (Overview)」)。 このサンプルをロードするには、「Studio サンプルを開く (Opening the Studio Samples)」 (WebSphere Application Server 4.0 用) に記載されている指示に従って、YourCo.war をロードします。
始める前に
マイグレーションのステップ
WebSphere Studio "Classic" から IBM WebSphere Studio Site Developer にサンプルをマイグレーションするには、以下のステップを実行してください。 各ステップについては以降で詳しく説明します。
(オプション) 通常は、マイグレーション用の新しいステージを作成しますが、 この例では、WebSphere Studio "Classic" に用意されているテスト・ステージを使用します。 テスト・ステージを使用すれば、 ステップ 8 で多くのサーブレット・マッピングを手動で編集しなければならない手間を省くことができます。
マイグレーション用の新しいステージの作成方法については、 『WebSphere Studio "Classic" から IBM WebSphere Studio Site Developer へのマイグレーション』を参照してください。
a. com.ibm.db requires databeans.jar, b. com.ibm.webtools.runtime requires webtlsrn.jar, c. com.ibm.ejs.ns.jndi requires ns.jar, d. com.ibm.webshpere.advanced.cm.factory requires cm.jar, e. com.ibm.ejs.models.base.extensions.webappext.ServletExtensions requires ws-base-extensions.jar
これを修正するには、Web プロジェクトの Java ビルド・パスを変更しなければなりません。
これで、サンプルは IBM WebSphere Studio Site Developer にマイグレーションされました。あとは、 IBM WebSphere Studio Site Developer サーバー・プロジェクトを作成して、サンプルを WebSphere テスト環境でテストするだけです。
次に、サーバー構成に対して EAR プロジェクトを指定する必要があります。
マイグレーションおよびその他のトピックに関する最新の情報が、 www.ibm.com/websphere/developer/zones/studio/transition.html から入手できます。
WebSphere Application Server - Express を利用するときに役立つ一般情報については、 以下の資料および Web ページを参照してください。
その他、次のような資料も参考になります。
本書は米国 IBM が提供する製品およびサービスについて作成したものであり、 本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。 日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。 本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、または サービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の 製品、プログラム、またはサービスを使用することができます。 ただし、IBM 以外の製品とプログラムの操作またはサービスの 評価および検証は、お客様の責任で行っていただきます。
IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。 本書の提供は、お客様にこれらの特許権について 実施権を許諾することを意味するものではありません。 実施権についてのお問い合わせは、書面にて下記宛先にお送りください。
〒106-0032
東京都港区六本木 3-2-31
IBM World Trade Asia Corporation
Licensing
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、 自ら適切と信ずる方法で、使用もしくは配布することができるものとします。
以下の保証は、国または地域の法律に沿わない場合は、適用されません。 IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。 国または地域によっては、法律の強行規定により、保証責任の制限が 禁じられる場合、強行規定の制限を受けるものとします。
この情報には、技術的に不適切な記述や誤植を含む場合があります。 本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、 改良または変更を行うことがあります。
本プログラムのライセンス保持者で、(i) 独自に作成したプログラムと その他のプログラム（本プログラムを含む）との間での情報交換、 および (ii) 交換された情報の相互利用を可能にすることを目的として、 本プログラムに関する情報を必要とする方は、下記に連絡してください。
Lab Director
IBM Canada Ltd. Laboratory
8200 Warden Avenue
Markham, Ontario, Canada L6G 1C7
本プログラムに関する上記の情報は、適切な使用条件の下で使用すること ができますが、有償の場合もあります。
本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約 の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。
IBM 以外の製品に関する情報は、その製品の供給者、出版物、 もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、 他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。
本書において IBM 以外の Web サイトに言及している場合がありますが、 便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものでは ありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部では ありません。それらの Web サイトは、お客様の責任でご使用ください。
本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。 より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。 これらの名称はすべて架空のものであり、 名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。
著作権使用許諾:
本書には、様々なオペレーティング・プラットフォームでの プログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・ プラットフォームのアプリケーション・プログラミング・インターフェースに 準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、 いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、 配布することができます。 このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。 従って IBM は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性が あることをほのめかしたり、保証することはできません。 お客様は、IBM のアプリケーション・プログラミング・インターフェースに準拠した アプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、 IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。
それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生的創作物にも、次の ように、著作権表示を入れていただく必要があります。
(C) (お客様の会社名) (年). このコードの一部は、IBM Corp. のサンプル・プログラムから取られています。 (C) Copyright IBM Corp. 2000, 2003. All rights reserved. (C) Copyright IBM Japan 2003.
プログラミング・インターフェース情報は、プログラムを使用して アプリケーション・ソフトウェアを作成する際に役立ちます。
汎用プログラミング・インターフェースにより、お客様はこのプログラム・ ツール・サービスを含むアプリケーション・ソフトウェアを書くことができます。
ただし、この情報には、診断、修正、および調整情報が含まれている場合が あります。診断、修正、調整情報は、お客様のアプリケーション・ソフトウェアの デバッグ支援のために提供されています。
警告: 診断、修正、調整情報は、変更される場合がありますので、 プログラミング・インターフェースとしては使用しないでください。
以下は、IBM Corporation の米国およびその他の国における商標です。
Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。
Microsoft、Windows、Windows NT および Windows ロゴは、Microsoft Corporation の米国およびその他の国における商標または登録商標です。
UNIX は、The Open Group がライセンスしている米国およびその他の国における登録商標です。