WebSphere Application Server Network Deployment, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

マイグレーション時の構成マッピング

マイグレーション時にさまざまな構成がマップされます。

マイグレーションでは、常に単一のインスタンスを、 同一マシン上または別のマシン上の別の単一インスタンス (プロファイル) にマイグレーションします。 例えば、 バージョン 5.x デプロイメント・マネージャーを、 バージョン 6.0.x デプロイメント・マネージャー・ プロファイルにマイグレーションして、 バージョン 5.x アプリケーション・サーバーを、 バージョン 6.0.x スタンドアロン・アプリケーション・サーバー・ プロファイルにマイグレーションします。

多くのマイグレーション・シナリオが考えられます。 バージョン 6.0.x のマイグレーション・ツールは、 前のバージョンから構成を復元する際に、オブジェクトと属性をバージョン 6.0.x 環境にマップします。

ブートストラップ・ポート

マイグレーションにより、 デフォルトのブートストラップ NameServer ポート設定 (900) が、 バージョン 4.0.x Advanced Edition またはバージョン 5.x からバージョン 6.0.x の NameServer のデフォルト (2809) にマップされます。 マイグレーション・ツールは、デフォルト以外の値を直接バージョン 6.0.x 環境にマップします。

バージョン 4.0.x Advanced Single Server Edition のマイグレーションの場合、 ブートストラップ NameServer ポートは、サーバー構成ファイルに定義されているアプリケーション・サーバーの NameServer 値にマップされます。

コマンド行パラメーター

マイグレーション・ツールは、サーバー・プロセス定義において、 該当するコマンド行パラメーターを Java 仮想マシン (JVM) 設定に変換します。 ほとんどの設定は、直接マップされます。 メモリー・ヒープ・サイズなどの一部の設定は、マイグレーションされません。 これは、バージョン 6.0.x 構成では役割を持たないか、 バージョン 6.0.x では意味や有効範囲が異なるためです。

クラスター・メンバー

バージョン 4.0.x のサーバー・グループは、バージョン 6.0.x のクラスターに変換されます。 マイグレーションを行うと、 スタンドアロン・サーバーとは異なる方法で、 クラスター・メンバーが構成されます。 サーバー・グループのマイグレーション時には、 そのグループのすべてのサーバーは、固有のポート番号が個々に割り当てられているかどうかに関係なく、 そのサーバー・グループの HTTP トランスポート・ポート番号が割り当てられます。 したがって、マイグレーション後、 新規のクラスター内のすべてのアプリケーション・サーバーは、同一の HTTP トランスポート・ポートを使用します。 管理コンソールを使用して、固有のポート番号を割り当てることができます。 これにより、サーバーを統合せずに実行できます。

デフォルトのサーバー

バージョン 6.0.x のデフォルトのサーバーの名前は server1 です。 マイグレーション後、 これまで、バージョン 4.0.x の DefaultServer が所有していたオブジェクトはすべて、 バージョン 6.0.x の server1 が所有します。

クラスター・メンバー用のエンタープライズ・アプリケーション

バージョン 4.0.x からマイグレーションする場合、 エンタープライズ・アプリケーションは、クラスター・メンバーに対してデプロイされません。 スクリプトまたはデプロイメント・マネージャー管理コンソールを使用して、 これらのアプリケーションを、クラスターに手動でデプロイする必要があります。 バージョン 5.x からマイグレーションする場合、アプリケーションは自動的にデプロイされます。

GenericServer
GenericServer は、バージョン 5.1.x で導入され、外部リソースを管理するために適合された APPLICATION_SERVER です。 バージョン 6.0.x では、GENERIC_SERVER と呼ばれる独自のタイプを持ちます。 マイグレーションによりこの変換が実行されますが、GenericServer が参照する外部リソースは正確にマイグレーションされません。GenericServer 設定のマイグレーションが完了後、以下のアクションを実行する必要があります。
  • GenericServer が管理している古いリソースが古い WebSphere Application Server インストールにある場合は、関連するファイルを WebSphere Application Server の新規インストールにコピーする必要があります。必要なセットアップを実行して外部アプリケーションを有効な作動状態に戻す必要もあります。IBM は、この代わりにリソースを新規 WebSphere Application Server ディレクトリーに再インストールすることをお勧めします。いずれを選択し実行した場合でも、最終ステップでは、アプリケーションの新規ロケーションへの参照をリセットする必要があります。
  • GenericServer が管理している古いリソースが古い WebSphere Application Server インストールにインストールされていない場合は、その他に必要ありません。
