test

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 管理ガイド

第 2 章 アプリケーションの配備

この章では、Application Server に J2EE アプリケーションを配備 (インストール) する方法について説明します。この章には次の節が含まれています。

配備について

配備のライフサイクル

Application Server をインストールしてドメインを起動したら、J2EE アプリケーションとモジュールを配備 (インストール) できます。配備中およびアプリケーションの変更の際、アプリケーションとモジュールには次のような作業を行います。

  1. 初期の配備

    アプリケーションまたはモジュールを配備する前に、ドメインを起動します。

    アプリケーションまたはモジュールを、特定のスタンドアロンサーバーインスタンスまたはクラスタに配備 (インストール) します。アプリケーションとモジュールはアーカイブファイルにパッケージ化されているので、配備中はアーカイブファイル名を指定します。デフォルトでは、デフォルトのサーバーインスタンス server に配備されます。

    サーバーインスタンスまたはクラスタに配備する場合、アプリケーションやモジュールはドメインの中央リポジトリ内に存在し、ターゲットとして配備したクラスタまたはサーバーインスタンスによって参照されます。

    管理コンソールではなく asadmin deploy コマンドを使用して、ドメインに配備することもできます。アプリケーションやモジュールをドメインだけに配備する場合、アプリケーションやモジュールはドメインの中央リポジトリ内に存在しますが、「配備のライフサイクル」の説明に従って参照を追加するまでは、サーバーインスタンスまたはクラスタによって参照されません。

    配備は動的です。アプリケーションを使用可能にするために、アプリケーションまたはモジュールの配備後にサーバーインスタンスを再起動する必要はありません。再起動しても、すべての配備アプリケーションとモジュールはそのまま配備され、使用することができます。

  2. 有効化または無効化

    デフォルトでは、配備されているアプリケーションやモジュールは有効になっています。つまり、アクセス可能なサーバーインスタンスやクラスタに配備されている場合、実行可能で、クライアントがアクセスできる状態になっています。アクセスを抑制するには、アプリケーションやモジュールを無効化します。無効化されたアプリケーションやモジュールはドメインからアンインストールされてはいないので、配備後は簡単に有効化できます。

  3. 配備されているアプリケーションやモジュールのターゲットの追加または削除

    配備の完了したアプリケーションやモジュールは、中央リポジトリ内に存在し、複数のサーバーインスタンスやクラスタによる参照が可能になります。最初は、ターゲットとして配備したサーバーインスタンスやクラスタがアプリケーションやモジュールを参照します。

    アプリケーションやモジュールの配備後、それを参照するサーバーインスタンスやクラスタを変更するには、管理コンソールを使用してアプリケーションやモジュールのターゲットを変更するか、または asadmin ツールを使用してアプリケーションの参照を変更します。アプリケーション自体は中央リポジトリに格納されるため、ターゲットを追加または削除すると、さまざまなターゲット上にある同じバージョンのアプリケーションが追加または削除されます。ただし、複数のターゲットに配備されているアプリケーションを、1 つのターゲット上で有効にして、ほかのターゲット上で無効にすることができます。したがって、アプリケーションがあるターゲットによって参照されていても、そのターゲット上で有効にされないかぎり、ユーザーはアプリケーションを使用できません。

  4. 再配備

    配備されているアプリケーションやモジュールを置換するには、これらを再配備します。再配備すると、以前に配備されたアプリケーションやモジュールは配備が自動的に取り消され、新しいアプリケーションやモジュールと置き換えられます。

    管理コンソールから再配備した場合、再配備されたアプリケーションやモジュールはドメインに配備されます。動的再設定が有効になっている場合、アプリケーションやモジュールを参照するスタンドアロンまたはクラスタ化されたすべてのサーバーインスタンスは、自動的に新しいバージョンを受信します。asadmin deploy コマンドを使用して再配備する場合、ターゲットとして domain を指定します。

    本稼動環境では、段階的アップグレードを使用して、処理が中断されない状態でアプリケーションをアップグレードします。詳細については、「段階的アップグレードについて」を参照してください。

  5. 配備取消し

    アプリケーションまたはモジュールをアンインストールするには、これらの配備を取り消します。

J2EE アーカイブファイルのタイプ

ソフトウェアプロバイダは、アプリケーションやモジュールをアーカイブファイルにパッケージ化します。アプリケーションやモジュールを配備するには、アーカイブファイルの名前を指定します。アーカイブファイルのコンテンツと構造は J2EE プラットフォームの仕様で定義されています。J2EE アーカイブファイルの種類は次のとおりです。

ソフトウェアプロバイダは、アプリケーションを 1 つの EAR ファイルまたは個別の WAR、EJB JAR、およびアプリケーションクライアント JAR ファイルにアセンブルすることが可能です。管理ツールでは、配備ページとコマンドはすべての種類のファイルで同じです。

ネーミング規則

1 つのドメイン内では、配備されているアプリケーションやモジュールの名前が一意である必要があります。

異なるタイプのモジュールが、アプリケーション内で同じ名前を使用できます。アプリケーションが配備されると、個々のモジュールを保持するディレクトリの名前には _jar、_war、および _rar サフィックスが使用されます。アプリケーション内の同じタイプのモジュールは、一意の名前にする必要があります。また、データスキーマのファイル名は、アプリケーション内で一意の名前にする必要があります。

モジュールのファイル名、EAR ファイル名、ejb-jar.xml ファイルの <module-name> 部分に見られるモジュール名、および ejb-jar.xml ファイルの <ejb-name> 部分に見られる EJB 名には、Java パッケージと同様のネーミングスキームを使用することをお勧めします。このパッケージと同様のネーミングスキームの使用により、名前の競合を防げます。このネーミング方法の利点は、Application Server だけでなく、ほかの J2EE Application Server にも当てはまります。

