WebLogic Server アプリケーションのデプロイメント
|
 |
 |
|
以下の節では、より高度なデプロイメントについて説明します (一部の WebLogic Server インストールでは使用されない場合もあります)。
ドメインにアプリケーションおよびスタンドアロン モジュールをデプロイする場合、WebLogic Server では、2 フェーズ デプロイメント プロトコルを使用します。このプロトコルにより、ドメイン内の複数の WebLogic Server デプロイメントの一貫性が保証され、アプリケーションの順序設定や改良されたモニタ機能などの高度な機能もサポートされます。
WebLogic Server ドメインの各デプロイメントには、準備とアクティブ化の 2 つのフェーズがあります。
準備フェーズは、アプリケーションおよびそのモジュールをデプロイ可能な状態にする段階です。準備フェーズでは、ドメインの WebLogic Server インスタンスは以下のタスクを実行します。
アクティブ化フェーズでは、対象サーバによってアプリケーションがクライアントで使用可能な状態にされます。このフェーズでアプリケーションまたはモジュールの実際のデプロイメントが行われます。
準備フェーズが正常に完了した後にのみ、アクティブ化フェーズが実行されます。
2 フェーズ デプロイメント モデルの主な目的は、複数の対象へのデプロイメント (複数の WebLogic Server インスタンスで構成されるクラスタへのデプロイメントなど) を、使用可能な状態の対象サーバを論理ユニットとして成功または失敗させることです。クラスタでは、使用可能な状態の対象サーバのうち、デプロイメント ファイルの検証に失敗したサーバや、デプロイメント ファイルにエラーが検出されたサーバが 1 つでもある場合には、デプロイメントがアクティブ化されません。
注意 : WebLogic Server 8.1 で非推奨になった WebLogic Server 6.x デプロイメント プロトコルでは、クラスタへのデプロイメントの一貫性は保証されません。詳細については、「WebLogic Server 6.x のデプロイメント プロトコル (非推奨)」を参照してください。
また、2 フェーズ デプロイメント プロトコルを使用すると、デプロイされるアプリケーションに関して以下の新機能の効果があります。
デフォルトでは、利用可能なすべてのデプロイメント ツールによって新しいアプリケーションをデプロイする場合は、2 フェーズ デプロイメント プロトコルが使用されます。管理サーバでも、以下の場合に非推奨の WebLogic Server 6.x デプロイメント プロトコルを使用します。
application.xml 記述子がない場合6.x デプロイメント プロトコルは非推奨になりました。6.x プロトコルを使用するアプリケーションがある場合は、次の手順に従って 2 フェーズ デプロイメントを使用してください。
java weblogic.Deployer -adminurl http://admin:7001 -username weblogic
-name app -undeploy
java weblogic.Deployer -adminurl http://admin:7001 -username weblogic
-deploy -name ArchivedEarJar -source C:/MyApps/JarEar.ear
-target server1,server2
WebLogic Server クラスタにデプロイする場合、デフォルトの 2 フェーズ デプロイメント処理では、管理サーバからアクセス可能なクラスタ化されたサーバ インスタンスについてのみ、デプロイメントが成功します。(管理サーバと管理対象サーバの間にネットワーク障害があるなどして) デプロイメントの時点でアクセス不能なサーバについては、ネットワーク接続が回復するまでデプロイメント リクエストは受信されません。この場合、クラスタ内の一部のサーバは新バージョンのデプロイメント ユニットを使用し、アクセス不能なサーバは旧バージョンのデプロイメント ユニットを使用するという状況になる可能性があります。
ClusterConstraintsEnabled は、ドメイン内のすべてのサーバに対して厳密な 2 フェーズ デプロイメント ポリシーを強制するオプションです。ClusterConstraintsEnabled を使用すると、クラスタ内のすべてのメンバーがアクセス可能であり、指定したファイルがデプロイ可能な場合にのみ、クラスタへのデプロイメントが成功します。
次の起動引数を指定すると、管理サーバの起動時に、ドメインに ClusterConstraintsEnabled を設定できます。
-DClusterConstraintsEnabled=true (ドメイン内のサーバに対して厳密なクラスタ デプロイメントを強制する)-DClusterConstraintsEnabled=false (ドメイン内のサーバに対してデフォルトの 2 フェーズ デプロイメント処理を適用する。管理サーバからアクセス可能なクラスタ化されたサーバのみに対してデプロイメントを行う)次に示すように、Administration Console を使用して ClusterConstraintsEnabled オプションを設定することもできます。
デプロイメントのステージング モードは、デプロイメントのアクティブ化フェーズで管理サーバから対象サーバにデプロイメント ファイルをコピーするかどうかを決定します。WebLogic Server のアーカイブ ファイルのステージング モードには、stage モード、nostage モード、external_stage モードの 3 種類があります (「ステージング モード」を参照)。
サーバのステージング ディレクトリは、管理サーバが stage モード デプロイメント用のデプロイメント ファイルをコピーするディレクトリです。また、external_stage モードを使用してアプリケーションをデプロイする前には、このディレクトリにデプロイメント ファイルが配置されている必要があります。
stage モードでは、管理サーバはマシンの元の位置から各対象サーバのステージング ディレクトリにデプロイメント ファイルをコピーします。たとえば、stage モードを使用してクラスタ内の 3 つのサーバに J2EE アプリケーションをデプロイする場合、管理サーバは 3 つのサーバ マシンのそれぞれのディレクトリにデプロイメント ファイルをコピーします。各サーバは、アーカイブ ファイルのローカル コピーを使用して J2EE アプリケーションをデプロイします。
警告 : アプリケーションのデプロイ後、アプリケーションの元のソース ファイルを変更したり削除したりしないでください。WebLogic Server デプロイメント フレームワークでは、このファイルを使用してデプロイされたアプリケーションを管理します。元のソース ファイルを変更したり削除したりすると、予期しない動作が発生する場合があります。
ステージング ディレクトリにファイルをコピーするときに、管理サーバはデプロイメント名と同名のサブディレクトリを作成します。そのため、次のコマンドを使用してデプロイした場合、
java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic -name mytestear -stage -targets mycluster
-deploy c:\bea\weblogic81\samples\server\medrecd\dist\physicianEar
mycluster の各サーバのステージング ディレクトリに新しいディレクトリ mytestear が作成されます。デプロイメント名を指定しないと、次のようにデフォルトのデプロイメント名 (およびステージング サブディレクトリ) が使用されます。
physicianEar)。physicianEar.ear をデプロイする場合のデプロイメント名とステージング サブディレクトリは physicianEar)。Administration Console では、複数の WebLogic Server インスタンスにデプロイする場合のデフォルト モードとして、stage モードを使用します。weblogic.Deployer ではデフォルトとして対象サーバのステージング モードを、管理対象サーバではデフォルトで stage モードを使用します。
stage モードでは、ネットワーク停止により管理サーバにアクセス不能になった場合でも、各サーバがデプロイメント ファイルのローカル コピーを持つことが保証されます。ただし、非常に大きいアプリケーションを複数のサーバ、またはクラスタにデプロイする場合は、対象サーバへのファイルのコピーに要する時間がかなり長くなることがあります。大きいファイルを複数のサーバにコピーすることによるオーバーヘッドを防ぐには、nostage モードを使用するとよいでしょう。
nostage モードでは、管理サーバはアーカイブ ファイルをソース位置からコピーしません。代わりに、各対象サーバは、デプロイメント用の単一のソース ディレクトリにあるアーカイブ ファイルにアクセスする必要があります。nostage デプロイメントでは、対象サーバのステージング ディレクトリは無視されます。
たとえば、クラスタ内の 3 つのサーバに J2EE アプリケーションをデプロイする場合、アプリケーションをデプロイするには、共有ディレクトリまたはネットワーク上のディレクトリを通じて各サーバが同じアプリケーション アーカイブ ファイルにアクセスできる必要があります。
注意 : nostage モードでは、デプロイメント ファイルのソースは、デプロイ時にユーザが指定するパスです (これに対し、stage モードでは各サーバのステージング ディレクトリのパスがソースになります)。ただし、WebLogic Server は、nostage モードの場合でもデプロイメント ファイルの一部を一時ディレクトリにコピーします。このため、ユーザがアーカイブ形式デプロイメントの全体または一部を更新することが可能です。
nostage モードでは、Web アプリケーション コンテナが JSP およびサーブレットに対する変更を自動的に検出します。また、アプリケーションの一部のみを後から更新することもできます。そのためには、該当する部分をファイル システムの 1 つの位置で更新し、再デプロイします。
Administration Console では、管理サーバのみにデプロイする場合 (単一サーバ ドメインの場合など) のデフォルト モードとして nostage モードが使用されます。weblogic.Deployer では対象サーバのステージング モードを、管理サーバでは stage モードをデフォルトで使用します。同じマシンでサーバ インスタンスのクラスタを実行する場合、または共有ディレクトリにアクセスできる複数のマシンに非常に大きいアプリケーションをデプロイする場合も、nostage モードを選択できます。非常に大きいアプリケーションを nostage モードでデプロイすると、ファイルがコピーされないため、デプロイ時間を短縮できます。
external_stage モードでは stage モードと同様に、対象サーバはデプロイメント ファイルのローカル コピーを使用してデプロイします。ただし、external_stage モードでは、管理サーバは対象サーバにデプロイメント ファイルを自動的にコピーしません。そのため、デプロイメントの前に、各対象サーバのステージング ディレクトリにファイルをコピーする必要があります。コピーは、手作業または自動スクリプトで実行できます。
デプロイメント ファイルは、各対象サーバのステージング ディレクトリ内で、デプロイメント名を反映した名前を持つサブディレクトリに格納されている必要があります。この名前は、デプロイメントに対してユーザが入力する名前、またはデフォルトのデプロイメント名 (展開されたアーカイブ ディレクトリの名前、またはアーカイブ ファイル名からファイル拡張子を除いた名前) のどちらでもかまいません。例については、「external_stage モードを使用したエンタープライズ アプリケーションのデプロイ」を参照してください。
external_stage モードは、使用することが少ないデプロイメント ステージング モードです。このモードは、通常、必要なファイルの自動コピーをサードパーティのツールによって管理している環境でのみ使用します。非常に大きいアプリケーションを複数のマシンにデプロイする場合で共有ファイル システムがない (nostage モードを使用できない) 場合も、external_stage モードを使用できます。このような場合に external_stage モードを使用すると、デプロイメント時にファイルがコピーされないため、デプロイメントにかかる時間を短縮できます。
Administration Console を使用してアプリケーションまたはスタンドアロン モジュールをデプロイする場合、ステージング モードはアプリケーション レベルで設定されます。アプリケーションのステージング モードは、対象サーバ自体に指定したデプロイメント モードよりも常に優先されます。
サーバのステージング モードは、デプロイメント時にデプロイメント モードを指定しない場合に使用される、サーバ用のデフォルトのデプロイメント モードを指定します。たとえば、weblogic.Deployer を使用してデプロイするときにステージング モードを指定しなかった場合、サーバのステージング モードが使用されます。サーバのステージング モードのデフォルト値は、管理サーバの場合は nostage モード、管理対象サーバの場合は stage モードです。
デフォルトでは、WebLogic Server はサーバレベルのリソース (JDBC に続いて JMS) をデプロイしてから、(起動クラスの前に) アプリケーションおよびスタンドアロン モジュールをデプロイします。起動クラスの実行順序はコンフィグレーション可能です (「起動クラスの実行とデプロイメントの順序設定」を参照)。
注意 : WebLogic Server セキュリティ サービスは必ず、サーバ リソース、アプリケーション、および起動クラスがデプロイされる前に初期化されます。したがって、起動クラスを使用してカスタム セキュリティ プロバイダをコンフィグレーションすることはできず、また、カスタム セキュリティ プロバイダの実装が JDBC などのデプロイ済みサーバ リソースに基づくこともできません。
デプロイメント ユニットの相対的なデプロイ順は、[ロード順] 属性によって決定します。デフォルトでは、各デプロイメント ユニットのロード順は 100 にコンフィグレーションされます。起動時には、[ロード順] の値が小さいデプロイメントのデプロイに続いて、値の大きいデプロイメントのデプロイが行われます。[ロード順] の値が同じデプロイメントは、デプロイメント名のアルファベット順にデプロイされます。Administration Console で、または ApplicationMBean を使用してプログラム的に [ロード順] 属性を設定して、デプロイメント ユニットのロード順を変更できます。Administration Console でロード順を変更する手順については、「デプロイメント ユニットのデプロイメント順序の変更」を参照してください。
アプリケーションが EAR の場合、application.xml デプロイメント記述子に宣言されている順序で、個々のモジュールがロードされます。『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。
デフォルトでは、サーバで JMS サービスと JDBC サービスが初期化され、アプリケーションおよびスタンドアロン モジュールがデプロイされた後に WebLogic Server の起動クラスが実行されます。
JMS サービスと JDBC サービスが使用可能になった後、アプリケーションおよびモジュールがアクティブ化される前に起動タスクを実行する場合は、Administration Console で [アプリケーション アクティブ化の前に実行] オプションを選択します (または StartupClassMBean の LoadBeforeAppActivation 属性を「true」に設定する)。
JMS サービスと JDBC サービスが使用可能になる前に起動タスクを実行する場合は、Administration Console で [アプリケーション デプロイメントの前に実行] オプションを選択します (または StartupClassMBean の LoadBeforeAppDeployments 属性を「true」に設定する)。
次の図は、WebLogic Server でいつ起動クラスが実行されるかを簡単に示しています。
WebLogic 起動クラスから JMS メッセージのコンシューマを確立する方法を示す examples.jms.startup API コード例を提供します。StartupClassMBean の詳細については、「Administration Console オンライン ヘルプ」、または 「Javadocs」全体を参照してください。
注意 : WebLogic Server 8.1 では、API コード サンプルが必要に応じて WL_HOME\samples\server\examples\src\examples にインストールされます。WL_HOME は WebLogic Server の最上位ディレクトリを示します。サンプル サーバを起動し、サンプルおよびその実行手順に関する情報を確認することができます。
アプリケーションをデプロイした後に、アプリケーションの全体または一部を選択して再デプロイできます。 アプリケーション全体を再デプロイする場合は、アプリケーションのクラスをアンロードし、変更後のデプロイメント ファイルを使用してアプリケーションを再びデプロイします (stage モードを使用してデプロイされたアプリケーションの場合は、再デプロイメントでもデプロイメント ファイルが対象サーバに再度コピーされます)。
注意 : アプリケーションは、再デプロイメント中はクライアントから使用できません。WebLogic Server では、再デプロイメント時にクライアントからアクセスがあった場合、アプリケーション操作およびデプロイメント操作は保証されません。このため、プロダクション環境で使用する場合には再デプロイはお勧めしません。
エンタープライズ アプリケーションの Web アプリケーションや EJB モジュールなど、アプリケーションの一部を再デプロイする場合は、特定のクラスローダのクラスのみをアンロードし、アンロードしたクラスを更新後のクラス ファイルを使用して再ロードします。クラスローディングの動作の詳細については、『WebLogic Server アプリケーションの開発』の「WebLogic Server J2EE アプリケーション クラスローディング」を参照してください。Web アプリケーションの個別のファイル (サーブレット、JSP、静的 HTML ページなど) を、アプリケーションのクラスローダに影響を与えることなく、アプリケーションの他のモジュールとは独立して再デプロイすることもできます。
アプリケーションおよびモジュールの再デプロイの例については、「デプロイメント ユニットの再デプロイまたは停止」および「Web アプリケーション内の静的ファイルの再デプロイ」を参照してください。
アプリケーションおよびモジュールを再デプロイする場合は、次の制限について注意が必要です。
weblogic.xml デプロイメント記述子ファイルの container-descriptor スタンザで save-sessions-enabled を「true」に設定します。weblogic.Deployer の次のメッセージが表示されます。Exception:weblogic.management.ApplicationException: [J2EE:160076] You
must include all of [module_list] in your files list to modify [module]
部分的な再デプロイメントとは、デプロイ済みの Web アプリケーションの一部を変更または追加し、再デプロイ アクションを使用して変更を有効にすることです。WebLogic Server は、展開された WAR ファイルとしてデプロイされた Web アプリケーションのみについて、部分的な再デプロイメントをサポートしています。次の種類の部分的な再デプロイメントがサポートされています。
WEB-INF/classes ディレクトリ内のクラスは、Web アプリケーションの他の部分とは独立して再デプロイできます。Web アプリケーションの再ロード間隔を設定して、WEB-INF/classes ディレクトリ全体ではなく、更新したクラスのみをデプロイすることも可能です。再ロード間隔の詳細については、『WebLogic Server Web アプリケーションの開発』の「Web アプリケーションのデプロイメント」を参照してください。WEB-INF/lib 内の JAR ファイルは、Web アプリケーションの他の部分から独立して再デプロイできません。WEB-INF/lib 内の JAR ファイルの再デプロイ時、コンテナは自動的にアプリケーション全体を再デプロイしますが、状態を保持します。
WebLogic Server では、エンタープライズ アプリケーションの実行時デプロイメント コンフィグレーションを変更するときに、アーカイブ自体の内容を変更して再パッケージ化する必要がありません。この変更を行うには、エンタープライズ アプリケーションのデプロイ時に使用する代替デプロイメント記述子ファイルを指定します。
代替デプロイメント記述子ファイルは、パッケージ化された EAR ファイルまたは展開された EAR ディレクトリ外部の任意の位置に配置できます (アーカイブまたはディレクトリ内に代替デプロイメント記述子ファイルを格納することはできません)。デプロイメント時に外部 EAR 記述子ファイルを指定すると、WebLogic Server はデプロイメントの既存の (パッケージ化された) デプロイメント記述子の代わりにその代替ファイルを使用します。stage モードを使用してファイルをデプロイする場合、代替デプロイメント記述子ファイルは、各対象サーバのステージング ディレクトリ内でデプロイメントのサブディレクトリの最上位 (domain_directory/servername/stage/myapp など) にデプロイメント ファイルと共にコピーされます。 他のステージング モードでは、コピーは行われません。
代替デプロイメント記述子ファイルを指定して、標準の J2EE デプロイメント記述子 (application.xml) または WebLogic Server デプロイメント記述子 (weblogic-application.xml) の代わりに使用できます。
通常、代替デプロイメント記述子は、アーカイブされたエンタープライズ アプリケーション (EAR ファイル) で使用します。代替デプロイメント記述子を使用すると、アプリケーション自体を再パッケージ化することなく、デプロイメント パラメータを変更できるためです。ただし、展開された EAR ディレクトリで使用する代替記述子を指定することもできます。
代替デプロイメント記述子の一般的な使い方には以下のものがあります。
代替記述子を使用してエンタープライズ アプリケーションをデプロイした場合、アプリケーションの再デプロイ時に代替記述子ファイルの位置を変更することはできません。 たとえば、weblogic.Deployer -redeploy コマンドを使用して、異なる代替デプロイメント記述子ファイルのファイル名またはパスを指定することはできません。ただし、元の記述子ファイルに行った変更は、再デプロイメント時に実装されます。
標準のデプロイメント記述子を使用してアプリケーションをデプロイした場合、-redeploy コマンドまたは -deploy コマンドを使用して、そのアプリケーションで代替記述子を使用することはできません。代わりに、最初にアプリケーションをアンデプロイし、次に代替記述子ファイルを使用してアプリケーションをデプロイする必要があります。
代替デプロイメント記述子を使用するには、weblogic.Deployer で次のオプションの 1 つまたは両方を使用するだけです。
-altappdd - 代替 J2EE デプロイメント記述子 (application.xml) を指定する。-altwlsappdd - 代替 WebLogic Server デプロイメント記述子 (weblogic-application.xml) を指定する。代替記述子ファイルの例については、「代替 (外部) アプリケーション記述子によるエンタープライズ アプリケーションのデプロイ」を参照してください。
この節では、アプリケーションを開発し WebLogic Server にデプロイする J2EE アプリケーション開発者向けのトピックを取り上げます。
注意 : 自動デプロイメントは、評価またはテストのために、スタンドアロン サーバ (管理サーバ) にアプリケーションを迅速にデプロイするための手段です。自動デプロイメントは、単一サーバの開発環境でのみ使用してください。 プロダクション環境で使用したり、管理対象サーバにデプロイするために使用したりすることは避けてください。
アプリケーションのデプロイ時には、自動デプロイではなく、WebLogic Server の分割開発ディレクトリおよび wldeploy ant タスクを使用することをお勧めします。『WebLogic Server アプリケーションの開発』の「分割開発ディレクトリ環境の概要」を参照してください。
自動デプロイメントが有効な場合は、アプリケーションが管理サーバの \applications ディレクトリにコピーされると、その管理サーバは新しいアプリケーションの存在を検出し、それを自動的にデプロイします (管理サーバが動作している場合)。アプリケーションを \applications ディレクトリにコピーしたときに WebLogic Server が稼働していない場合、そのアプリケーションは WebLogic Server の管理サーバが次に起動したときにデプロイされます。 自動デプロイメントは管理サーバに対してのみデプロイします。
注意 : Windows NT では厳格なファイル ロック制限により、アプリケーションが展開された場合、アプリケーション内のすべてのコンポーネントも展開されます。つまり、展開するアプリケーションまたはモジュールに JAR ファイルが含まれる場合、自動デプロイメントは使用できません。
自動デプロイメントは、開発環境において単一サーバの対象で使用することを想定されています。Administration Console など、他のツールを使用して自動デプロイ済みの展開されたアプリケーションに対象を追加した場合、アプリケーションを再デプロイしても新しい対象サーバに変更は伝わりません。
WebLogic Server ドメインは、開発環境とプロダクション環境の 2 つの異なるモードで実行できます。
開発モードでは、WebLogic Server インスタンスは domain_name/applications ディレクトリ (domain_name は WebLogic Server ドメインの名前) にあるアプリケーションを自動的にデプロイおよび更新できます。つまり、開発モードでは自動デプロイを使用することになります。プロダクション モードでは、自動デプロイメント機能は無効になります。
デフォルトでは、WebLogic Server ドメインは開発モードで稼働します。ドメインのモードを指定する方法については、『WebLogic Server のコンフィグレーションと管理』の「コンフィグレーション ウィザードを使用したドメインの作成とコンフィグレーション」を参照してください。
アーカイブされたアプリケーションを自動デプロイするには、そのアーカイブ ファイルを /applications ディレクトリにコピーします。WebLogic Server はアプリケーションのデプロイメント モードを自動的に stage モードに設定します。
自動デプロイされたデプロイメント ユニットは、サーバの稼働時に動的に再デプロイできます。動的に再デプロイするには、アーカイブ ファイルの新バージョンを /applications ディレクトリ内の既存ファイルに上書きコピーします。
自動デプロイ済みのアーカイブされたデプロイメント ユニットをアンデプロイするには、/applications ディレクトリからアプリケーションを削除します。WebLogic Server は、アプリケーションを停止してコンフィグレーションから削除します。
展開されたアーカイブ形式でアプリケーションを自動デプロイするには、展開されたアーカイブ ディレクトリ全体を /applications ディレクトリにコピーします。WebLogic Server は、nostage デプロイメント モードを使用して、展開されたアーカイブ アプリケーションを自動的にデプロイします。展開された EAR ディレクトリをデプロイするとき、そのディレクトリにアーカイブされたモジュール (JAR ファイル) が含まれてる場合は、デプロイ時に JAR ファイルがロックされます。
アプリケーションが展開されたアーカイブ形式で自動デプロイされている場合、管理サーバは、展開されたアプリケーションのディレクトリ内で REDEPLOY というファイルを定期的に検索します。このファイルのタイムスタンプが変更されている場合、管理サーバは展開ディレクトリを再デプロイします。
展開されたアプリケーション ディレクトリ内のファイルを再デプロイするには、次の手順に従います。
REDEPLOY という名前の空のファイルを作成し、そのファイルを、デプロイするアプリケーションのタイプに応じて、WEB-INF または META-INF ディレクトリに配置します。展開されたエンタープライズ アプリケーションには、最上位に META-INF ディレクトリがあり、このディレクトリに application.xml ファイルがあります。
展開された Web アプリケーションには、最上位に WEB-INF ディレクトリがあり、このディレクトリに web.xml ファイルがあります。
展開された EJB アプリケーションには、最上位に META-INF ディレクトリがあり、このディレクトリに ejb-jar.xml ファイルがあります。
展開されたコネクタには、最上位に META-INF ディレクトリがあり、このディレクトリに ra.xml ファイルがあります。
注意 : REDEPLOY ファイルは、デプロイされたアプリケーション全体またはスタンドアロン モジュールに対してのみ機能します。展開されたエンタープライズ アプリケーションをデプロイした場合、REDEPLOY ファイルは、個別のモジュール (Web アプリケーションなど) ではなく、アプリケーション全体の再デプロイを制御します。Web アプリケーション自体を展開されたアーカイブ ディレクトリとしてデプロイする場合、REDEPLOY ファイルは Web アプリケーション全体の再デプロイメントを制御します。
管理サーバは、タイムスタンプの変更を検出すると、展開ディレクトリのコンテンツを再デプロイします。
注意 : 自動デプロイしたアプリケーションの再デプロイを開始する場合は常に、REDEPLOY ファイルを編集する (タイムスタンプを変更する) 必要があります。サーバが停止状態のときにアプリケーションを変更する場合でも、REDEPLOY ファイルを編集し、次回のサーバ起動時に変更が確実に適用されるようにする必要があります。
展開形式で自動デプロイしたアプリケーションをアンデプロイするには、weblogic.Deployer -undeploy コマンドを使用するか、または Administration Console を使用して、デプロイメントのコンフィグレーションを削除します。次に、\applications ディレクトリからアプリケーション ファイルを削除します。
アプリケーション ライフサイクル リスナ イベントは、デプロイメント、アンデプロイメント、および再デプロイメント時の動作を開発者が制御できるハンドルを提供します。 この節では、アプリケーション ライフサイクル リスナ イベントの使用方法について説明します。
WebLogic Server には、リスナ クラス、停止クラス、および起動クラスを拡張するときに使用できる 4 つのアプリケーション ライフサイクル イベントがあります。 以下のイベントがあります。
public void preStart(ApplicationLifecycleEvent evt) {}
public void postStart(ApplicationLifecycleEvent evt) {}
public void preStop(ApplicationLifecycleEvent evt) {}
public void postStop(ApplicationLifecycleEvent evt) {}
注意 : 起動クラスおよび停止クラスでは、main{} メソッドのみを実装します。リスナ用に提供されたメソッドを実装した場合は、無視されます。
注意 : ApplicationLifecycleListener に remove{} メソッドは提供されていません。イベントが、デプロイメントでの起動時 (prestart と poststart) およびアンデプロイメントでの停止時 (prestop と poststop) にのみ開始されるためです。
これらのイベントを使用するには、weblogic-application.xml デプロイメント記述子に登録する必要があります。「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。 以下の要素を定義します。
抽象クラス (WebLogic Server 付属のクラス) weblogic.application.ApplicationLifecycleListener を拡張することにより、リスナを作成します。作成したリスナはコンテナによって検索されます。
WebLogic Server の ApplicationLifecycleListener 抽象クラスに提供されている次のメソッドをオーバーライドし、必要な機能を追加してアプリケーションを拡張します。
コード リスト 4-1 は、ApplicationLifecycleListener をオーバーライドする方法を示しています。この例では、パブリック クラス MyListener が ApplicationLifecycleListener を拡張しています。
import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyListener extends ApplicationLifecycleListener {
public void preStart(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(preStart) -- we should always see you..");
} // preStart
public void postStart(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(postStart) -- we should always see you..");
} // postStart
public void preStop(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(preStop) -- we should always see you..");
} // preStop
public void postStop(ApplicationLifecycleEvent evt) {
System.out.println
("MyListener(postStop) -- we should always see you..");
} // postStop
public static void main(String[] args) {
System.out.println
("MyListener(main): in main .. we should never see you..");
} // main
}
コード リスト 4-2 に、停止クラスを実装する方法を示します。停止クラスは、preStop イベントおよび postStop イベントにアタッチできます。この例では、パブリック クラス MyShutdown が ApplicationLifecycleListener を拡張しています。
import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyShutdown extends ApplicationLifecycleListener {
public static void main(String[] args) {
System.out.println
("MyShutdown(main): in main .. should be for post-stop");
} // main
}
コード リスト 4-3 に、起動クラスを実装する方法を示します。起動クラスは、preStart イベントおよび postStart イベントにアタッチできます。この例では、パブリック クラス MyStartup が ApplicationLifecycleListener を拡張しています。
import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyStartup extends ApplicationLifecycleListener {
public static void main(String[] args) {
System.out.println
("MyStartup(main): in main .. should be for pre-start");
} // main
}
次の例に、weblogic-application.xml デプロイメント記述子ファイルでアプリケーション ライフサイクル イベントをコンフィグレーションする方法を示します。URI パラメータは必須ではありません。アプリケーションの $CLASSPATH 内であれば任意の位置にクラスを配置できます。ただし、$CLASSPATH にクラスの位置を定義する必要があります。EAR に APP-INF/classes ディレクトリまたは APP-INF/lib ディレクトリが存在する場合は、これらのディレクトリにリスナを配置できます。この場合、リスナは自動的に $CLASSPATH に含まれます。
次の例に、URI パラメータを使用してアプリケーション ライフサイクル イベントをコンフィグレーションする方法を示します。この例では、アーカイブ foo.jar はクラスを含み、EAR ファイルの最上位に存在します (例 : myEar/foo.jar)。
コード リスト 4-4URI パラメータを使用したアプリケーション ライフサイクル イベントのコンフィグレーション
<listener>
<listener-class>MyListener</listener-class>
<listener-uri>foo.jar</listener-uri>
</listener>
<startup>
<startup-class>MyStartup</startup-class>
<startup-uri>foo.jar</startup-uri>
</startup>
<shutdown>
<shutdown-class>MyShutdown</shutdown-class>
<shutdown-uri>foo.jar</shutdown-uri>
</shutdown>
次の例に、URI パラメータを使用せずにアプリケーション ライフサイクル イベントをコンフィグレーションする方法を示します。
コード リスト 4-5URI パラメータを使用しないアプリケーション ライフサイクル イベントのコンフィグレーション
<listener>
<listener-class>MyListener</listener-class>
</listener>
<startup>
<startup-class>MyStartup</startup-class>
</startup>
<shutdown>
<shutdown-class>MyShutdown</shutdown-class>
</shutdown>
アプリケーションの完全な再デプロイメントが発生する場合にのみ、アプリケーション ライフサイクル イベントが開始されます。アプリケーションの完全な再デプロイメント時に、アプリケーション ライフサイクル イベントが登録済みであれば、アプリケーション ライフサイクルはまず停止シーケンスを開始し、次にクラスを再初期化し、その後開始シーケンスを実行します。
たとえば、完全なアプリケーション ライフサイクル イベント セット (preStart、postStart、preStop、postStop) に対してリスナが登録されている場合、完全な再デプロイメント時に次のイベント シーケンスが表示されます。
|
|
|