プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebLogic Serverアプリケーションの開発
12c (12.2.1.3.0)
E90359-04
目次へ移動
目次

前
次

13 アプリケーション・ライフサイクル・イベントのプログラミング

WebLogic Serverのアプリケーション・ライフ・サイクル・イベントに応答するアプリケーションの作成方法について説明します。

この章の内容は次のとおりです。

アプリケーション・ライフサイクル・イベントの理解

アプリケーション・ライフサイクル・リスナー・イベントは、デプロイメント、アンデプロイメント、および再デプロイメント時の動作を開発者が制御できるハンドルを提供します。アプリケーション・ライフサイクル・リスナー・イベントの使用方法について説明します。

WebLogic Serverには、リスナー・クラス、停止クラス、および起動クラスを拡張するときに使用できる4つのアプリケーション・ライフサイクル・イベントがあります。以下のものが含まれます。

  • リスナー - 任意のイベントにアタッチできます。リスナーのメソッドの例は次のとおりです。

    • public void preStart(ApplicationLifecycleEvent evt) {}

      preStartイベントは、準備フェーズを開始、またはアプリケーションのデプロイメント・プロセスを開始します。

    • public void postStart(ApplicationLifecycleEvent evt) {}

      postStartイベントは、アクティブ化フェーズを終了、またはアプリケーションのデプロイメント・プロセスを終了します。アプリケーションがデプロイされます。

    • public void preStop(ApplicationLifecycleEvent evt) {}

      preStopイベントは、非アクティブ化フェーズを開始、またはアプリケーションの削除またはアンデプロイメントのプロセスを開始します。

    • public void postStop(ApplicationLifecycleEvent evt) {}

      postStopイベントは、削除フェーズを終了、またはアプリケーションの削除またはアンデプロイメントのプロセスを終了します。

  • 停止クラスはpostStopイベントのみを取得します。

    注意:

    アプリケーション・スコープの停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。代わりに、ライフサイクル・リスナーを使用してください。

  • 起動クラスはpreStartイベントのみを取得します。

    注意:

    アプリケーション・スコープの停止クラスは、WebLogic Serverのリリース9.0以降では非推奨になりました。代わりに、ライフサイクル・リスナーを使用してください。

    起動クラスおよび停止クラスでは、main{}メソッドのみを実装します。リスナー用に提供されたメソッドを実装した場合は、無視されます。

    ApplicationLifecycleListenerremove{}メソッドは提供されていません。イベントが、デプロイメントでの起動時(prestartとpoststart)およびアンデプロイメントでの停止時(prestopとpoststop)にのみ開始されるためです。

weblogic-application.xmlへのイベントの登録

それらを使用するには、weblogic-application.xmlデプロイメント記述子にアプリケーション・ライフサイクル・リスナー・イベントを登録する必要があります。

エンタープライズ・アプリケーションのデプロイメント記述子の要素を参照してください。以下の要素を定義します。

  • listener - ユーザー定義のアプリケーション・ライフサイクル・リスナーを登録するときに使用します。これらは、抽象ベース・クラスweblogic.application.ApplicationLifecycleListenerを拡張するクラスです。

  • shutdown - ユーザー定義の停止クラスを登録するときに使用します。

  • startup - ユーザー定義の起動クラスを登録するときに使用します。

基本的なライフサイクル・リスナー機能のプログラミング

抽象クラス(WebLogic Server付属のクラス) weblogic.application.ApplicationLifecycleListenerを拡張することにより、リスナーを作成することができます。作成したリスナーは、コンテナの検索対象になります。

WebLogic ServerのApplicationLifecycleListener抽象クラスに提供されている次のメソッドをオーバーライドし、必要な機能を追加してアプリケーションを拡張します。

  • preStart{}

  • postStart{}

  • preStop{}

  • postStop{}

例13-1は、ApplicationLifecycleListenerをオーバーライドする方法を示します。この例では、パブリック・クラスMyListenerがApplicationLifecycleListenerを拡張しています。

例13-1 MyListener

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
}

例13-2に、停止クラスを実装する方法を示します。停止クラスは、preStopイベントおよびpostStopイベントにアタッチできます。この例では、パブリック・クラスMyShutdownApplicationLifecycleListenerを拡張しません。これは、weblogic-application.xmlデプロイメント記述子で宣言された停止クラスはWebLogic Server固有のインタフェースに依存しないためです。

例13-2 MyShutdown

import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyShutdown {
   public static void main(String[] args) {
     System.out.println
     ("MyShutdown(main): in main .. should be for post-stop");
   } // main
}