Java DataBase Connectivity (JDBC) ドライバーおよびデータ・ソース

バージョン 6.0.x は、JDBC およびデータ・ソース・オブジェクトを大幅に再定義します。 マイグレーション・ツールでは、 以前に使用した設定を入力変数として使用して、 バージョン 4.0.x のデータ・ソースをバージョン 6.0.x のデータ・ソースにマップします。

jmsserver

jmsserver は、タイプ MESSAGE_BROKER からタイプ APPLICATION_SERVER に変更されます。 これが所有したキューまたはトピックは、サービス統合テクノロジーに基づく、 バージョン 6.0.x のデフォルト・メッセージング・プロバイダーにマイグレーションされました。 前のリリースでは、 Network Deployment 環境で、jmsserver はそれ自体の MESSAGE_BROKER サーバーでした。 Base 環境では、APPLICATION_SERVER タイプ内に含まれていました。 JMS リソースはすべてそのままで、変更しないで動作する必要があります。これらのリソースのさらなるマイグレーションは、 バージョン 6.0.x のデフォルト・メッセージング・プロバイダーによって提供されるスクリプト/bat を実行することによって行うことができます。 JMS リソースについて詳しくは、メッセージング・リソースについての学習 を参照してください。

バージョン 5.x ノードのバージョン 6.0.x ノードへのマイグレーション

セルに所属するバージョン 5.x ノードは、 セルからノードを除去せずにマイグレーションできます。

最初にデプロイメント・マネージャーをマイグレーションしてから、 セル内の他の基本ノードをマイグレーションします。

Network Deployment を バージョン 5.x からバージョン 6.0.x にマイグレーションする場合は、 同じセル名を使用してください。 別のセル名を使用すると、Network Deployment バージョン 6.0.x セルに、 統合ノードが正常にマイグレーションされません。

セル内にある WebSphere Application Server の基本ノードをバージョン 6.0.x にマイグレーションすると、 ノード・エージェントもバージョン 6.0.x にマイグレーションされます。 セル内には、いくつかのバージョン 6.0.x ノードとほかのバージョン 5.x レベルのノードがある可能性があります。

名前バインディング
バージョン 6.0.x には、新しいネーミング構造が導入されました。 旧バージョンで有効だった Enterprise Java Bean 参照などの参照はすべて、 バージョン 6.0.x では機能しません。 ただし、管理コンソールを使用して、 旧名をバージョン 6.0.x の新しいネーミング構造にマップする名前バインディングを追加することができます。 例えば、バージョン 5.0.x のエンタープライズ Bean 参照の名前は、バージョン 6.0.x のネーム・スペ ースでは、バインディング名であっても Java Naming and Directory Interface (JNDI) 名であってもかまいません。
注: 旧バージョンからのネーム・スペースの内容は、自動ではバージョン 6.0.x にマイグレーションされません。
ノード名

バージョン 4.0.x のリポジトリーには、 複数のノード名および関連付けられた子を入れることができます。WASPostUpgrade ツールは、 マイグレーションするノードのノード名と一致する、オブジェクトと子のみを処理します。 このツールは、マイグレーション中の構成ファイル内のノード名を識別し、 マイグレーションしているマシンの長いネットワーク名または短いネットワーク名と一致する構成ファイル内のノード名を選択します。

PageList サーブレット

PageList サーブレットの構成は、バージョン 4.0.x から変更されました。 このサーブレットを直接使用することは推奨されなくなりました。 PageList サーブレットは、 Web アーカイブ (WAR) ファイル内のサーブレット拡張構成の一部として使用可能です。 すべての参照は、バージョン 6.0.x でサポートされるサーブレット構成に更新されます。

サーブレット構成を変更するには、Application Server Toolkit (AST) および Rational Web Developer を使用することもできます。詳しくは、アセンブリー・ツール を参照してください。

