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

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

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

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

マイグレーションでは、常に単一のインスタンスを、 同一マシン上または別のマシン上の別の単一インスタンス (プロファイル) にマイグレーションします。 Network Deployment 製品のインフォメーション・センターを開いて、 マイグレーション・ツールがモデル、クローン、サーバー・グループ、クラスター、 および Lightweight Third Party Authentication (LTPA) セキュリティー設定をマップする方法を習得します。

多くのマイグレーション・シナリオが考えられます。 バージョン 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 では意味や有効範囲が異なるためです。

デフォルトのサーバー

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

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 リソースについて詳しくは、メッセージング・リソースについての学習 を参照してください。

名前バインディング
バージョン 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 はマイグレーションされません。

サンプル

旧バージョンからのサンプルのマイグレーションはありません。 同等のバージョン 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 で LTPA 認証を使用するグローバル・セキュリティーが、WebSphere Application Server 基本製品にマイグレーションされます。ただし、グローバル・セキュリティーは、 バージョン 4.0.x では使用可能化されていても、 バージョン 6.0.x へのマイグレーション時に使用不可になります (バージョン 5.x からのマイグレーション時にはセキュリティーは使用不可になりません)。

バージョン 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 のプロパティー値に合わせて、これらの設定値を変更してください。

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

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 22, 2008 12:07:38 AM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/cins_migconf.html