例13-3に、起動クラスを実装する方法を示します。起動クラスは、preStartイベントおよびpostStartイベントにアタッチできます。この例では、パブリック・クラスMyStartupApplicationLifecycleListenerを拡張しません。これは、weblogic-application.xmlデプロイメント記述子で宣言された起動クラスはWebLogic Server固有のインタフェースに依存しないためです。

例13-3 MyStartup

import weblogic.application.ApplicationLifecycleListener;
import weblogic.application.ApplicationLifecycleEvent;
public class MyStartup {
   public static void main(String[] args) {
     System.out.println
     ("MyStartup(main): in main .. should be for pre-start");
   } // main
}

ロールベースのアプリケーション・ライフサイクル・リスナーの構成

run-as-principal-name要素を使用して起動イベントや停止イベントに対してユーザーIDを指定できる、ロールベース機能を備えたアプリケーション・ライフサイクル・イベントを構成できます。ただし、アプリケーション・ライフサイクル・リスナー用に定義されたrun-as-principal-name IDが管理者である場合、アプリケーション・デプロイヤには管理者権限が必要です。管理者権限がない場合、デプロイメントは失敗します。

  1. 「基本的なライフサイクル・リスナー機能のプログラミング」で説明した基本的なプログラミング手順に従います。
  2. listener要素内に、run-as-principal-name要素を追加して、イベントの起動や停止を行う権限のあるユーザーを指定します。例:
    <listener>
      <listener-class>myApp.MySessionAttributeListenerClass</listener-class>
      <run-as-principal-name>javajoe</run-as-principal-name>
    </listener>
    

ここに指定するIDはシステムの有効なユーザー名である必要があります。run-as-principal-nameを指定しない場合、アプリケーション・ライフサイクル・リスナーの実行のためのrun-as IDとしては、デプロイメント・イニシエータのユーザーIDが使用されます。

URIパラメータを指定した場合と指定しない場合のライフサイクル・イベントの構成例

weblogic-application.xmlデプロイメント記述子ファイルで、URIパラメータを使用する、または使用せずにアプリケーション・ライフサイクル・イベントを構成できます。

次の例に、weblogic-application.xmlデプロイメント記述子ファイルでアプリケーション・ライフサイクル・イベントを構成する方法を示します。URIパラメータは必須ではありません。アプリケーションの$CLASSPATH内であれば任意の位置にクラスを配置できます。ただし、$CLASSPATHにクラスの位置を定義する必要があります。EARにAPP-INF/classesディレクトリまたはAPP-INF/libディレクトリが存在する場合は、これらのディレクトリにリスナーを配置できます。この場合、リスナーは自動的に$CLASSPATHに含まれます。

次の例に、URIパラメータを使用してアプリケーション・ライフサイクル・イベントを構成する方法を示します。この例では、アーカイブfoo.jarはクラスを含み、EARファイルの最上位に存在します。(例: myEar/foo.jar)

例13-4 URIパラメータを使用したアプリケーション・ライフサイクル・イベントの構成

<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パラメータを使用せずにアプリケーション・ライフサイクル・イベントを構成する方法を示します。

例13-5 URIパラメータを使用しないアプリケーション・ライフサイクル・イベントの構成

<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)に対してリスナーが登録されている場合、完全な再デプロイメント時に次のイベント・シーケンスが表示されます。

  1. preStop{}

  2. postStop{}

  3. 初期化が開始されます。(デバッグ・フラグを設定していない場合、初期化は表示されません。)

  4. preStart{}

  5. postStart{}

アプリケーション・バージョン・ライフサイクル・イベントのプログラミング

WebLogic Serverのアプリケーション・バージョン・ライフサイクル・イベントに応答するアプリケーションの作成方法について説明します。

アプリケーション・バージョン・ライフサイクル・イベントの動作の理解

WebLogic Serverはアプリケーション・バージョン・ライフサイクル・イベントの通知を提供しており、ApplicationVersionLifecycleListenerクラスを拡張してweblogic-application.xmlでライフサイクル・リスナーを指定できます。エンタープライズ・アプリケーションのデプロイメント記述子の要素URIパラメータを指定した場合と指定しない場合のライフサイクル・イベントの構成例を参照してください。

アプリケーション・バージョン・ライフサイクル・イベントは次のように呼び出されます。

  • 静的なデプロイメントと動的なデプロイメントの両方の場合。

  • 匿名IDとユーザーIDのいずれかを使用して。

  • 現在のアプリケーションがバージョン管理されている場合のみ。それ以外の場合、バージョン・ライフサイクル・イベントは無視されます。

  • リスナーを登録しているバージョンを含めて、すべてのアプリケーション・バージョンについて。イベントが特定のバージョンに属しているかどうかを調べるには、ApplicationVersionLifecycleEvent.isOwnVersionメソッドを使用します。バージョン・ライフサイクル・イベントの種類の詳細は、ApplicationVersionLifecycleEventクラスを参照してください。