PageList サーブレットを使用または拡張した場合、 このサーブレットを使用しているマイグレーション済みアプリケーションの実行時に、 次の例のようなエラーが戻されることがあります。
Error 500: No PageList information is configured for servlet
EmpInfoApp.SearchByDept
以下のように、アセンブリー・ツールキットを使用して、 マイグレーション済みの Enterprise アーカイブ (EAR) ファイルに使用または拡張を移動することによりエラーを修正します。
  1. アセンブリー・ツールキットを開始して、エラーを生成する EAR ファイルをロードします。
  2. EAR ファイル内の Web モジュールを開きます。
  3. エラーを生成する Web モジュールを展開します。
  4. Web コンポーネントを開き、エラーを生成する Web コンポーネントを検索します。
  5. サーブレットを展開します。 「PageList 拡張子」オプションが表示されます。
  6. 拡張情報を追加します。
  7. EAR ファイルを保管し、再デプロイします。
バージョン 5.x からバージョン 6.0.x へのポリシー・ファイルのマイグレーション
WebSphere Application Server バージョン 6.0.x では、 設定を Version 6.0.x ポリシー・ファイルにマージすることにより、 バージョン 5.x でインストールされたすべてのポリシー・ファイルがマイグレーションされます (以下の特性があります)。
  • バージョン 6.0.x ポリシー・ファイルにあるコメントは失われます。 これらのコメントは、 バージョン 6.0.x ポリシー・ファイルに含まれるコメントと置き換えられます。
  • マイグレーションでは、許可または認可はマージされません。厳密には、追加タイプのマイグレーションです。許可または認可がバージョン 6.0.x ファイルにない場合、 マイグレーションにより引き渡されます。
  • セキュリティーは重要なコンポーネントです。このため、 マイグレーションにより、コメント「MIGR0372I: マイグレーション済みの権限は次のとおりです。 」の直後の元の .policy ファイルの最後に追加が行われます。これによって、マイグレーションによって行われたポリシー・ファイルの変更を、管理者が確認しやすくなります。 
プロパティー・ディレクトリーおよび lib/app ディレクトリー

マイグレーションにより、 ファイルが旧バージョン・ディレクトリーからバージョン 6.0.x 構成にコピーされます。 詳しくは、次のセクションを参照してください。

プロパティー・ファイルのバージョン 4.0.x からのマイグレーション
バージョン 6.0.x マイグレーションでは、 バージョン 4.0.x からのプロパティー・ファイルが WebSphere Application Server バージョン 6.0.x にも含まれている場合には、 それらのファイルをマイグレーションします。 具体的には、プロパティー・ファイルのマイグレーションには、次のファイルが含まれます。
  • converter.properties
  • sas.client.props
  • encoding.properties ("ko" 設定が間違っていれば、マイグレーションは行われません。)
  • TraceSettings.properties
その他のプロパティー・ファイルにある設定は、 手動でバージョン 6.0.x と同等の構成に変換する必要があります。
バージョン 5.x からバージョン 6.0.x へのプロパティー・ファイルのマイグレーション
WebSphere Application Server バージョン 6.0.x では、 以下の場合を除き、設定をバージョン 6.0.x プロパティー・ファイルにマージすることにより、 バージョン 5.x でインストールされたすべてのプロパティー・ファイルがマイグレーションされます。
  • j2c.properties (resources.xml ファイルにマイグレーションされます)
  • samples.properties
マイグレーションでは、プロパティー・ファイルはオーバーレイされません。
J2C リソースによって参照されるリソース・アダプター・アーカイブ (RAR)

J2C リソースによって参照される RAR が古い WebSphere Application Server インストールにある場合、これらの RAR はマイグレーションされます。この場合、RAR は、新しい WebSphere Application Server インストールの対応するロケーションにコピーされます。関係リソース・アダプター RAR はマイグレーションされません。

サンプル

デプロイメント・マネージャーのマイグレーション時に、 統合ノードのバージョン 5.x サンプルがマイグレーションされます。 その他すべてのバージョン 5.x サンプルについては、同等のバージョン 6.0.x サンプルを使用することができます。

セキュリティー

Java 2 セキュリティーは、バージョン 6.0.x ではデフォルトで使用可能です。 セキュリティーの使用可能化により、一部のアプリケーションをバージョン 6.0.x ではなく、 バージョン 4.0.x で実行できるようになります。 バージョン 6.0.x でさまざまなレベルの Java 2 セキュリティーを定義するためのいくつかの技法が使用可能です。 1 つは was.policy ファイルをアプリケーションの一部として作成し、 すべてのセキュリティー許可を使用可能にすることです。 マイグレーション・ツールは、マイグレーション中に wsadmin コマンドを呼び出して、 バージョン 6.0.x の properties ディレクトリーにある既存の was.policy ファイルをエンタープライズ・アプリケーションに追加します。 マイグレーション・ツールは、バージョン 4.0.x アプリケーションをバージョン 6.0.x に移動する際に、 この作業を実行します。