EJB コンポーネントの JNDI 検索名も一意である必要があります。一貫性のあるネーミング規則の確立が役立つ場合があります。たとえば、アプリケーション名とモジュール名を EJB 名に追加するのは、名前を一意にする 1 つの方法です。この場合、mycompany.pkging.pkgingEJB.MyEJB は、アプリケーション pkging.ear にパッケージ化されたモジュール pkgingEJB.jar 内にある EJB の JNDI 名を表します。

パッケージとファイル名に、オペレーティングシステムでは不正なスペースや文字を含めないようにする必要があります。

アプリケーションの配備に関する管理コンソールタスク

Procedureエンタープライズアプリケーションを配備する

エンタープライズアプリケーションは、WAR ファイルや EJB JAR ファイルなど、任意のタイプの J2EE スタンドアロンモジュールを含むアーカイブファイルの一種である EAR ファイルにパッケージ化されています。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 「エンタープライズアプリケーション」ノードを選択します。

  3. 「エンタープライズアプリケーション」ページで、「配備」をクリックします。

  4. 「配備」ページで、EAR ファイルを配備する場所を指定します。

    サーバーマシンとは、Application Server のドメイン管理サーバーを実行しているホストです。クライアントマシンとは、ブラウザを介して管理コンソールを表示しているホストです。

    • ファイルがクライアントマシンにある場合、またはクライアントマシンからファイルにアクセス可能な場合は、ラジオボタンをクリックして、Application Server にアップロードするパッケージファイルを指定します。

      「ブラウズ」をクリックしてファイルを検索するか、またはファイルへの完全パスを入力します。

    • ファイルがサーバーマシンにある場合、または分割ディレクトリからパッケージ化されていないアプリケーションを配備する場合は、ラジオボタンをクリックして、サーバーからアクセス可能なパッケージファイルまたはディレクトリパスを指定します。

      ファイルまたはディレクトリへの完全パス名を入力します。分割ディレクトリからの配備は高度な開発者用なので、本稼働環境ではお勧めできません。

  5. 「次へ」をクリックして「Enterprise アプリケーションを配備」ページを表示します。

  6. 「Enterprise アプリケーションを配備」ページで、アプリケーションの設定値を指定します。

    1. 「アプリケーション名」フィールドで、ファイル名のプレフィックスであるデフォルト名を保持するか、または別の名前を入力します。

      ファイルのアップロードを選択した場合は、デフォルト名が表示されます。アプリケーション名は一意である必要があります。

    2. 配備後には利用できないようにアプリケーションを無効にする場合は、「無効」ラジオボタンをオンにします。

      デフォルトでは、アプリケーションは配備すると同時に利用可能になります。

    3. アプリケーションがすでに配備されている場合は、「再配備」チェックボックスを選択して、再配備します。そうでない場合、エラーが表示されます。

      また、別のアプリケーション名を選択して、新しい名前で配備することもできます。

    4. 配備の前にファイルの構造やコンテンツを検証するには、「ベリファイア」チェックボックスにチェックマークを付けます。

      大きなアプリケーションの検証は時間がかかる可能性があります。ファイルの破壊や移行不能が想定される場合は検証を行なってください。

    5. JSP ページを事前にコンパイルするには、「JSP」チェックボックスにチェックマークを付けます。

      このチェックボックスを選択しない場合、JSP ページは最初のアクセスの実行時にコンパイルされます。コンパイルは時間がかかる可能性があるので、本稼働環境ではこのチェックボックスにチェックマークを付けてください。

    6. 高可用性の設定を選択します。

      アプリケーションの高可用性を有効にするには、「可用性」チェックボックスを選択します。1 つのアプリケーションで可用性を有効にする場合、それより高いすべてのレベル (指定した設定および Web コンテナまたは EJB コンテナ) も同様に有効にする必要があります。

    7. アプリケーションを配備するターゲットを選択します。

      利用可能なターゲットのリストから、1 つまたは複数のターゲットを選択して「追加」をクリックします。ターゲットを選択しない場合、アプリケーションはデフォルトのサーバーインスタンス server に配備されます。

      再配備の場合は、ターゲットを選択しないでください。ここで選択した内容は、すべて無視されます。クラスタやスタンドアロンインスタンスの動的再設定が有効になっている場合、配備されているアプリケーションを参照する、ターゲットのクラスタ化またはスタンドアロンのすべてのサーバーインスタンスは、新しく再配備されたアプリケーションを自動的に参照します。サービスを中断せずにアプリケーションを再配備する方法の詳細については、「アプリケーションのアップグレード」を参照してください。

    8. RMI スタブを生成するかどうかを選択します。

      RMI スタブの生成を選択すると、静的 RMI-IIOP スタブが生成され、クライアント JAR ファイルに配置されます。

  7. 「了解」をクリックしてアプリケーションを配備します。

同機能を持つ asadmin コマンド

deploy

Procedure配備されているエンタープライズアプリケーションを編集する

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 「エンタープライズアプリケーション」ノードを展開します。

  3. 配備されているアプリケーションのノードを選択します。

  4. 「エンタープライズアプリケーション」ページで、説明を変更します。

  5. 「Enterprise Edition」で、高可用性を有効または無効にします。

    1 つのアプリケーションで可用性を有効にする場合、それより高いすべてのレベル (指定した設定および Web コンテナまたは EJB コンテナ) も同様に有効にする必要があります。

ProcedureWeb アプリケーションを配備する

