アプリケーション更新の準備設定

このページを使用して、サーバー上に既にインストール済みのエンタープライズ・アプリケーション、モジュール、またはファイルを更新します。

この管理コンソール・ページを表示するには、以下を実行します。
  1. 「アプリケーション」 > 「アプリケーション・タイプ」 > 「WebSphere エンタープライズ・アプリケーション」とクリックします。
  2. 更新を行うインストール済みアプリケーションまたはモジュールを選択します。
  3. 更新」をクリックします。
更新」をクリックすると、そのセルにデプロイされたアプリケーション・ファイルの更新を支援するページが表示されます。 アプリケーション全体を更新することも、単一モジュール、単一ファイル、 あるいはアプリケーションの一部のみを更新することもできます。新規ファイルまたはモジュールの相対パスが、 そのサーバー上に既に存在するファイルまたはモジュールの相対パスと同じである場合は、 新規ファイルまたはモジュールで既存のファイルまたはモジュールが置き換えられます。 その新規ファイルまたはモジュールがサーバー上に存在しない場合は、 デプロイ済みアプリケーションに追加されます。
更新するアプリケーション

「エンタープライズ・アプリケーション」ページで選択した、インストール済み (またはデプロイ済み) の アプリケーションの名前を指定します。

アプリケーション全体の置換

アプリケーション更新オプション」の下で、 サーバー上に既にインストール済みのアプリケーションを、新規 (更新済み) エンタープライズ・アプリケーション .ear ファイルで置き換えるように指定します。

このオプションを選択した後、以下の手順を実行します。

  1. .ear ファイルがローカルにあるのか、またはリモート・ファイル・システムにあるのか、 およびそのアプリケーションの絶対パス名を指定します。 このパスで、インストール前に更新済み .ear ファイルのロケーションを指定します。

    ブラウザーと更新済みファイルまたはモジュールが同一マシン上にある場合は (サーバーもそのマシン上にあるかないかにかかわらず)、「ローカル・ファイル・システム」を使用します。 「ローカル・ファイル・システム」はすべての更新オプションに使用可能です。

    アプリケーション・ファイルが現行セルのコンテキストのいずれかのノードにある場合は、 「リモート・ファイル・システム」を使用します。

    マルチサーバー・インストールでは、選択されたノードでノード・エージェントまたはデプロイメント・マネージャーが実行されている場合、「リモート・ファイル・システム」を使用してそのノードのファイル・システム全体をブラウズすることができます。 ブラウズ中に表示されるのは、.ear.jar.sar、または .war ファイルのみです。

    また、アプリケーション・サーバーを稼働しているマシンに既に存在するアプリケーション・ファイルを指定する場合にも、 「リモート・ファイル・システム」オプションを使用します。 例えば、フィールド値は、app_server_install_root/installableApps/test.ear のようになります。スタンドアロンの WAR モジュールをインストールする場合は、コンテキスト・ルートも指定してください。

    ヒント: アプリケーションのインストール中、アプリケーション・ファイルは通 常、ブラウザーを稼働しているクライアント・ マシンから、そのファイルをデプロイする管理コンソールを稼働しているサーバー・マシンにアップロードされます。 この場合、サーバー・マシンにアップロードするモジュールの選択には、 管理コンソールを稼働する Web ブラウザーを使用します。ただし場合によっては、アプリケーション・ファイルが、 セル内の任意のノードのファイル・システム上に常駐していることがあります。 このようなファイルをアプリケーション・サーバーでインストールする場合は、 「リモート・ファイル・システム」オプションを使用してください。
  2. スタンドアロンの Web アプリケーション (WAR) または Session Initiation Protocol (SIP) モジュール (SAR) をインストールしている場合は、その WAR ファイルまたは SAR ファイルのコンテキスト・ルートを指定します。

    コンテキスト・ルートは、(WAR ファイルからの) 定義済みのサーブレット・マッピングと組み合わされて、ユーザーがサーブレットへのアクセス時に入力する完全 URL を構成します。例えば、 コンテキスト・ルートが /gettingstarted でサーブレット・マッピングが MySession の場合、 URL は http://host:port/gettingstarted/MySession となります。

  3. 次へ」をクリックして、アプリケーション・ファイル更新のウィザードを表示します。 更新ウィザードは、インストール・ウィザードに似ており、 アプリケーション・バインディング情報を指定または編集するためのフィールドがあります。 必要に応じて、更新ウィザードのステップに従います。

全アプリケーションが更新されると、古いアプリケーションはアンインストールされ、 新規アプリケーションがインストールされます。 構成変更が保存され、その後同期化されると、アプリケーション・ファイルはアプリケーションが稼働するノードで展開されます。 更新の間アプリケーションがノードで稼働していると、 アプリケーションは停止し、アプリケーション・ファイルが更新され、アプリケーションが始動します。