バージョン 4.0.x で Lightweight Third Party Authentication (LTPA) を使用するグローバル・セキュリティーが、WebSphere Application Server 基本製品および Network Deployment 製品に マイグレーションされます。ただし、グローバル・セキュリティーは、 バージョン 4.0.x では使用可能化されていても、 バージョン 6.0.x へのマイグレーション時に使用不可になります (バージョン 5.x からのマイグレーション時にはセキュリティーは使用不可になりません)。

バージョン 4.0.x で localos 認証メカニズムを使用するグローバル・セキュリティー機能は、 Network Deployment 製品にマイグレーションされます。ただし、グローバル・セキュリティーは、バージョン 4.0.x では使用可能でしたが、 バージョン 6.0.x へのマイグレーション中に使用不可になります。 Network Deployment 製品は SWAM と呼ばれる認証メカニズムをサポートしません。 マイグレーションによって、バージョン 6.0.x の認証メカニズムを LTPA に設定します。 管理コンソールを使用して、 マイグレーション済み LTPA の鍵を生成します。 鍵を生成したら、グローバル・セキュリティーを使用可能にできます。

バージョン 4.0.x では、 JNDI 検索タイムアウト値のチューニングと LDAP 接続の再利用をサポートするプロパティーが導入されています。 これら 2 つのプロパティーは、現在、 バージョン 6.0.x の管理コンソールの「セキュリティー・センター」内の設定値になっています。 バージョン 4.0.x プロパティー値は、 バージョン 6.0.x 設定へマイグレーションされません。
  • jndi.LDAP.SearchControl.TimeLimit プロパティーは、 バージョン 6.0.x の「検索タイムアウト」設定 (バージョン 6.0.x ではデフォルトで 300) と同等です。
  • jndi.LDAP.URLContextImplementation プロパティーは、 バージョン 6.0.x の「接続の再利用」設定 (バージョン 6.0.x ではデフォルトで true) と同等です。

必要に応じて、バージョン 6.0.x の管理コンソールを使用し、 バージョン 4.0.x のプロパティー値に合わせて、これらの設定値を変更してください。

サーバー・グループ

バージョン 4.0.x のサーバー・グループは、バージョン 6.0.x のクラスターとして再定義されます。 アプリケーション・サーバーは、 バージョン 6.0.x のクラスター・メンバーとしてサポートされている唯一のオブジェクトです。

サーブレット・パッケージ名の変更

DefaultErrorReporter サーブレットを含むパッケージは、 バージョン 5 で変更されました。 バージョン 4.0.x では、このサーブレットは com.ibm.servlet.engine.webapp クラスにあります。 バージョン 6.0.x では、このサーブレットは com.ibm.ws.webcontainer.servlet クラスにあります。 DefaultErrorReporter サーブレットを直接使用することは推奨されなくなりました。

Stdin、stdout、stderr、passivation、および作業ディレクトリー

通常、これらのディレクトリーは、 前のバージョンのインストール・ディレクトリーにあります。 デフォルトでは、stdinstdout、 および stderr は、バージョン 6.0.x のインストール・ルートの logs ディレクトリーにあります。 マイグレーション・ツールは、既存の passivation ディレクトリーと作業デ ィレクトリーのマイグレーションを試行します。 そうでない場合、該当するバージョン 6.0.x のデフォルトが使用されます。

共存シナリオでは、バージョン間で共通のディレクトリーを使用すると、問題が生じる可能性があります。

トランスポート・ポート

マイグレーション・ツールは、すべてのポートをマイグレーションします。 ポートがすでに存在している場合、 このツールはログ内のポートの競合について警告します。 競合しているサーバーを同時に実行する前に、ポートの競合を解決する必要があります。

