|
| Sun ONE Application Server 7 サーバーアプリケーションの移行および再配備 |
KIVA/NAS 4.1 から Sun ONE AS 7 への移行Kiva/NAS 4.1 Java AppLogic のアプリケーションは、iPlanet Migration Toolkit (iMT 1.2.3) で J2EE Web モジュールに移行できます。この結果生成される Web モジュールは、JATO と thin KFC (Kiva Foundation Classes) adaption layer を利用し、任意の J2EE web コンテナでの AppLogic コードの実行をサポートします。
はじめに
移行プロセスの開始前に、リリースノートを読んで、それぞれの環境に関連する最新情報と問題点を把握してください。%MIGTBX_HOME%/bin/readme.txt ファイルも参照してください。この readme ファイルには Migration Toolbox の正しいインストール方法と設定方法、および動作環境についての情報も記載されています。後の節に記載されている移行プロセスを開始する前に、これらのインストールおよび設定を完了し、環境を整備しておく必要があります。
%MIGTBX_HOME% は Sun ONE Migration Toolbox (S1MT) をインストールまたは解凍したディレクトリを表します。
移行準備
移行プロセスの概要
AppLogics で作成されたプロジェクトを同等の J2EE プロジェクトに完全に移行するための主要なフェーズは 2 種類あります。1 つは自動移行フェーズ、もう 1 つは手動移行フェーズです。自動移行には抽出および変換の 2 つの手順があります。
自動移行フェーズ
このフェーズでは、AppLogic アプリケーションソースの移行準備、および S1MT による自動抽出および変換を行います。AppLogic ファイル、GXR、クエリファイル、テンプレート、静的コンテンツ、通常の Java ソースおよびプロパティなど、元のアプリケーションソースファイルを含むアーカイブ (JAR/ZIP) を入力として使用します。このファイルはユーザーが準備します。このファイルはアプリケーション抽出アーカイブと呼ばれます。標準 Java アーカイブ (JAR/ZIP) を使用して既存のアプリケーションをパッケージ化すれば、NAS/iAS の実行環境は不要であり、移行環境がよりフレキシブルになります。単体テストのための手動移行で必要になるのは、データベース、Web サーバー、アプリケーションサーバーなどの実行時のインフラストラクチャだけになるため、顧客のサイトでも移行処理ができるようになります。重要なことは、このアーカイブは単にアプリケーションサーバーの ./nas/APPS ディレクトリの移行先となるコンテンツであり、Web サーバーのドキュメントルートであるということです。KIVA AppLogic の抽出ツールはこのアーカイブを読み込み、アプリケーション記述子を作成します。iMT v1.2.3 は、現在、アプリケーション抽出アーカイブの自動生成をサポートしています。Kiva Migration Toolbox Builder の「Addin」メニューにある「Addin」を参照してください。
アプリケーション記述子の XML ファイルは、アーカイブの各ファイルの後処理を行う Translation Tool のガイドとしての役割を持ちます。移行ではアプリケーション記述子の調整が必要な場合があります。アプリケーション記述子の編集に関してはテクニカルノートを参照してください。Translation Tool を実行すると、JATO および KIVA 移行ライブラリをベースにした J2EE に準拠するコンポーネントだけで構成された部分移行済みのアプリケーションが、配備記述子、サーブレット、JSP、コマンド、クエリファイルなどを含む Web アプリケーションアーカイブとして作成されます。移行が完了する場合もあります。
変換プロセスが終了すると、HTML テンプレートはすべて JSP に変換され、GX タグは KIVA 移行ライブラリで使用される新しい JSP タグに変換されます。AppLogic ソースファイルは KIVA 移行ライブラリを使用するように調整されます。ただし文をインポートするための最小限の変更だけが行われます。変換プロセスでは、JATO アプリケーションのすべてのコンポーネントとコマンド直接起動モジュールを含む、Web アプリケーションのインフラストラクチャも作成されます。ただし、変換フェーズでは、KFC API 対応で書かれたコードでも、KIVA 移行ライブラリの「対象外」のものについては自動移行を行いません。この移行が手動移行フェーズの主要なタスクになります。iMT v1.2.3 は、現在、静的ドキュメントの自動移行をサポートしています。これは URL の修正に有効です。Kiva Migration Toolbox Builder の「Addin」メニューから「Addin」を選択してください。また新しい Kiva Document Translation Tool もサポートしています。
手動移行フェーズ
一般に手動移行フェーズでは、自動移行されたアプリケーションの出力内容の確認、および対象外の KFC API コードの J2EE 固有のコードへの移行を行います。このプロセスでは通常、アプリケーションまたはアーキテクチャの再設計は不要です。通常は、手動移行の必要があるコードを、KIVA 移行ライブラリ kivaMIGRATION.jar の MIGRATION バージョンで「deprecation」でコンパイルすれば、手動処理対象の箇所が明示されます。
作業環境の準備
先に進む前に次の事項を行ってください。
- iPlanet Migration Toolbox がインストール済みかどうかを確認します。
- クラスのバージョン問題を回避するため、Toolbox アプリケーションを実行する時にはすべての JAR ファイルを JDK の拡張ディレクトリ%JAVA_HOME%/jre/lib/ext から必ず削除することをお勧めします。Toolbox の実行に必要なクラスはすべてバージョンに含まれています。拡張ディレクトリの JAR ファイルの名称を変更するだけでは不十分であり、別の場所に移動する必要があります。
- 移行対象の AppLogic ベースアプリケーションを決定します。
- アプリケーション抽出アーカイブを生成します。./nas/APPS の下のアプリケーションに関連するすべてのファイルおよびディレクトリを含む ZIP または JAR ファイルを生成するのが一番簡単な方法です。AppLogics 用の iMT では、実際はアプリケーションの Java クラスまたはライブラリをロードまたは実行しません。ソースレベルの抽出および変換が終了した時点で、アーカイブにすべての従属クラスまたはライブラリが含まれていなくても問題はありません。これらが必要になるのは自動移行後にコンパイルを行う場合です。
- ここで、Sun ONE Application Server 7 (S1AS)、Forte for Java 4.0 EE、または他の J2EE に準拠するサーブレットまたは JSP コンテナをインストールできます。
自動移行プロジェクトの準備
AppLogic および KFC による開発は自由度が大きく、規定は実質的にはないとみなすことができます。したがって、すべてのプロジェクトの置き換えを iMT では把握できません。このため、移行プロジェクトの準備時には Sun Professional Services に援助を依頼することを強くお勧めしています。
iMT Kiva BETA では、手動移行時に JDK 1.3.1 のコードを J2EE 環境でコンパイルすると障害が発生することが知られています。このような考慮点と移行を行う前に必要な処理を次に示します。
iMT 使用前に J2EE 環境に合わせたアプリケーションコードの準備が必要です。コードは JDK 1.3 (または少なくとも JDK 1.2.2) および J2EE API に対応するようにコンパイルする必要があります。たとえば、iMT には KFC 用の kfcjdk11.jar ライブラリがあります。これは既存のアプリケーションを、Forte for Java (FFJ) などのより高度な J2EE 対応 IDE でコンパイルするために用意されています。標準 AppLogic アプリケーションは、kfcjdk11.jar をファイルシステムのクラスパスに追加するだけで FFJ でコンパイルできるようになります。コンパイル前に非推奨フラグを TRUE に設定し、非推奨コードを明確にします。
JDBC をすでに使用しており、JDBC、Oracle、および Sybase などのベンダーが新しい JDK への対応を推奨している場合は、データベースサービスを最新のサードパーティドライバに対応させておくことを強くお勧めします。
移行タスクを正確に決定し、正しいデータを提供するためには、説明した特別な注意事項をすべて最初に検討する必要があります。簡単に言うと、コードの「例外的な箇所」をすべて特定する必要があります。開発者と締結している J2EE コンテナ規約の同時サーバーパターンとの不整合を発生させる、コードパターンまたは Java サービスの使用がこれにあたります。たとえばコードが java.lang.Thread を直接、または共有リソースとして使用する場合は、このコードの J2EE 適合性を検査する必要があります。
コード自体が J2EE に対応していても、使用しているサードパーティの Java サービスが対応していない場合もあります。たとえば Visibroker for Java や Iona など、旧バージョンの CORBA がこれにあたるため、アップグレードの必要があります。
J2EE では、論理アプリケーションは個別の Web アプリケーション、つまり WAR として配備する必要があります。移行を進める前に論理アプリケーションと共通ライブラリを分離することが、より簡単な方法です。
外部 URL の変更に対して準備する必要があります。J2EE の移行にどの方法を使用しても URL は変更されるため、ブックマークとこれまでにパブリッシュされた URL の移行が必要になります。iMT v1.2.3 は静的ドキュメントの URL の自動移行を部分的にサポートしています。しかし、それでも既存のシステムを調査し、手動で行う必要がある変更を明確にしておく必要があります。
GXR ファイルの準備
アプリケーション記述子の生成時の抽出フェーズを正確に実行するために、NameTrans で使用される AppLogic ファイルと AppLogic 名、および URL を識別する GXR ファイルが必要になります。ほとんどのアプリケーションで GXR ファイルを 1 つ以上使用します。アプリケーションの各パッケージで 1 つ以上使用する場合もあります。抽出フェーズでは、アプリケーション抽出アーカイブごとに GXR ファイルが 1 つだけ必要になります。GXR ファイルが複数ある場合は結合する必要があります。GXR ファイルがない場合は正しい GXR 構文に基づいて作成する必要があります。KIVA レジストリ、つまり ./nas/bin/kreg -save temp.out SOFTWARE のダンプを取ることでソースデータが得られます。要約すると、抽出ツールでは GXR ファイルを使用して、アプリケーション抽出アーカイブのどのファイルを AppLogic のソースファイルとするかを決定し、GUID の AppLogic や AppLogic クラス名へのマッピングを行います。
Extraction Tool 実行前の注意点
AppLogic アプリケーションが完全にアプリケーションサーバーサイド Java をベースにしており、クエリファイル、HTML テンプレート、AppLogic ソース、サポート Java ソースなどの要素も完全にアプリケーションサーバーサイドのものである場合、通常は ./nas/APPS ディレクトリの関連するコンテンツのアーカイブを生成するだけでアプリケーション抽出アーカイブを作成できます。ただし、アプリケーションが静的なコンテンツも含む場合は追加作業が必要になります。一般的には静的コンテンツは Netscape Enterprise Web サーバーに置き、動的コンテンツを AppLogics やテンプレートとしてアプリケーションサーバーに置くのがより効率的です。ただし、このようにコンテンツを分散させるのが良いのか、それとも同じサーバーに置くのが良いのかは J2EE サーバーのベンダーによっても変わります。静的コンテンツは自動移行時、またはその終了後に WAR に追加できます。通常これが一番簡単な方法です。
元の AppLogics アプリケーションを J2EE JATO に iMT を使用して移行する場合には、考慮すべき重要な点が 1 つあります。AppLogics (POST/GET) を起動する URL が http://host/cgi-bin/gx.cgi/AppLogic+HelloWorld のような絶対パスの場合でも、移行後の URL は ServletContext で定義されたコンテキストに対する相対パスになるため、必ず相対パスで記述するようにします。URL の変換は静的コンテンツや HTML テンプレートなどの動的コンテンツの変換とは別に行う必要があります。iMT はすべての AppLogics を、コマンド直接起動モジュールと呼ばれる特別な JATO モジュールで JATO コマンドの実装にマップします。変換されるすべての AppLogics が ServletContext 内の同じパスから呼び出されるため、結果として生成される HTML マークアップでは、イントラ AppLogic 起動 (URL) が最も予想しやすいものになります。したがって、すべての AppLogic 起動 URL はイントラ AppLogic 向けに変換されます。アプリケーション抽出アーカイブの HTML テンプレートに静的コンテンツが含まれる場合、この静的コンテンツのコンテキストはコマンド直接起動モジュール (ModuleServlet) の ServletContext で指定されているパスとは適合しないため、AppLogic URL を調整する必要があります。OnlineBankSample の移行を行うとこの調整の必要性を確認でき、Kiva Document Translation Tool を使用して静的ドキュメントの自動変換を実際に行うことができます。
OnlineBankSample の移行
この節では、onlineBankSample を J2EE に自動または手動で移行する手順について説明します。
Migration Toolbox の実行
iMT 1.2.3 をまだインストールしていない場合はインストールします。iMT のインストールおよび起動を説明している"移行準備"節を参考にしてください。%MIGTBX_HOME%¥bin¥setenv.bat を編集し、iMT のインストール場所と JDK ホームディレクトリを適切に設定します。
Toolbox の作成
- 「Addin」>「Migration」メニューから「Kiva Migration Toolbox Builder」を選択します。
モーダルダイアログウィザードが表示されます。
「OK」をクリックしてウィザードの最初の手順に進みます。
- 自動 iMT 移行では新しい Java JATO ファイルを含む J2EE インフラストラクチャをいくつか生成します。これらの新しいファイルにパッケージを割り当てる必要があります。元のアプリケーションの既存の Java ソースがパッケージ化されて残る場合でも、これらの新しいファイルにパッケージを割り当てる必要があります。パッケージ名に関する制限はありません。OnlineBankSample アプリケーションにはデフォルト値が提示されます。
パッケージを入力し、「OK」をクリックしてウィザードの次の手順に進みます。
- iMT で生成されるすべてのデータを格納するディレクトリを入力します。通常はデフォルトの値を変更する必要はありません。この例でもデフォルトの値を使用しています。「OK」をクリックしてウィザードの次の手順に進みます。
- Automatic Application Extract Archive Wizard を使用して、アーカイブを自動構築するツールを作成できます。「OK」を選択すると手順 (5) に進みます。「Cancel」を選択すると以下の抽出アーカイブ選択ダイアログが表示されます。
このダイアログボックスで手動で作成されたアーカイブを指定できます。抽出アーカイブをすでに作成しており、新しいツールボックスだけを構築する場合はこの手順が便利です。
Automatic Application Extract Archive Wizard で「OK」を選択すると次のダイアログが表示されます。
- デフォルト値を変更せずに「OK」を選択して、次の手順に進みます。
- デフォルトの空白のリストを変更せずに「OK」を選択して、ウィザードの次の手順に進みます。
- デフォルトを変更せずに「OK」を選択します。ツールボックスに 3 つのツールが新しく生成され、ウィザードの次の手順に進みます。
- OnlineBankSample の Java ソースはすべて ASCII エンコードを使用しています。したがってデフォルトをそのまま使用します。ユーザー独自のアプリケーションを移行する時に、日本語 Shift_JIS など他の文字エンコードを使用している Java ソースがある場合は、その文字エンコードを指定します。「OK」をクリックしてウィザードの次の手順に進みます。
- OnlineBankSample のクエリファイルはすべて ASCII エンコードを使用しています。したがってデフォルトをそのまま使用します。ユーザー独自のアプリケーションを移行する時に、日本語 Shift_JIS など他の文字エンコードを使用しているクエリファイルがある場合は、その文字エンコードを指定します。「OK」を選択するとツールボックスに Kiva Extraction and Translation tools が作成され、ウィザードの次の手順に進みます。
- iMT v1.2.3 には静的 HTML ドキュメントを自動変換し、WAR ファイルと自動結合する機能が用意されています。この機能をスキップするとウィザードは終了し、ツールボックス生成は終了します。OnlineBankSample に対して「OK」を選択して自動機能を使用します。
- 「OK」を選択して OnlineBankSample のデフォルトのドキュメントディレクトリを指定します。4 つの新しいツールがツールボックスに生成され、ウィザードが終了します。
「OK」をクリックして必要なツールの生成を完了します。アドインの結果、抽出ツール、変換ツール、およびアプリケーション抽出アーカイブ自動生成とドキュメント自動変換で使用されるオプションツールが作成され、ツールボックスに必要なツールがすべて揃います。各ツールの分岐を選択すると、詳細なヘルプが右側のフレームに表示されます。ヘルプにはツールの各プロパティの説明があります。ツールの各インスタンスをクリックすると、Bean プロパティパネルが右側のフレームに表示されます。基本プロパティおよび高度なプロパティを編集できます。
Task Tool はリストに記載された他のツールを単純に順番どおり実行します。ツールを個別に実行すれば、コンソールへの出力を注意深く確認することができ、より詳細な情報を得ることができます。
抽出ツールのプロパティを以下に示します。
変換ツールのプロパティを以下に示します。
- CreateAppExtractArchive-onlinebank Task ツールを起動します。このツールは CopySrcAll-onlinebank と JarExtract-onlinebank の各ツールを順番に実行し、アプリケーション抽出アーカイブを生成します。
%MIGTBX_HOME%¥work¥onlinebank¥archive¥onlinebankApps.jar
- Extract-onlinebank を起動します。このツールは非常に高速に実行されます。ツール実行のトレースがコンソールフレームに表示されます。アプリケーション抽出ファイルを内観し、GXR ファイルを収集して、アプリケーションを記述する XML ファイルを生成します。このアプリケーション記述子の内容を確認し、必要に応じてファイルの構成が正しくなるように編集します。編集することで、正しいエンコードを含むアーカイブの各ファイルの後処理を Translation tool が明確に認識できるようになります。iMT 1.2.3 の Extraction tool は HTML テンプレートのエンコードを自動認識します。アプリケーション記述子の内容を確認し、各テンプレートに対して正しいエンコードが選択されていることを確認します。アプリケーション記述子は次の場所に置かれます。
%MIGTBX_HOME%¥work¥onlinebank¥appdesc¥onlinebank.xml
XML エディタでこのファイルを慎重に確認し、編集することをお勧めします。次の図は XML Spy でこのファイルの一部を表示したものです。
- Translate-onlinebank を起動します。時間は抽出よりも少し長くなり、またアーカイブの AppLogic ソースファイル、Java ファイルおよび Html テンプレートの数によって変わります。変換時には常にコンソールの出力に注意し、エラーが発生していないかどうかを確認します。Translation tool はエラーが発生すると処理をスキップし、残りのアプリケーションの変換を進めます。トレースの出力が大きくなれば警告やエラーを見逃しやすくなります。高度なプロパティを変更してデバッグと詳細なトレースを有効にし、変換の詳細を確認することができます。正規表現マッピング規則の内部呼び出しやエレメント処理の使用などが確認対象となります。変換結果は出力ディレクトリの下の migrated ディレクトリに置かれます。
完全な J2EE JATO Web アプリケーションが migrated/war に作成されます。
- FixStaticDocs-onlinebank Task ツールを起動します。このタスクは、JarDocs-onlinebank、TranslateDocs-onlinebank、および CopyDocs2War-onlinebank を順番に呼び出し、AppLogics の静的コンテンツ URL を修正し、コンテンツを WAR のドキュメントルートにコピーします。
自動移行はこの時点で完了します。次に手動移行を開始します。
手動移行を進めていく最も簡単な方法は、Web アプリケーションを J2EE IDE にロードすることです。この例では Forte for Java EE (FFJ) を使用しています。
- FFJ 4.0 を起動し、OnlineBank という名前の新しいプロジェクトを作成します。新しいプロジェクトには既存のファイルシステムを置かないようにします。「プロジェクト」をメニューから選択し、「プロジェクトマネージャ」をクリックします。
- 「プロジェクトマネージャ」ウィンドウで「新規」をクリックし、プロジェクト名を入力します。ここでは OnlineBank を入力しています。
- 「ファイルシステム」アイコンを右クリックし、エクスプローラパネルで「マウント」>「ローカルディレクトリ」を選択します。${migtbox_home}¥work¥output¥onlinebank¥migrated¥war を選択し、「OK」をクリックします。Forte ではこのディレクトリを標準の WAR ディレクトリとして認識し、WAR ビューをエクスプローラに表示します。
FFJ では、ファイルシステムという用語を、プロジェクトのクラスパスのエントリを指す用語として使用します。WAR ディレクトリのマウント時に自動的にクラスパスの一部となるのは、./war/WEB-INF/classes に置かれている war ファイルだけではありません。./war/WEB-INF/lib に置かれている ZIP および JAR の各ライブラリも追加されます。下記の OnlineBank プロジェクトのファイルシステムを参照してください。
新しい Web アプリケーションのドキュメントルートは以下の位置になります。JSP に変換された静的コンテンツおよび HTML テンプレートを確認してください。
Java クラスは Web アプリケーションの以下の位置に新たに置かれます。元の Java ソースが元のパッケージ形態を維持していることを確認してください。AppLogics は JATO コマンドに変換されます。影響を受けるコードはごくわずかです。新しい JATO ソースファイルは Translation tool のプロパティで指定された新しいパッケージに置かれます。
Java ソースはコンパイルする必要があります。ここで重要な点は、コンパイラの非推奨 (deprecation) フラグを設定することです。Translation tool は KFC adaption library のデバッグまたは「移行」バージョンを WAR に自動的に配備します。このライブラリを使用し、非推奨 (deprecation) フラグを指定して変換されたアプリケーションをコンパイルすると、「対象外の」API を使用しているコードの各行に対してレポートを生成します。この目的は、できるだけ早くコンパイルを完了し、手動移行に必要なタスクのレポートを生成することです。アプリケーションが「対象外の」API を使用していても、コンパイルすれば実行はできます。ただし、null や EXE.FAILURE を返すなどの対象外 API が動作しないため、正常には動作しません。アプリケーション全体の移行は負荷が高い作業であるため、このような段階的移行およびテストは有効な手段です。つまり、移行される AppLogic JATO コマンドは 1 つずつテストできます。また、非推奨 (deprecation) レポートで必要な作業を特定することができるという利点もあります。
- 外部コンパイラをコンパイラとして指定してプロジェクトのプロパティを編集し、deprecation を true に設定します。「ツール」をメニューから選択し、「オプション」をクリックします。最初に「構築」、次にその下の「コンパイラの種類」ノードを展開し、「オプション」ウィンドウの「外部コンパイラ」の「非推奨 (deprecation) 」を true に設定します。
- エクスプローラ の「プロジェクト」で「クラス」の分岐を選択し、右クリックしてメニューを開き、「すべてをコンパイル」を選択します。AppLogics などの移行されたコードは次のディレクトリに置かれているものが処理対象になります。
${migtbox_home}¥work¥output¥onlinebank¥migrated¥war¥WEB-INF¥classes¥
新しく生成された JATO インフラストラクチャは次のディレクトリに置かれているものが処理対象になります。
${migtbox_home}¥work¥output¥onlinebank¥migrated¥war¥WEB-INF¥classes¥com
コンパイルはただちに実行されます。
OnlineBankSample では対象外のセッション KFC API が 6 箇所で、iMT のバージョンでは ITrans の対象外「コミット」メソッドが 3 箇所で指定されています。
対象外 API の中で最もよく使用されるのがセッション API です。KIVA Application Server および KFC では、任意のセッション API に対して ISessionIDGen 参照を設定できます。このインタフェースでセッション ID および関連する動作を制御できます。J2EE にはこのような機能はありません。アプリケーションが ISessionIDGen を使用している場合、その部分については手動で再設計する必要があります。ほとんどの開発者は API にnull オブジェクト参照を設定し、この機能を使用しません。それでもやはり、すべての KFC「セッション」API にこのパラメータが必要であり、ISessionIDGen タイプは対象外であるため、すべてのKFC「セッション」API は対象外になります。ほとんどの対象外メソッドに対して、ISessionIDGen パラメータを必要としない API が提供されています。このような対象外のセッション API を使用している場合は、移行時に変更を行い、代わりの API を使用するようにします。通常、これらのセッション API はアプリケーション内の 2、3 箇所にまとまって存在するので、手動変更作業の負荷はそれほど高くありません。セッション API では、特別に考慮する点が 2 つあります。IAppLogic.saveSession(ISessionIDGen) の代わりになるメソッドはありません。J2EE には HttpSession の「保存またはフラッシュ」の概念がないためです。この API は削除されます。IAppLogic.createSession(int, int, String, String, ISessionIDGen) API の代わりになる API にはパラメータがありません。J2EE のサーブレット API は、KFC API のような制御機能を開発者に提供していません。ただしコンテナのベンダーは、便利な設定機能や配備記述子およびアプリケーションサーバー設定による HttpSession を提供している場合があります。
ITrans.commit メソッドの引数は 1 つですが、KIVA では使用されません。この API を引数のない API に置き換えてあります。CreateCust.java、Transfer.java、および UpdateCust.java の 3 つのメソッドから、値「0」を削除する必要があります。
- OnlineBankSample アプリケーションでは、BaseAppLogic.java、OBLogin.java、および OBLogout.java でセッション API を使用しています。以下の変更が必要になります。
BaseAppLogic.java、38 行目
ISession2 currentSession = getSession(); // getSession(0, appName, null);
BaseAppLogic.java、44 行目
currentSession = createSession(); //createSession(GXSESSION.GXSESSION_DISTRIB, 0, appName, null, null);
OBSession.java、52 行目
// result = m_logic.saveSession(null);
OBLogin.java、123 行目
int rc = GXE.SUCCESS; // saveSession(null);
OBLogout.java、27 行目
destroySession(); // destroySession(null);
通常は HTML ソースの手動変更が必要になります。HTML テンプレートのソースまたは JSP の変更が必要な場合もあります。変更はアプリケーションごとに異なります。ほとんどの手動処理は iMT で系統的に行うことができます。繰り返されるパターンを検出し、正規表現マッピングツールを使用して、作業を自動化できます。マークアップで変更が必要になるのはほとんどが URL のパスです。動的コンテンツから静的コンテンツへのリンクで絶対パスを使用している場合は、Web アプリケーションコンテキストが付加されることでパスが無効になります。
- ExitMessage.jsp の両方のバージョンを編集します。静的コンテンツを WAR ファイルに移動しているため、動的コンテンツから静的コンテンツへの参照は無効になります。コンテンツが WAR ファイル外に配備されればこれらの参照は正しくなります。絶対参照の前には「..」が追加されます。ExitMessage.jsp は、実際はサーブレットコンテキスト内の /cmd サーブレットマッピングのコンテキストに存在するため、パスを 1 セグメント上に移動するだけでサーブレットコンテキストのドキュメントルートに戻ることができます。
/GXApp/OnlineBankSample/templates/en/ExitMessage.jsp
/GXApp/OnlineBankSample/templates/ja/ExitMessage.jsp
15 行目 (html -> jsp のリンクおよびパス) (以下参照)
href="../GXApp/OnlineBankSample/en/OBLogin.html"> Back to Login Page </a><br>
- (省略可能) /WEB-INF/web.xml を編集し、ルートコンテキスト要求時の自動起動を許可します (以下参照)。開始ファイル要素をサーブレットマッピングと taglib 要素の間に追加する必要があります。
</servlet-mapping>
<welcome-file-list>
<welcome-file>
GXApp/OnlineBankSample/index.html
</welcome-file>
</welcome-file-list>
<taglib>
手動移行の主な作業はアプリケーション内の URL の確認です。静的なコンテンツと動的なコンテンツのリンクは、J2EE 配備の移植を可能にするため相対パスに変更する必要があります。JavaScript の変更も必要になります。
手動移行処理が終了し、最終的に生成される Web アプリケーションは任意の J2EE Web コンテナに配備できます。FFJ では WAR ファイルをエクスポートし、iAS 6.5 に配備できます。また、Web アプリケーションは FFJ に組み込まれた TomCat サーバーで直接実行できます。
- サーバーモジュールグループを FFJ に追加します。エクスプローラの「WEB-INF」分岐を右クリックし、「新規」->「JSP& サーブレット」->「Web モジュールグループ」を選択し、サーバーグループを追加します。ウィザード画面のデフォルト値をそのまま使用し、「完了」をクリックします。エクスプローラの「WEB-INF」に、「ServerConfiguration」という名前の新しい要素が表示されます。エクスプローラの「ServerConfiguration」分岐を右クリックし、「Web モジュールを追加」を選択して現在の Web アプリケーションを追加します。サーブレットコンテキスト名が「Web モジュールを追加」ウィンドウに表示されます。たとえば「Demo」などが表示されます。
- エクスプローラで「ServerConfiguration」分岐を右クリックし、「実行」を選択して FORTE で実行します。