単一モジュールの置換または追加

アプリケーション更新オプション」の下で、 インストール済みアプリケーションでモジュールを置き換える、 またはそのアプリケーションにモジュールを追加するように指定します。

このモジュールは、Web モジュール (.war ファイル)、エンタープライズ Bean モジュール (EJB .jar ファイル)、SIP モジュール (.sar ファイル )、またはリソース・アダプター・モジュール (コネクター .rar ファイル) にすることができます。

このオプションを選択した後、このモジュールがローカルにあるのか、またはリモート・ファイル・システムにあるのか、 およびそのモジュールの絶対パス名を指定します。 このパスで、インストール前に更新済みモジュールのロケーションを指定します。 「ローカル・ファイル・システム」および「リモート・ファイル・システム」については、 前述の『アプリケーション全体の置換』の説明を参照してください。

モジュールを置き換える場合は、指定した相対パス (モジュール URI) が、インストール済みアプリケーション内の更新対象モジュールのパスと一致する必要があります。

インストール済みアプリケーションに新規モジュールを追加する場合は、指定した相対パスが、インストール済みアプリケーション内のモジュールのパスと一致しない ようにする必要があります。 新規モジュールで望ましいパスを値に指定してください。

スタンドアロンの Web モジュールまたは SIP モジュールをインストールする場合は、「コンテキスト・ルート」の値を指定します。 コンテキスト・ルートは、(.war ファイルからの) 定義済みサーブレット・マッピングと組み合わされて、 ユーザーがサーブレットへのアクセス時に入力する完全 URL を構成します。 例えば、 コンテキスト・ルートが /gettingstarted でサーブレット・マッピングが MySession の場合、 URL は http://host:port/gettingstarted/MySession となります。

次に、情報の指定を要求するインストール・オプションのみを表示するか、 すべてのインストール・オプションを表示するかを指定します。

モジュール上で必要な情報を指定した後、「次へ」をクリックして、 アプリケーション・ファイルを更新するためのウィザードを表示します。 更新ウィザードは、インストール・ウィザードに似ており、 モジュール・バインディング情報を指定または編集するためのフィールドがあります。 必要に応じて、更新ウィザードのステップに従います。

単一モジュールが追加または更新された後で構成変更が保存されると、 新規または更新済みモジュールが、この製品の構成リポジトリー内のデプロイされたアプリケーションに保存されます。これらの変更がノードと同期化されると、モジュールはノードのファイル・システムに追加されるか、または更新されます。 モジュールが追加または更新されるときに、アプリケーションがノードで稼働している場合、 次のうちの 1 つが実行されます。
  • Web モジュールに対する更新の場合、稼働している Web モジュールは停止し、 Web モジュール・ファイルが更新された後、Web モジュールが始動します。
  • モジュール追加の場合、追加されたモジュールが、アプリケーションがノードで展開された後、稼働しているアプリケーション・サーバーで始動します。 アプリケーションの再始動は必要ありません。
  • すべてのモジュールがクラス・ローダーを共有するように、 アプリケーションのクラス・ローダー・ポリシーが Single に設定されている場合、 全アプリケーションが停止し、モジュール・レベル変更のために再始動します。
  • この製品で構成されるセキュリティー・プロバイダーが動的更新をサポートしない場合、アプリケーション全体が停止し、モジュール・レベルを変更するために再始動します。
  • モジュールに対するそのほかすべての更新の場合、アプリケーション全体が停止し、 モジュール・ファイルが更新された後、アプリケーション全体が始動します。
単一ファイルの置換または追加

アプリケーション更新オプション」の下で、 インストール済みアプリケーション内でファイルを置き換えるか、 このアプリケーションにファイルを追加するように指定します。

このオプションを使用して、.ear.war.sar.rar、 または、場合によって .jar ファイル以外の、アプリケーションによって使用されるファイルを更新します。 このオプションを使用すると、 アプリケーションでモジュールとして定義されていない .jar ファイルを追加または更新できます。.ear ファイルを更新するには、「アプリケーション全体の置換」オプションを使用します。 アプリケーションでモジュールとして定義されている .war ファイル、.sar ファイル、.rar ファイル、または .jar ファイルを更新するには、「単一モジュールの置換または追加」オプションを使用します。

このオプションを選択した後、このファイルがローカルにあるのか、リモート・ファイル・システムにあるのか、 およびそのファイルの絶対パス名を指定します。 このパスで、インストール前に更新済みファイルのロケーションを指定します。 「ローカル・ファイル・システム」および「リモート・ファイル・システム」については、 『アプリケーション全体の置換』の説明を参照してください。