-scriptCompatibility="true" または -scriptCompatibility="false" を選択すると、トランスポート・ポートのための 2 つの結果が得られます。
  • -scriptCompatibility="true": これにより、トランスポート・ポートはそのままです (これはデフォルトです)。
  • -scriptCompatibility="false": これにより、トランスポート・ポートはチャネルとチェーンの新しいインプリメンテーションに変換されます。外部アプリケーション使用の観点から、トランスポート・ポートは同じように動作しますが、TransportChannelService に移行されました。トランスポート・チェーンとチャネルについて詳しくは、 トランスポート・チェーン を参照してください。
Web モジュール

バージョン 6.0.x が実装する Java 2 Platform、Enterprise Edition (J2EE) の仕様レベルでは、 コンテンツ・タイプを設定する場合、Web コンテナーの振る舞いの変更が必要になります。 デフォルトのサーブレットの書き込み機能によってコンテンツ・タイプが設定されない場合、 バージョン 6.0.x の Web コンテナーのデフォルトがその値に設定されなくなるばかりでなく、 Web コンテナーは呼び出しを「ヌル」として戻します。 この場合、一部のブラウザーで、Web コンテナーのタグが正しく表示されないことがあります。 エンタープライズ・アプリケーションをマイグレーションする際に、 autoResponseEncoding IBM 拡張が Web モジュールに対して true に設定されます。 このアクションにより、問題が生じなくなります。