アプリケーション・バージョン・ライフサイクル・イベントの種類

WebLogic Serverには4つのアプリケーション・バージョン・ライフサイクル・イベントがあります。

  • public void preDeploy(ApplicationVersionLifecycleEvent evt)

    • preDeloyイベントは、アプリケーション・バージョンのデプロイまたは再デプロイ操作が開始されたときに呼び出されます。

  • public void postDeploy(ApplicationVersionLifecycleEvent evt)

    • postDeloyイベントは、アプリケーション・バージョンが正常にデプロイまたは再デプロイされたときに呼び出されます。

  • public void preUndeploy(ApplicationVersionLifecycleEvent evt)

    • preUndeloyイベントは、アプリケーション・バージョンのアンデプロイ操作が開始されたときに呼び出されます。

  • public void postDelete(ApplicationVersionLifecycleEvent evt)

    • postDeleteイベントは、アプリケーション・バージョンが削除されたときに呼び出されます。

      注意:

      postDeleteイベントは、アプリケーション・バージョン全体が完全に削除された後にのみ起動されます。これには、モジュールのアンデプロイやターゲットのサブセットからのアンデプロイなどの部分的なアンデプロイは含まれません。

アプリケーション・バージョン・ライフサイクル・イベントを使用する場合の本番デプロイメント・シーケンスの例

以下の表では、デプロイメント(V1)、本番再デプロイメント(V2)、およびアンデプロイ(V2)の例を示します。

表13-1 デプロイメント・アクションとアプリケーション・バージョン・ライフ・サイクル・イベントのシーケンス

デプロイメント・アクション 時間 バージョンV1 バージョンV2

バージョンV1のデプロイメント

T0

preDeploy(V1)が呼び出されます。

バージョンV1のデプロイメント

T1

デプロイメントが開始されます。

バージョンV1のデプロイメント

T2

V1のアプリケーション・ライフサイクル・リスナーが登録されます。

バージョンV1のデプロイメント

T3

V1がアクティブなバージョンとなり、デプロイメントが完了します。

バージョンV1のデプロイメント

T4

postDeploy(V1)が呼び出されます。

バージョンV1のデプロイメント

T5

アプリケーション・リスナーがpostDeploy(V1)を取得します。

バージョンV2の本番再デプロイメント

T6

preDeploy(V2)が呼び出されます。

バージョンV2の本番再デプロイメント

T7

アプリケーション・バージョン・リスナーがpreDeploy(V1)を受け取ります。

バージョンV2の本番再デプロイメント

T8

デプロイメントが開始されます。

バージョンV2の本番再デプロイメント

T9

V2のアプリケーション・ライフサイクル・リスナーが登録されます。

バージョンV2の本番再デプロイメント

T10

デプロイ(V2)が成功すると、V1はアクティブなバージョンでなくなります。

デプロイ(V2)が成功すると、V2はV1に代わってアクティブなバージョンとなります。

デプロイメントが完了します。

バージョンV2の本番再デプロイメント

T11

postDeploy(V2)が呼び出されます。

注意:このイベントはデプロイメントが失敗した場合でも発生します。

バージョンV2の本番再デプロイメント

T12

アプリケーション・バージョン・リスナーがpostDeploy(V2)を取得します。デプロイ(V2)が失敗した場合、V1はアクティブなままとなります。

バージョンV2の本番再デプロイメント

T13

アプリケーション・リスナーがpostDeploy(V2)を取得します。

バージョンV2の本番再デプロイメント

T14

デプロイ(V2)が成功すると、V1はリタイアを開始します。

バージョンV2の本番再デプロイメント

T15

V1のアプリケーション・リスナーが登録解除されます。

バージョンV2の本番再デプロイメント

T16

V1がリタイアされます。

V2のアンデプロイメント

T17

preUndeploy(v2)が呼び出されます。

V2のアンデプロイメント

T18

アプリケーション・リスナーは呼び出されたpreUndeploy(v2)を取得します。

V2のアンデプロイメント

T19

アンデプロイメントが開始されます。

V2のアンデプロイメント

T20

V2がアクティブなバージョンでなくなります。

V2のアンデプロイメント

T21

V2のアプリケーション・バージョン・リスナーが登録解除されます。

V2のアンデプロイメント

T22

アンデプロイメントが完了します。

V2のアンデプロイメント

T23

アプリケーション全体がアンデプロイされると、postDelete(V2)が呼び出されます。

注意:このイベントはアンデプロイメントが失敗した場合でも発生します。