相対パス (モジュール URI) の場合、.ear ファイルのルートから開始するファイルへの相対パスを指定します。例えば、ファイルがモジュール hello.jarcom/company/greeting.class にある場合、相対パス hello.jar を指定します。

ファイルを置き換えるには、相対パスがインストール済みアプリケーション内の更新対象ファイルの相対パスと一致する必要があります。

インストール済みアプリケーションに新規ファイルを追加する場合は、相対パスがインストール済みアプリケーション内の既存のファイルの相対パスと一致しない ようにする必要があります。新規ファイルで望ましいパスを値に指定してください。

ファイル・システムおよび相対パスを指定した後で、「次へ」をクリックします。

単一ファイルが追加または更新された後で構成変更が保存されると、 新規または更新済みファイルが、この製品の構成リポジトリー内の デプロイされたアプリケーションに保存されます。 これらの変更がノードと同期化されると、ファイルはノードのファイル・システムに追加されるか、または更新されます。 ファイルが追加または更新されるときに、アプリケーションがノードで稼働している場合、 次のうちの 1 つが実行されます。
  • ファイルがアプリケーション・メタデータの有効範囲 (META-INF ディレクトリー) で追加されるか、 またはアプリケーションの有効範囲または非 Web モジュールで更新される場合、 アプリケーション全体が停止し、ファイルが追加または更新された後、アプリケーション全体が再始動します。
  • ファイルがアプリケーション・メタデータの有効範囲外 (META-INF ディレクトリー外ですが、どのモジュール内でもない) で追加されると、稼働しているアプリケーションを再始動することなく、変更がファイル・システムに保存されます。
  • ファイルが Web モジュール・メタデータ (META-INF または WEB-INF ディレクトリー) に追加または更新されると、稼働している Web モジュールは停止し、Web モジュール・ファイルは追加または更新されて、 Web モジュールが始動します。
  • Web モジュールのその他すべてのファイルの場合、ファイルは、アプリケーションまたはそのコンポーネントを停止することなく、ノードのファイル・システムで追加または更新されます。
複数ファイルの置換、追加または削除

アプリケーション更新オプション」の下で、圧縮ファイルをアップロードすることによって、 インストール済みアプリケーションの複数のファイルを更新するように指定します。 圧縮ファイルの内容によっては、このオプションを使用するだけで、 インストール済みアプリケーションでのファイルの置換、新規ファイルの追加、およびファイルの削除を行うことができます。 圧縮ファイル内の各項目は単一のファイルとして処理され、圧縮ファイルのルートからのファイルのパスは、インストール済みアプリケーションのファイルの相対パスとして処理されます。

このオプションを選択した後、この圧縮ファイルがローカルにあるのか、またはリモート・ファイル・システムにあるのか、 およびこの圧縮ファイルの絶対パス名を指定します。 圧縮ファイルをアップロードしていて、リモート・ブラウズが .ear.sar.war または .jar ファイルにしか機能しないため、「ローカル・ファイル・システム」を使用する可能性があります。 .zip または .gzip などの有効な圧縮ファイル・フォーマットを指定します。このパスによって、圧縮ファイルのロケーションが、インストール前に提供されます。 このオプションにより、圧縮ファイルが unzip されて、インストール済みアプリケーションのディレクトリーに格納されます。

ブラウザーと更新済みファイルまたはモジュールが同一マシン上にある場合は (サーバーもそのマシン上にあるかないかにかかわらず)、「ローカル・ファイル・システム」を使用します。 「ローカル・ファイル・システム」はすべての更新オプションに使用可能です。

ファイルを置き換えるには、圧縮ファイル内のファイルの相対パスが、 インストール済みアプリケーション上の更新されるファイルの相対パスと同じでなければなりません。

インストール済みアプリケーションに新規ファイルを追加するには、圧縮ファイル内のファイルの相対パスが、インストール済みアプリケーション内のファイルの相対パスと異なっていなければなりません。

インストール済みアプリケーションにあるファイルの相対パスは、 モジュールの相対パス (ファイルがモジュール内にある場合) と / によって区切られるモジュールのルートからのファイルの相対パスの連結によって形成されます。