バージョン 4.0.x からバージョン 6.0.x へのマイグレーション
バージョン 4.0.x 構成は、すでに J2EE 1.2 仕様レベルになっています。 バージョン 6.0.x は J2EE 1.4 仕様レベルですが、 J2EE 1.2 オブジェクトがサポートされています。
  • エンタープライズ Bean

    バージョン 4.0 から EJB 1.1 JAR ファイルを移動する場合、再デプロイメントは必要ありません。

    JAR ファイルごとに、 バックエンド・データ・ストア・ベンダーを 1 つだけ指定してください。 エンタープライズ Bean で異なるバックエンド・データ・ストアを使用する場合は、 それらを別々の JAR ファイルにパッケージしてください。

  • JMS リソース

    バージョン 4.0 からの JMS リソースはすべて、 バージョン 6.0.x 構成内の汎用 JMS リソースにマップされます。 IBM WebSphere MQ を使用する JMS リソースを、 IBM WebSphere MQ 固有のリソースとして再構成します。 MQ JMS リソースは、より適切にシステム管理と統合されます。 ネーム・スペース内の項目を手動で定義する必要はありません。 MQ JMS 項目を介してバッキング MQ キュー定義を参照できます。

  • JavaServer Pages (JSP) プリコンパイル

    バージョン 4.0.x では、JSP ファイルから生成されたクラスは、 WAR ファイルのディレクトリー構造に基づくパッケージ内にあります。 コンテキスト・ルートの上部にある JSP ファイルは、すべて unnamed パッケージ内にあります。 ルートのサブディレクトリー内の JSP ファイルは、そのサブディレクトリーの名前をとって名付けた パッケージ内にあります。 バージョン 6.0.x では、JSP ファイルから生成されたクラスは、 すべて org.apache.jsp パッケージ内にあります。 したがって、クラス・ファイルは、バージョン間で互換しません。

    エンタープライズ・アプリケーションをバージョン 4.0.x からバージョン 6.0.x にマイグレーションする際に、 JSP ファイルを再コンパイルして、クラス・ファイルを正しいパッケージ内に再生成します。

    マイグレーション・ツールは、 アプリケーションのインストール中に wsadmin コマンドの -preCompileJSPs オプションを使用して、 これをサポートします。

    同じオプションを使用して、 手動でバージョン 6.0.x に移動させるバージョン 4.0.x エンタープライズ・アプリケーションをインストールします。

  • J2EE セキュリティー

    バージョン 4.0.x の 2 つのロケーションにあるセキュリティーを、 エンタープライズ・アプリケーションに適用できます。 リポジトリー内の情報は、 エンタープライズ・アプリケーション・バインディング内の情報に優先します。 マイグレーション・ツールは、 リポジトリー内の情報をエンタープライズ・アプリケーションにマイグレーションします。

  • Secure Sockets Layer (SSL) のマイグレーション

    ユーザー定義の鍵ファイルを指す次の SSLConfig 属性は、 以下のようにして WebSphere Application Server バージョン 4.0.x (AE) またはバージョン V5.x からバージョン 6.0.x にマイグレーションされます。

    バージョン 4.0.x またはバージョン 5.x の設定
    <key_file_name>dir_name/WASLDAPKeyring.jks</key_file_name>
    <trust_file_name>dir_name/WASLDAPKeyring.jks</trust_file_name>
    
    dir_name 変数は、WASLDAPKeyring.jks ファイルの元の場所を識別します。
    バージョン 6.0.x の設定
    keyFileName="dir_name/WASLDAPKeyring.jks"   
    trustFileName="dir_name/WASLDAPKeyring.jks"
    
    dir_name 変数は、WASLDAPKeyring.jks ファイルの元の場所を識別します。
    バージョン 4.0.x またはバージョン 5.x の設定
    <key_file_name>${WAS_HOME}/keys/WASLDAPKeyring.jks</key_file_name>
    <trust_file_name>${WAS_HOME}/keys/WASLDAPKeyring.jks</trust_file_name>
    バージョン 6.0.x の設定
    keyFileName="${USER_INSTALL_ROOT}/keys/WASLDAPKeyring.jks"   
    trustFileName="${USER_INSTALL_ROOT}/keys/WASLDAPKeyring.jks"

    マイグレーション・ツールでは、 鍵ファイル (例えば、.jks または .kdb) を、 WebSphere Application Server の基本製品または Network Deployment 製品の対応するディレクトリーにコピーしません。 SSL 構成のマイグレーションは、 修飾鍵ストア・ファイルをバージョン 6.0.x のディレクトリーにコピーすることによって完了する必要があります。

    鍵ファイル名属性とトラスト・ファイル名属性が、 WebSphere Application Server バージョン 4.0.x (AE) またはバージョン 5.x 構成内の DummyServerKeyFile.jks ファイルを指している場合には、 鍵ファイル名属性とトラスト・ファイル名属性はバージョン 6.0.x にマイグレーションされません。 代わりに、バージョン 6.0.x のデフォルト値 ${USER_INSTALL_ROOT}/etc/DummyServerKeyFile.jks は変更されないままです。

  • サーブレット・パッケージ名は、バージョン 4.0 からバージョン 6.0 にマイグレーションする際に変更されます。

    web.xml ファイルが DefaultErrorReporter サーブレットを定義する場合、 マイグレーション・ツールは、バージョン 6.0.x のパッケージが反映されるようにクラス名を更新します。 DefaultErrorReporter サーブレットを直接使用することは推奨されなくなりました。

  • InvokerServlet および SimpleFileServlet サーブレット
    InvokerServlet および SimpleFileServlet サーブレットは、 内部サーブレットで、WebSphere Application Server バージョン 3.5 以降、公開されていません。 バージョン 3.5 より後のバージョンで web.xml ファイルを介してこれらのサーブレットを参照した場合は、 web.xml ファイルからこれらの項目を除去し、 ibm-web-ext.xmi ファイルを使用して、これらのサーブレットを使用可能または使用不可にします (serveServletsByClassnameEnabled および fileServingEnabled を使用します)。 以下の例を参照してください。
    <?xml version="1.0" encoding="UTF-8"?>
    <webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"  
    xmlns:webappext="webappext.xmi" xmlns:webapplication="webapplication.xmi"  
    xmlns:commonext.localtran="commonext.localtran.xmi"  
    	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmi:id="WebApp_ID_Ext" reloadInterval="3" reloadingEnabled="true" 
    fileServingEnabled="false" directoryBrowsingEnabled="false" 
    serveServletsByClassnameEnabled="true" preCompileJSPs="false" 
    autoRequestEncoding="false" autoResponseEncoding="false">
      <defaultErrorPage xsi:nil="true"/>
      <additionalClassPath xsi:nil="true"/>
      <webApp href="WEB-INF/web.xml#WebApp_ID"/>
      <extendedServlets xmi:id="ServletExtension_1">
        <extendedServlet href="WEB-INF/web.xml#Servlet_1"/>
      </extendedServlets>
      <extendedServlets xmi:id="ServletExtension_2">
        <markupLanguages xmi:id="MarkupLanguage_1" name="HTML" mimeType="text/html" 
        errorPage="Page_1" defaultPage="Page_2">
          <pages xmi:id="Page_2" name="Hello.page" uri="/HelloHTML.jsp"/>
          <pages xmi:id="Page_1" name="Error.page" uri="/HelloHTMLError.jsp"/>
        </markupLanguages>
        <markupLanguages xmi:id="MarkupLanguage_2" name="VXML" mimeType="text/x-vxml" 
        errorPage="Page_3" defaultPage="Page_4">
          <pages xmi:id="Page_4" name="Hello.page" uri="/HelloVXML.jsp"/>
          <pages xmi:id="Page_3" name="Error.page" uri="/HelloVXMLError.jsp"/>
        </markupLanguages>
        <markupLanguages xmi:id="MarkupLanguage_3" name="WML" mimeType="vnd.wap.wml" 
        errorPage="Page_5" defaultPage="Page_6">
          <pages xmi:id="Page_6" name="Hello.page" uri="/HelloWML.jsp"/>
          <pages xmi:id="Page_5" name="Error.page" uri="/HelloWMLError.jsp"/>
        </markupLanguages>
        <extendedServlet href="WEB-INF/web.xml#Servlet_2"/>
      </extendedServlets>
      <extendedServlets xmi:id="ServletExtension_3">
        <extendedServlet href="WEB-INF/web.xml#Servlet_3"/>
        <localTransaction xmi:id="LocalTransaction_1" unresolvedAction="Rollback"/>
      </extendedServlets>
    </webappext:WebAppExtension>
    