Web アプリケーションは、サーブレットや JSP ファイルなどのコンポーネントを含むアーカイブファイルの一種である WAR ファイルにパッケージ化されています。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 「Web アプリケーション」ノードを選択します。

  3. 「Web アプリケーション」ページで、「配備」をクリックします。

  4. 「配備」ページで、WAR ファイルを配備する場所を指定します。

    サーバーマシンとは、Application Server のドメイン管理サーバーを実行しているホストです。クライアントマシンとは、ブラウザを介して管理コンソールを表示しているホストです。

    • ファイルがクライアントマシンにある場合、またはクライアントマシンからファイルにアクセス可能な場合は、ラジオボタンをクリックして、Application Server にアップロードするパッケージファイルを指定します。

      「ブラウズ」をクリックしてファイルを検索するか、またはファイルへの完全パスを入力します。

    • ファイルがサーバーマシンにある場合、または分割ディレクトリからパッケージ化されていないアプリケーションを配備する場合は、ラジオボタンをクリックして、サーバーからアクセス可能なパッケージファイルまたはディレクトリパスを指定します。

      ファイルまたはディレクトリへの完全パス名を入力します。分割ディレクトリからの配備は高度な開発者用なので、本稼働環境ではお勧めできません。

  5. 「次へ」をクリックして「Web アプリケーションを配備」ページを表示します。

  6. 「Web アプリケーションを配備」ページで、アプリケーションの設定を指定します。

    1. 「アプリケーション名」フィールドで、ファイル名のプレフィックスであるデフォルト名を保持するか、または別の名前を入力します。

      ファイルのアップロードを選択した場合は、デフォルト名が表示されます。アプリケーション名は一意である必要があります。

    2. 「コンテキストルート」フィールドに、Web アプリケーションを識別する文字列を入力します。

      Web アプリケーションの URL では、コンテキストルートはポート番号の直後に続きます (http://host:port/context-root/...)。コンテキストルートがスラッシュで始まるようにしてください。たとえば次のようにします。/hello

    3. 配備後には利用できないようにアプリケーションを無効にする場合は、「無効」ラジオボタンをオンにします。

      デフォルトでは、アプリケーションは配備すると同時に利用可能になります。

    4. アプリケーションがすでに配備されている場合は、「再配備」チェックボックスを選択して、再配備します。そうでない場合、エラーが表示されます。

      また、別のアプリケーション名を選択して、新しい名前で配備することもできます。

    5. 配備の前にファイルの構造やコンテンツを検証するには、「ベリファイア」チェックボックスにチェックマークを付けます。

      大きなアプリケーションの検証は時間がかかる可能性があります。ファイルの破壊や移行不能が想定される場合は検証を行なってください。

    6. JSP ページを事前にコンパイルするには、「JSP」チェックボックスにチェックマークを付けます。

      このチェックボックスを選択しない場合、JSP ページは最初のアクセスの実行時にコンパイルされます。コンパイルは時間がかかる可能性があるので、本稼働環境ではこのチェックボックスにチェックマークを付けてください。

    7. 高可用性の設定を選択します。

      アプリケーションの高可用性を有効にするには、「可用性」チェックボックスを選択します。1 つのアプリケーションで可用性を有効にする場合、それより高いすべてのレベル (指定した設定および Web コンテナまたは EJB コンテナ) も同様に有効にする必要があります。

    8. アプリケーションを配備するターゲットを選択します。

      利用可能なターゲットのリストから、1 つまたは複数のターゲットを選択して「追加」をクリックします。ターゲットを選択しない場合、アプリケーションはデフォルトのサーバーインスタンス server に配備されます。

      再配備の場合は、ターゲットを選択しないでください。ここで選択した内容は、すべて無視されます。クラスタやスタンドアロンインスタンスの動的再設定が有効になっている場合、配備されているアプリケーションを参照する、ターゲットのクラスタ化またはスタンドアロンのすべてのサーバーインスタンスは、新しく再配備されたアプリケーションを自動的に参照します。サービスを中断せずにアプリケーションを再配備する方法の詳細については、「段階的アップグレードについて」を参照してください。

    9. RMI スタブを生成するかどうかを選択します。

      RMI スタブの生成を選択すると、静的 RMI-IIOP スタブが生成され、クライアント JAR ファイルに配置されます。

  7. 「了解」をクリックしてアプリケーションを配備します。

同機能を持つ asadmin コマンド

deploy

Procedure配備されている Web アプリケーションを起動する

アプリケーションを配備すると、管理コンソールから起動することができます。アプリケーションを起動するには、サーバーと HTTP リスナーが実行されている必要があります。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 「Web アプリケーション」をクリックします。

  3. Web アプリケーションの起動リンクをクリックします。

  4. 「Web アプリケーションへのリンク」ページのリンクをクリックして、アプリケーションを起動します。

ProcedureEJB モジュールを配備する

EJB モジュールは、EJB JAR ファイルとも呼ばれ、Enterprise JavaBeans を含んでいます。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 「EJB モジュール」ノードを選択します。

  3. 「EJB モジュール」ページで、「配備」をクリックします。

  4. 「配備」ページで、JAR ファイルを配備する場所を指定します。

    サーバーマシンとは、Application Server のドメイン管理サーバーを実行しているホストです。クライアントマシンとは、ブラウザを介して管理コンソールを表示しているホストです。

    • ファイルがクライアントマシンにある場合、またはクライアントマシンからファイルにアクセス可能な場合は、ラジオボタンをクリックして、Application Server にアップロードするパッケージファイルを指定します。

      「ブラウズ」をクリックしてファイルを検索するか、またはファイルへの完全パスを入力します。

    • ファイルがサーバーマシンにある場合、または分割ディレクトリからパッケージ化されていないアプリケーションを配備する場合は、ラジオボタンをクリックして、サーバーからアクセス可能なパッケージファイルまたはディレクトリパスを指定します。

      ファイルまたはディレクトリへの完全パス名を入力します。分割ディレクトリからの配備は高度な開発者用なので、本稼働環境ではお勧めできません。

  5. 「次へ」をクリックして「EJB モジュールを配備」ページを表示します。

  6. 「EJB モジュールを配備」ページで、モジュールの設定を指定します。

    1. 「アプリケーション名」フィールドで、ファイル名のプレフィックスであるデフォルト名を保持するか、または別の名前を入力します。

      ファイルのアップロードを選択した場合は、デフォルト名が表示されます。アプリケーション名は一意である必要があります。

    2. 配備後には利用できないようにモジュールを無効にする場合は、「無効」ラジオボタンをオンにします。

      デフォルトでは、モジュールは配備すると同時に利用可能になります。

    3. モジュールがすでに配備されている場合は、「再配備」チェックボックスを選択して、再配備します。そうでない場合は、エラーが表示されます。

      また、別のアプリケーション名を選択して、新しい名前で配備することもできます。

    4. 配備の前にファイルの構造やコンテンツを検証するには、「ベリファイア」チェックボックスにチェックマークを付けます。

      大きなアプリケーションの検証は時間がかかる可能性があります。ファイルの破壊や移行不能が想定される場合は検証を行なってください。

    5. 高可用性の設定を選択します。

      モジュールの高可用性を有効にするには、「可用性」チェックボックスを選択します。1 つのモジュールで可用性を有効にする場合、それより高いすべてのレベル (指定した設定および Web コンテナまたは EJB コンテナ) も同様に有効にする必要があります。

    6. モジュールを配備するターゲットを選択します。

      利用可能なターゲットのリストから、1 つまたは複数のターゲットを選択して「追加」をクリックします。ターゲットを選択しない場合、モジュールはデフォルトのサーバーインスタンス server に配備されます。

      再配備の場合は、ターゲットを選択しないでください。ここで選択した内容は、すべて無視されます。クラスタやスタンドアロンインスタンスの動的再設定が有効になっている場合、配備されているモジュールを参照する、ターゲットのクラスタ化またはスタンドアロンのすべてのサーバーインスタンスは、新しく再配備されたモジュールを自動的に参照します。サービスを中断せずにモジュールを再配備する方法の詳細については、「段階的アップグレードについて」を参照してください。

    7. RMI スタブを生成するかどうかを選択します。

      RMI スタブの生成を選択すると、静的 RMI-IIOP スタブが生成され、クライアント JAR ファイルに配置されます。

  7. 「了解」をクリックしてモジュールを配備します。

同機能を持つ asadmin コマンド

deploy

Procedureコネクタモジュールを配備する

コネクタはリソースアダプタとも呼ばれ、RAR ファイルというアーカイブファイルの一種にパッケージ化されています。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 「コネクタモジュール」ノードを選択します。

  3. 「コネクタモジュール」ページで、「配備」をクリックします。

  4. 「配備」ページで、RAR ファイルを配備する場所を指定します。

    サーバーマシンとは、Application Server のドメイン管理サーバーを実行しているホストです。クライアントマシンとは、ブラウザを介して管理コンソールを表示しているホストです。

    • ファイルがクライアントマシンにある場合、またはクライアントマシンからファイルにアクセス可能な場合は、ラジオボタンをクリックして、Application Server にアップロードするパッケージファイルを指定します。

      「ブラウズ」をクリックしてファイルを検索するか、またはファイルへの完全パスを入力します。

    • ファイルがサーバーマシンにある場合、またはパッケージ化されていないモジュールを分割ディレクトリから配備する場合は、ラジオボタンをクリックして、サーバーからアクセス可能なパッケージファイルまたはディレクトリパスを指定します。

      ファイルまたはディレクトリへの完全パス名を入力します。分割ディレクトリからの配備は高度な開発者用なので、本稼働環境ではお勧めできません。

  5. 「次へ」をクリックして「コネクタモジュールを配備」ページを表示します。

  6. 「コネクタモジュールを配備」ページで、モジュールの設定を指定します。

    1. 「アプリケーション名」フィールドで、ファイル名のプレフィックスであるデフォルト名を保持するか、または別の名前を入力します。

      ファイルのアップロードを選択した場合は、デフォルト名が表示されます。アプリケーション名は一意である必要があります。

    2. 「スレッドプール ID」フィールドで、配備するリソースアダプタのスレッドプールを指定します。

      デフォルトでは、Application Server は、デフォルトスレッドプールのすべてのリソースアダプタからの作業要求を処理します。このフィールドを使用して、特定のユーザーが作成したスレッドプールを関連付け、リソースアダプタからの作業要求を処理します。

    3. 配備後には利用できないようにモジュールを無効にする場合は、「無効」ラジオボタンをオンにします。

      デフォルトでは、モジュールは配備すると同時に利用可能になります。

      コネクタモジュールを有効または無効にすると、コネクタリソースとそのモジュールをポイントする接続プールも有効または無効にできます。

    4. モジュールがすでに配備されている場合は、「再配備」チェックボックスを選択して、再配備します。そうでない場合は、エラーが表示されます。

      また、別のアプリケーション名を選択して、新しい名前で配備することもできます。

    5. 配備の前にファイルの構造やコンテンツを検証するには、「ベリファイア」チェックボックスにチェックマークを付けます。

      大きなアプリケーションの検証は時間がかかる可能性があります。ファイルの破壊や移行不能が想定される場合は検証を行なってください。

    6. リソースアダプタに追加プロパティーが指定されている場合は、それらが表示されます。

      この表を使用して、これらのプロパティーのデフォルト値を変更します。

    7. モジュールを配備するターゲットを選択します。

      利用可能なターゲットのリストから、1 つまたは複数のターゲットを選択して「追加」をクリックします。ターゲットを選択しない場合、モジュールはデフォルトのサーバーインスタンス server に配備されます。

      再配備の場合は、ターゲットを選択しないでください。ここで選択した内容は、すべて無視されます。クラスタやスタンドアロンインスタンスの動的再設定が有効になっている場合、配備されているモジュールを参照する、ターゲットのクラスタ化またはスタンドアロンのすべてのサーバーインスタンスは、新しく再配備されたモジュールを自動的に参照します。サービスを中断せずにモジュールを再配備する方法の詳細については、「段階的アップグレードについて」を参照してください。

  7. 「了解」をクリックしてモジュールを配備します。

同機能を持つ asadmin コマンド

deploy

Procedureライフサイクルモジュールを作成する

ライフサイクルモジュールは、サーバーライフサイクルの 1 つまたは複数のイベントによってトリガーされると、タスクを実行します。このようなサーバーイベントには次のものがあります。

ライフサイクルモジュールは J2EE 仕様の一部ではなく、Application Server の拡張です。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 「ライフサイクルモジュール」ノードを選択します。

  3. 「ライフサイクルモジュール」ページで、「新規」をクリックします。

  4. 「ライフサイクルモジュールを作成」ページで、次の設定を指定します。

    1. 「名前」フィールドに、モジュールの機能を示す名前を入力します。

    2. 「クラス名」フィールドに、ライフサイクルモジュールのクラスファイルの完全修飾名を入力します。

    3. ライフサイクルを含む JAR ファイルがサーバーのクラスパスにある場合は、「クラスパス」フィールドを空白のままにしておきます。そうでない場合は、完全修飾パスを入力します。

      クラスパスを指定しない場合は、domain-dir/applications/lifecycle-module/module-name のクラスをアンパックする必要があります。クラスパスを指定する場合は、何もする必要はありません。

    4. 「読み込み順序」フィールドに、100 以上でオペレーティングシステムの MAXINT 値未満の整数を入力します。

      この整数によって、サーバーの起動時にライフサイクルモジュールが読み込まれる順番が決定します。モジュールに指定された数値が小さいほど、早く読み込まれます。

    5. サーバーを起動すると、すでに配備されたライフサイクルモジュールが読み込まれます。

      デフォルトでは、読み込みが失敗した場合も、サーバーは起動操作を継続します。読み込みが失敗したときにサーバーが起動しないようにするには、「読込み時の障害」チェックボックスにチェックマークを付けます。

    6. 配備後には利用できないようにモジュールを無効にする場合は、「無効」ラジオボタンをオンにします。

      ライフサイクルモジュールはサーバーの起動時に呼び出されるため、ライフサイクルモジュールを無効にしても、実際にはサーバーインスタンスが再起動されるまで無効になりません。

    7. モジュールを配備するターゲットを選択します。

      利用可能なターゲットのリストから、1 つまたは複数のターゲットを選択して「追加」をクリックします。ターゲットを選択しない場合、モジュールはデフォルトのサーバーインスタンス server に配備されます。

  5. 「了解」をクリックします。

同機能を持つ asadmin コマンド

create-lifecycle-module

Procedureアプリケーションクライアントモジュールを配備する

アプリケーションクライアントモジュールは、J2EE アプリケーションクライアント JAR ファイルとも呼ばれ、クライアントのサーバー側ルーチンを含んでいます。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 「アプリケーションクライアントモジュール」ノードを選択します。

  3. 「アプリケーションクライアントモジュール」ページで、「配備」をクリックします。

  4. 「配備」ページで、JAR ファイルを配備する場所を指定します。

    サーバーマシンとは、Application Server のドメイン管理サーバーを実行しているホストです。クライアントマシンとは、ブラウザを介して管理コンソールを表示しているホストです。

    • ファイルがクライアントマシンにある場合、またはクライアントマシンからファイルにアクセス可能な場合は、ラジオボタンをクリックして、Application Server にアップロードするパッケージファイルを指定します。

      「ブラウズ」をクリックしてファイルを検索するか、またはファイルへの完全パスを入力します。

    • ファイルがサーバーマシンにある場合、またはパッケージ化されていないモジュールを分割ディレクトリから配備する場合は、ラジオボタンをクリックして、サーバーからアクセス可能なパッケージファイルまたはディレクトリパスを指定します。

      ファイルまたはディレクトリへの完全パス名を入力します。分割ディレクトリからの配備は高度な開発者用なので、本稼働環境ではお勧めできません。

  5. 「次へ」をクリックして「アプリケーションクライアントモジュールを配備」ページを表示します。

  6. 「アプリケーションクライアントモジュールを配備」ページで、モジュールの設定を指定します。

    1. 「アプリケーション名」フィールドで、ファイル名のプレフィックスであるデフォルト名を保持するか、または別の名前を入力します。

      ファイルのアップロードを選択した場合は、デフォルト名が表示されます。アプリケーション名は一意である必要があります。

    2. モジュールがすでに配備されている場合は、「再配備」チェックボックスを選択して、再配備します。そうでない場合は、エラーが表示されます。

      また、別のアプリケーション名を選択して、新しい名前で配備することもできます。

    3. 配備の前にファイルの構造やコンテンツを検証するには、「ベリファイア」チェックボックスにチェックマークを付けます。

      大きなアプリケーションの検証は時間がかかる可能性があります。ファイルの破壊や移行不能が想定される場合は検証を行なってください。

    4. モジュールを配備するターゲットを選択します。

      利用可能なターゲットのリストから、1 つまたは複数のターゲットを選択して「追加」をクリックします。ターゲットを選択しない場合、モジュールはデフォルトのサーバーインスタンス server に配備されます。

      再配備の場合は、ターゲットを選択しないでください。ここで選択した内容は、すべて無視されます。クラスタやスタンドアロンインスタンスの動的再設定が有効になっている場合、配備されているモジュールを参照する、ターゲットのクラスタ化またはスタンドアロンのすべてのサーバーインスタンスは、新しく再配備されたモジュールを自動的に参照します。サービスを中断せずにモジュールを再配備する方法の詳細については、「段階的アップグレードについて」を参照してください。

    5. RMI スタブを生成するかどうかを選択します。

      RMI スタブの生成を選択すると、静的 RMI-IIOP スタブが生成され、クライアント JAR ファイルに配置されます。

      クライアント側ルーチンでは次のことを行います。

      • 通常、アプリケーションプロバイダは、クライアント側ルーチンを含む JAR ファイルを出荷します。

      • アプリケーションプロバイダは、asadmin deploy コマンドの --retrieve オプションを指定することにより、クライアント側スタブを取得できます。

  7. 「了解」をクリックしてモジュールを配備します。

同機能を持つ asadmin コマンド

deploy

Procedure配備用のアーカイブファイルを指定する

アプリケーションまたはモジュールのページで「配備」をクリックして、「配備」ページにアクセスします。「配備」ページで、アプリケーションまたはモジュールがパッケージ化されているアーカイブファイルの場所を指定します。

サーバーマシンとは、Application Server のドメイン管理サーバーを実行しているホストです。クライアントマシンとは、ブラウザを介して管理コンソールを表示しているホストです。

手順

  1. ファイルがクライアントマシンにある場合、またはクライアントマシンからファイルにアクセス可能な場合は、ラジオボタンをクリックして、Application Server にアップロードするパッケージファイルを指定します。

    「ブラウズ」をクリックしてファイルを検索するか、またはファイルへの完全パスを入力します。

  2. ファイルがサーバーマシンにある場合、または分割ディレクトリからパッケージ化されていないアプリケーションを配備する場合は、ラジオボタンをクリックして、サーバーからアクセス可能なパッケージファイルまたはディレクトリパスを指定します。

    ファイルまたはディレクトリへの完全パス名を入力します。分割ディレクトリからの配備は高度な開発者用なので、本稼働環境ではお勧めできません。

アプリケーションの一覧表示、配備取消し、および有効化に関する管理コンソールタスク

Procedure配備されているアプリケーションを一覧表示する

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. アプリケーションまたはモジュールタイプのノードを展開します。

    配備されているアプリケーションまたはモジュールの詳細を表示するには、次の手順のいずれかに従います。

    • ツリーコンポーネントで、アプリケーションまたはモジュールのノードを選択します。

    • ページで、「アプリケーション名」列のエントリを選択します。

同機能を持つ asadmin コマンド

list-components

Procedureサブコンポーネントを一覧表示する

エンタープライズアプリケーション、Web アプリケーション、EJB モジュール、およびコネクタモジュールにはサブコンポーネントが含まれています。たとえば、Web アプリケーションには 1 つまたは複数のサーブレットが含まれる場合があります。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 記述子を表示するアプリケーションまたはモジュールタイプのノードを展開します。

  3. 配備されているアプリケーションまたはモジュールのノードを選択します。

  4. 「アプリケーション」または「モジュール」ページで、「サブコンポーネント」表が表示されます。

同機能を持つ asadmin コマンド

list-sub-components

Procedure配備されているアプリケーションのモジュールの記述子を表示する

エンタープライズアプリケーション、Web アプリケーション、EBJ モジュール、コネクタモジュール、およびアプリケーションクライアントモジュールについては、モジュールの配備記述子を表示できます。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 記述子を表示するアプリケーションまたはモジュールタイプのノードを選択します。

  3. 配備されているアプリケーションまたはモジュールのノードを選択します。

  4. 「記述子」タブを選択します。

  5. 記述子ファイルのテキストを表示するには、ファイル名をクリックします。

    ページがファイルのコンテンツを表示します。この情報は読み取り専用です。

Procedureアプリケーションまたはモジュールの配備を取り消す

アプリケーションまたはモジュールの配備を取り消すと、それがドメインからアンインストールされ、すべてのインスタンスからそのアプリケーションまたはモジュールに対する参照が削除されます。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. 配備を取り消すアプリケーションまたはモジュールタイプのノードを選択します。

  3. 配備されているアプリケーションを一覧している表で、配備を取り消すアプリケーションまたはモジュールのチェックボックスにチェックマークを付けます。

  4. 「配備取消し」をクリックします。

同機能を持つ asadmin コマンド

undeploy

Procedureアプリケーションまたはモジュールを有効または無効にする

配備されているアプリケーションやモジュールが有効である場合、クライアントはアクセスできます。無効の場合は、配備されているもののクライアントからはアクセスできません。デフォルトでは、「すべてのターゲットを有効にする」ラジオボタンがオンになっているので、アプリケーションまたはモジュールは配備すると有効になります。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. アプリケーションタイプのノードを展開します。

  3. 配備されているアプリケーションまたはモジュールを有効または無効にするには、配備されているアプリケーションまたはモジュールの横にあるチェックボックスを選択します。

    1 つのターゲットでアプリケーションを有効にするには、次の手順に従います。

    1. アプリケーションのノードを選択します。

    2. 「ターゲット」タブをクリックします。

    3. 配備されているアプリケーションまたはモジュールの横にあるチェックボックスを選択します。

  4. 「有効」または「無効」を選択します。

    これらのボタンを使用すると、すべてのターゲットでアプリケーションを有効化または無効化できます。

同機能を持つ asadmin コマンド

enable および disable

Procedureアプリケーションターゲットを管理する

アプリケーションまたはモジュールの配備後、ターゲットを管理することによって、アプリケーションまたはモジュールを参照するサーバーインスタンスやクラスタを管理します。

手順

  1. ツリーコンポーネントで、「アプリケーション」ノードを展開します。

  2. アプリケーションタイプのノードを展開します。

  3. 配備されているアプリケーションのノードを選択します。

  4. 「ターゲット」タブを選択します。

  5. 特定のターゲットインスタンスまたはクラスタ上のアプリケーションを有効化または無効化するには、ターゲットの横にあるチェックボックスをクリックして、「有効」または「無効」をクリックします。

  6. アプリケーションのターゲットを追加または削除するには、「ターゲットの管理」を選択します。

  7. ターゲットを追加または削除して、「了解」をクリックします。

    アプリケーションが、修正されたターゲット一覧で使用できるようになります。

同機能を持つ asadmin コマンド

create-application-ref および delete-application-ref

Procedure追加の仮想サーバーに配備する

ターゲットのサーバーインスタンスまたはクラスタにアプリケーションやモジュールを配備したら、それを追加の仮想サーバーと関連付けることができます。

手順

  1. 配備されているアプリケーションまたはモジュールの「ターゲット」ページで、ターゲットの横にある「仮想サーバーの管理」をクリックします。

  2. 使用可能な仮想サーバーのリストに仮想サーバーターゲットを追加または削除します。

  3. 「了解」をクリックします。

複数のターゲットへの再配備

アプリケーションが複数のターゲット (スタンドアロンサーバーインスタンスまたはクラスタ) に配備されている場合、複数のターゲットへの再配備には 2 とおりの方法があります。次のいずれかの方法を使用して、アプリケーションを参照するすべてのサーバーインスタンスが必ず最新バージョンを受信するようにします。

開発環境

開発環境では、単にアプリケーションを再配備するだけです。アプリケーションはドメインに再配備され、動的再設定がターゲットサーバーインスタンスに対して有効になっている場合、アプリケーションを参照するすべてのターゲットは自動的に新しいバージョンを受信します。動的再設定は、デフォルトでは有効になっています。動的再設定がサーバーインスタンスに対して有効になっていない場合、サーバーインスタンスは再起動されるまで旧バージョンを使用し続けます。

本稼働環境

本稼働環境では、「段階的アップグレードについて」で説明されている手順に従います。

Procedure動的再読み込みを設定する

動的再読み込みを有効にすると、サーバーは配備されているアプリケーションの変更を定期的にチェックし、変更のあるアプリケーションを自動的に再読み込みします。変更は、手動で作成する .reload と呼ばれるファイルの日付の変更によって示されます。アプリケーションは、domain-dir/applications/j2ee-modules module-name または domain-dir/applications/j2ee-apps/ app-name にインストールする必要があります。

次に例を示します。


/opt/SUNWappserver/domain/domain1/applications/j2ee-modules/webapps-simple

動的再読み込みは、変更したコードをすぐにテストできるため、開発環境で役に立ちます。しかし、本稼働環境では、動的再読み込みはパフォーマンスを低下させる可能性があります。

注 –

動的再読み込みは、デフォルトのサーバーインスタンスにのみ利用可能です。

動的再読み込みは、開発環境を対象としています。この機能は、本稼働環境の機能であるセッションの持続性とは互換性がありません。動的再読み込みが有効になっている場合は、セッションの持続性を有効にしないでください。

手順

  1. ツリーコンポーネントで、「スタンドアロンインスタンス」ノードを展開します。

  2. Server (管理サーバー) をクリックします。

  3. 「詳細」をクリックします。

  4. 「アプリケーション設定」ページで、次の事項を設定します。

    • 再読み込み: 「有効」チェックボックスで動的再読み込みを有効または無効にします。

    • 再読込のポーリング間隔: 配備されているアプリケーション内の変更をサーバーがチェックする頻度を指定します。

    • 管理セッションタイムアウト: 管理セッションがタイムアウトし、再度ログインするまでの時間を指定します。

次の手順

動的再読み込みを使用してすべてのアプリケーションが動的に再読み込みされるようにシステムを設定したら、.reload と呼ばれるファイルを作成して、アプリケーションのディレクトリに配置します。このファイルには何もコンテンツがありません。アプリケーションの変更時に、UNIX の touch コマンドを使用するなどしてファイルの日付を変更すると、この変更が自動的に再読み込みされます。

開発者のための開発方法

関連項目

Procedure自動配備を使用する

自動配備機能を使うと、事前にパッケージ化されたアプリケーションやモジュールを domain-dir/autodeploy ディレクトリにコピーすることで配備できます。

たとえば、hello.war という名前のファイルを domain-dir /autodeploy ディレクトリにコピーします。アプリケーションの配備を取り消すには、autodeploy ディレクトリから hello.war ファイルを削除します。

管理コンソールまたは asadmin ツールを使用して、アプリケーションの配備を取り消すこともできます。この場合、アーカイブファイルはそのままになります。

注 –

自動配備は、デフォルトのサーバーインスタンスにのみ利用可能です。

自動配備機能は、開発環境を対象としています。この機能は、本稼働環境の機能であるセッションの持続性とは互換性がありません。自動配備が有効になっている場合は、セッションの持続性を有効にしないでください。

手順

  1. ツリーコンポーネントで、「スタンドアロンインスタンス」ノードを展開します。

  2. Server (管理サーバー) をクリックします。

  3. 「詳細」をクリックします。

  4. 「アプリケーション設定」ページで、次の事項を設定します。

    1. 「有効」チェックボックスを選択または選択解除して、自動配備を有効または無効にします。

    2. 「自動配備のポーリング間隔」フィールドで、アプリケーションやモジュールファイルの自動配備ディレクトリをサーバーが確認する頻度を指定します。

      ポーリング間隔を変更しても、アプリケーションやモジュールの配備にかかる時間には影響ありません。

    3. 自動配備ディレクトリでアプリケーションを構築したディレクトリを指定してあれば、ファイルをデフォルトの自動配備ディレクトリにコピーする必要はありません。

      デフォルトは、サーバーインスタンスのルートディレクトリにある autodeploy というディレクトリです。

      デフォルトでは、複数のサーバーインスタンスのディレクトリを手動で変更する必要をなくすために、変数が使用されます。これらの変数の詳細については、「詳細ドメイン属性を設定する」を参照してください。

    4. 配備の前にベリファイアを実行するには、「ベリファイア」を選択します。

      ベリファイアはファイルの構造とコンテンツを調べます。大きなアプリケーションの検証は時間がかかる可能性があります。

    5. JSP ページをプリコンパイルするには、「プリコンパイル」を選択します。

      このチェックボックスを選択しない場合、JSP ページは最初のアクセスの実行時にコンパイルされます。コンパイルは時間がかかる可能性があるので、本稼働環境ではこのチェックボックスにチェックマークを付けてください。

Procedureパッケージ化されていないアプリケーションをディレクトリから配備する

この機能は高度な開発者を対象としています。

ディレクトリ配備は、デフォルトのサーバーインスタンス (server) への配備にだけ使用します。クラスタまたはスタンドアロンサーバーインスタンスへの配備には使用できません。

パッケージ化されていないアプリケーションやモジュールを含むディレクトリを、分割ディレクトリと呼ぶことがあります。ディレクトリのコンテンツは、対応する J2EE アーカイブファイルのコンテンツと一致する必要があります。たとえば、ディレクトリから Web アプリケーションを配備する場合、ディレクトリのコンテンツは対応する WAR ファイルと同じになる必要があります。必要なディレクトリコンテンツの詳細については、適切な仕様を参照してください。

分割ディレクトリ内で配備記述子ファイルを直接変更できます。

環境が動的再読み込みを使用するように設定されている場合は、配備されたアプリケーションをディレクトリから動的に再読み込みすることもできます。詳細については、「動的再読み込みを設定する」を参照してください。

手順

  1. 管理コンソールで、配備プロセスを開始します。「Web アプリケーションを配備する」を参照してください。

  2. 「配備」ページで、次の事項を設定します。

    1. ラジオボタンをクリックして、サーバーからアクセス可能なパッケージファイルまたはディレクトリパスを指定します。

    2. 「ファイルまたはディレクトリ」フィールドで、分割ディレクトリの名前を入力します。

同機能を持つ asadmin コマンド

deploydir

deploytool ユーティリティーの使用

ソフトウェア開発者を対象として設計された deploytool ユーティリティーは、J2EE アプリケーションおよびモジュールをパッケージ化し、配備します。deploytool の使用手順については、『J2EE 1.4 Tutorial』を参照してください。

配備計画の使用

この機能は高度な開発者を対象としています。

配備計画は、Application Server に固有の配備記述子だけを含む JAR ファイルです。このような配備記述子、たとえば sun-application.xml などについては、『Application Server 開発者ガイド』で説明されています。配備計画は、JSR 88: J2EE Application Deploymentの実装の一部です。配備計画を使用して、Application Server に固有の配備記述子を含まないアプリケーションやモジュールを配備します。

配備計画を使用して配備を行うには、asadmin deploy コマンドの --deploymentplan オプションを指定します。たとえば、次のコマンドは、mydeployplan.jar ファイルによって指定される計画に従って、myrosterapp.ear ファイルのエンタープライズアプリケーションを配備します。


$ asadmin deploy --user admin ---deploymentplan mydeployplan.jar myrosterapp.ear

エンタープライズアプリケーション (EAR) の配備計画ファイルでは、sun-application.xml ファイルがルートに置かれています。各モジュールの配備記述子は、構文 module-name.sun-dd-name に従って格納されています。sun-dd-name は、モジュールタイプによって異なります。モジュールに CMP マッピングファイルが含まれる場合、ファイルは module-name.sun-cmp-mappings.xml という名前になります。.dbschema ファイルはルートレベルに格納されていて、スラッシュ (/) はシャープ記号 (#) に置き換えられます。次のリストは、エンタープライズアプリケーション (EAR) の配備計画ファイルの構造を示しています。

$ jar -tvf mydeployplan.jar
420 Thu Mar 13 15:37:48 PST 2003 sun-application.xml
370 Thu Mar 13 15:37:48 PST 2003 RosterClient.war.sun-web.xml
418 Thu Mar 13 15:37:48 PST 2003 roster-ac.jar.sun-application-client.xml
1281 Thu Mar 13 15:37:48 PST 2003 roster-ejb.jar.sun-ejb-jar.xml
2317 Thu Mar 13 15:37:48 PST 2003 team-ejb.jar.sun-ejb-jar.xml
3432 Thu Mar 13 15:37:48 PST 2003 team-ejb.jar.sun-cmp-mappings.xml
84805 Thu Mar 13 15:37:48 PST 2003 team-ejb.jar.RosterSchema.dbschema

Web アプリケーションまたはモジュールファイルの配備計画では、Application Server に固有の配備記述子がルートレベルにあります。スタンドアロンの EJB モジュールに CMP Bean が含まれる場合、配備計画には、ルートレベルの sun-cmp-mappings.xml ファイルや .dbschema ファイルが含まれます。次のリストでは、配備計画が CMP bean を示しています。

$ jar r -tvf myotherplan.jar
3603 Thu Mar 13 15:24:20 PST 2003 sun-ejb-jar.xml
3432 Thu Mar 13 15:24:20 PST 2003 sun-cmp-mappings.xml
84805 Thu Mar 13 15:24:20 PST 2003 RosterSchema.dbschema