インストール済みアプリケーションからファイルを除去するには、任意のアーカイブ有効範囲で META-INF/ibm-partialapp-delete.props という名前がついたファイルを使用して、圧縮ファイルのメタデータを指定します。 ibm-partialapp-delete.props ファイルは ASCII ファイルでなければなりません。 ASCII ファイルでは、そのアーカイブ内の削除するファイルを、1 行に 1 項目ずつリストします。 この項目には、複数のファイルを識別する正規表現などのストリング・パターンを含めることができます。 削除されるファイルのファイル・パスは、META-INF/ibm-partialapp-delete.props ファイルを持つアーカイブ・パスに対する相対パスでなければなりません。
削除するファイルのレベル 圧縮ファイルに含めるメタデータ .props ファイル
アプリケーション 圧縮ファイル内に META-INF/ibm-partialapp-delete.props を含めます。 メタデータ .props ファイルで、削除するファイルをリストします。 ファイル・パスは、META-INF/ibm-partialapp-delete.props ファイルのロケーションに対する相対パスです。

例えば、my.ear ファイルのルートから utils/config.xmi という名前のファイルを削除するには、 META-INF/ibm-partialapp-delete.props ファイルに行 utils/config.xmi を含めます。

モジュール 圧縮ファイルに module_uri/META-INF/ibm-partialapp-delete.props を含めます。

モジュールから 1 つのファイルを削除するには、 メタデータ .props ファイルにモジュールに対するファイル・パスを含めます。 例えば、my.jar モジュールから a/b/c.jsp を削除するには、圧縮ファイルの my.jar/META-INF/ibm-partialapp-delete.props ファイルに a/b/c.jsp を含めます。

1 つのモジュール内で複数ファイルを削除するには、1 行に 1 つの記入項目で、メタデータ .props ファイルで削除されるファイルをリストします。 例えば、my.war ファイルからすべての JavaServer Pages (.jsp ファイル) を削除するには、 my.war/META-INF/ibm-partialapp-delete.props ファイルに行 .*jsp を含めます。 この行は正規表現 .*jsp を使用しており、my.war 内のすべての .jsp ファイルを識別します。

単一の部分アプリケーション・ファイルを使用して、複数のファイルを追加、削除、および更新することができます。

ファイル・システム・パスを指定した後で、「次へ」をクリックします。

アプリケーションの一部が更新された後で構成変更が保存されると、 新規または更新済みアプリケーション・ファイルが、WebSphere® Application Server 構成リポジトリー内のデプロイされたアプリケーションに保存されます。 これらの変更がノードと同期化されると、ファイルはノードのファイル・システムに追加されるか、または更新されます。 一部のアプリケーション・オプションは複数のファイルを更新するため、 再始動されるアプリケーション・コンポーネントは一部のアプリケーションで個々のファイルを使用して決定されます。

一部のアプリケーション圧縮ファイルの記入項目の例は、次のとおりです。

util.jar
META-INF/ibm-partialapp-delete.props
foo.jar/com/mycomp/xyz.class
xyz.war/welcome.jsp
xyz.war/WEB-INF/web.xml
webmod.war/META-INF/ibm-partialapp-delete.props

この例では、META-INF/ibm-partialapp-delete.props ファイルが .*.dat および tools/test.jar ファイルを含みます。webmod.war/META-INF/ibm-partialapp-delete.props ファイルは com/test/.*.jsp および WEB-INF/test.xmi ファイルを含みます。

一部のアプリケーション更新オプションは、以下を行います。
  • デプロイされたアプリケーションで util.jar を追加または置き換えます。
  • デプロイされたアプリケーションの foo.jar ファイル内で com/mycomp/xyz.class を追加または置き換えます。
  • アプリケーションから *.dat ファイルを削除しますが、モジュールからは削除しません。
  • アプリケーションから tools/test.jar を削除します。
  • デプロイされたアプリケーションの xyz.war モジュール内で welcome.jsp を追加または置き換えます。
  • デプロイされたアプリケーションの xyz.war モジュール内で WEB-INF/web.xml を置き換えます。
  • webmod.war モジュールから com/test/*.jsp を削除します。
  • webmod.war モジュールから WEB-INF/test.xmi を削除します。

META-INF/ibm-partialapp-delete.props ファイルでは、正規表現のメタキャラクターをエスケープします。 例えば、クラス Abc の内部クラスを削除する場合、 正規表現 Abc¥$.* を使用します。ここで、$ は正規表現のメタキャラクターで、円記号 (¥) でエスケープされています。

META-INF/ibm-partialapp-delete.props ファイルには、 以下のようなテキストを含めることができます。

.*.dat

webmod.war/META-INF/ibm-partialapp-delete.props:
com/test/.*.jsp
WEB-INF/test.xmi



マーク付きのリンク (オンライン) では、インターネットにアクセスする必要があります。

関連概念
関連タスク
関連資料
エンタープライズ・アプリケーション・コレクション


ファイル名: urun_rapp_update.html