バージョン 5.x からバージョン 6.0.x へのマイグレーション

バージョン 5.x からバージョン 6.0.x へのマイグレーションは、 バージョン 4.0.x からのマイグレーションと比べてはるかに単純です。 両バージョンで同じ基本定義が使用されます。 この作業では、構成ファイルのバージョン 5.x からバージョン 6.0.x 構成へのマッピング、 およびインストール済みアプリケーションの新規製品へのコピーが行われます。 マイグレーション・ツールは、統合ノードのマイグレーションをサポートし、 Network Deployment ノードの完全なマイグレーションをサポートします。

EAR ファイルのマイグレーションに必要な Java ヒープ・サイズ

wsadmin ツールを使用して 5.x EAR ファイルをすべてバージョン 6.0.x にマイグレーションする場合、 WASPostUpgrade ツールは、 Java のデフォルトの最大ヒープ・サイズ値の 64 MB を使用して EAR ファイルをインストールします。

Java ヒープ・サイズの大きさが不十分なため、 マイグレーション中にバージョン 5.x EAR ファイルがインストールに失敗する場合は、 次のようなエラー・メッセージが表示されます。
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError 

Java の最大ヒープ・サイズを増やし、以下の指示に従ってアプリケーションをインストールしてください。

WebSphere Application Server バージョン 6.0.x へのアプリケーションのインストール

以下のことを前提とします。
インストール・ルート
C:¥WebSphere¥AppServer
番号記号 (###)
最大ヒープ・サイズ値
EAR_file_name
EAR ファイルの名前
app_name
アプリケーションの名前
server_name
EAR ファイルをインストールするサーバーの名前
node_name
サーバーを構成するノードの名前
コマンドは、 わかりやすくするために複数の行に分けて表示しています。
wsadmin -conntype NONE
        -javaoption 
        -Xmx###m 
        -c "$AdminApp install 
               C:¥¥WebSphere¥¥AppServer¥¥installableApps¥¥
                  EAR_file_name
        {-nodeployejb 
         -appname app_name
         -server server_name
         -node node_name}"

WebSphere Application Server Network Deployment バージョン 6.0.x へのアプリケーションのインストール

以下のことを前提とします。
インストール・ルート
C:¥WebSphere¥DeploymentManager
番号記号 (###)
最大ヒープ・サイズ値
EAR_file_name
EAR ファイルの名前
app_name
アプリケーションの名前
cluster_name
EAR ファイルをインストールしなければならないクラスターの名前
コマンドは、 わかりやすくするために複数の行に分けて表示しています。
wsadmin -conntype NONE
        -javaoption 
        -Xmx###m 
        -c "$AdminApp install 
            C:¥¥WebSphere¥¥DeploymentManager¥¥installableApps¥¥
                   EAR_file_name>
        {-nodeployejb 
         -appname app_name 
         -cluster cluster_name}"



関連タスク
製品構成のマイグレーション
タスクの概説: アプリケーションでのエンタープライズ Bean の使用
マイグレーションと共存
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:13:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cins_migconf.html