Servlet3.1ライフサイクルイベントの適用(転載)
5929 ワード
ライフサイクルイベントの適用
11.1紹介
アプリケーションイベント施設は、Webアプリケーション開発者にサーブレットContext、HttpSession、およびサーブレットRequestのライフサイクルをよりよく制御し、コード分解をよりよくし、Webアプリケーションで使用されるリソースを管理する上で効率を向上させることができます.
11.2イベントリスナー
アプリケーション・イベント・リスナーは、1つまたは複数のサーブレット・イベント・リスナー・インタフェースを実装するクラスです.これらは、Webアプリケーションを配備する際に、Webコンテナにインスタンス化されて登録されます.開発者がWARパッケージで提供します.
サーブレットイベントリスナーは、サーブレットContext、HttpSession、およびサーブレットRequestの状態が変化したときのイベント通知をサポートします.サーブレットコンテキストリスナーは、アプリケーションを管理するために使用されるリソースまたはJVMレベルが所有する状態です.HTTPセッションリスナーは、同じクライアントまたはユーザからウェブアプリケーションにアクセスする一連の要求に関連付けられた状態またはリソースを管理するために使用される.サーブレットリクエストリスナーは、サーブレットリクエストのライフサイクル全体を管理するための状態です.非同期リスナーは、タイムアウトや非同期処理の完了などの非同期イベントを管理するために使用されます.
複数のリスナークラスが各イベントタイプをリスニングでき、開発者は各イベントタイプに対してコンテナ呼び出しリスナーbeanの順序を指定できます.
11.2.1イベントタイプとListenerインタフェース
イベント・タイプとListenerインタフェースは、次の表に示すように監視されます.
表11-1サーブレットコンテキストイベント
イベントのタイプ
説明
Listenerインタフェース
ライフサイクル
サーブレットコンテキストが作成され、最初のリクエストにサービスできるようになりました.または、サーブレットコンテキストが閉じます.
javax.servlet. ServletContextListener
属性の変更
サーブレットコンテキストのプロパティが追加、削除、または置換されています.
javax.servlet. ServletContextAttributeListener
表11-2 HTTPセッションイベント
イベントのタイプ
説明
Listenerインタフェース
ライフサイクル
セッションは作成、破棄、またはタイムアウトされました.
javax.servlet.http. HttpSessionListener
属性の変更
HttpSessionで属性を追加、削除、または置換しました.
javax.servlet.http. HttpSessionAttributeListener
セッションの移行
HttpSessionがアクティブまたはパッシベーションされています.
javax.servlet.http. HttpSessionActivationListener
オブジェクトバインド
HttpSessionからオブジェクトがバインド解除されました
javax.servlet.http. HttpSessionBindingListener
表11-3サーブレット要求イベント
イベントのタイプ
説明
Listenerインタフェース
ライフサイクル
1つのservletリクエストは、Webコンポーネントによって処理され始めました.
javax.servlet. ServletRequestListener
属性の変更
サーブレットリクエストで属性を追加、削除、または置換しました.
javax.servlet. ServletRequestAttributeListener
非同期イベント
タイムアウト、接続終了、または非同期処理の完了
javax.servlet.AsyncListener
11.2.2 Listenerの使用例
イベントの使用方法を説明するために、データベースを使用するサーブレットを含む簡単なWebアプリケーションを考慮します.開発者は、サーブレットコンテキストリスナークラスを提供し、データベース接続を管理します.
1.アプリケーションが起動すると、Listenerクラスが通知されます.アプリケーションはデータベースにログインし、servletコンテキストに接続を格納します.
2.アプリケーションのサーブレットは、必要に応じて、Webアプリケーションのアクティブな期間に接続にアクセスします.
3.Listenerクラスは、Webサーバがシャットダウンされたとき、またはアプリケーションがWebサーバから削除されたときに、データベース接続をシャットダウンするよう通知されます.
11.3 Listenerクラスの構成
11.3.1リスナークラスの提供
Webアプリケーションの開発者はjavaxで1つ以上を実現する.servlet APIのListenerインタフェースのListenerクラス.各リスナークラスには、無パラメトリックコンストラクタが必要です.ListenerクラスはWARパッケージにパッケージ化されているか、WEB-INF/classesアーカイブの下にあるか、WEB-INF/libディレクトリのJAR内部にある.
11.3.2配置宣言
Listenerクラスは、Webアプリケーションデプロイメント記述子でlistener要素宣言を使用します.クラス名に基づいて呼び出される順序です.他のListenerとは異なり、AsyncListenerタイプのListenerはプログラミングのみで登録される場合があります(サーブレットRequestを使用します).
11.3.3 Listenerの登録
Webコンテナは、各リスナークラスのインスタンスを作成し、最初のリクエストを処理する前にイベント通知に登録します.Webコンテナは、実装されたインタフェースに基づいてリスナーインスタンスを登録し、配置記述子に表示される順序に従います.Webアプリケーションの実行中に、Listenerは登録順に呼び出されます.
11.3.4クローズ時通知
アプリケーションが閉じると、リスナーは宣言時とは逆の順序で通知され、コンテキストリスナーに通知する前にセッションリスナーに通知されます.通知セッションリスナーセッションセッションセッションが無効になるには、通知コンテキストリスナーが閉じる前にする必要があります.
11.4配置記述子の例
次の例は、2つのサーブレットコンテキストライフサイクルリスナーと1つのHttpSessionリスナーを登録する配置構文です.
仮定com.acme.MyConnectionManagerとcom.acme.MyLoggingModuleは両方ともjavaxを実現しました.servlet.ServeretContextListener,com.acme.MyLoggingModuleはjavaxを実現した.servlet.http.HttpSessionListener.また、開発者はcom.acme.MyConnectionManagerはcom.acme.MyLoggingModuleは、サーブレットコンテキストのライフサイクルイベントの通知を受けます.次に、このアプリケーションのデプロイメント記述子を示します.
<web-app>
<display-name>MyListeningApplication</display-name>
<listener>
<listener-class>com.acme.MyConnectionManager</listener-class>
</listener>
<listener>
<listener-class>com.acme.MyLoggingModule</listener-class>
</listener>
<servlet>
<display-name>RegistrationServlet</display-name>
...etc
</servlet>
</web-app>
<web-app>
<display-name>MyListeningApplication</display-name>
<listener>
<listener-class>com.acme.MyConnectionManager</listener-class>
</listener>
<listener>
<listener-class>com.acme.MyLoggingModule</listener-class>
</listener>
<servlet>
<display-name>RegistrationServlet</display-name>
...etc
</servlet>
</web-app>11.5 Listenerインスタンスとスレッド
コンテナは、アプリケーションへの最初のリクエストの実行を開始する前に、Webアプリケーションのリスナークラスのインスタンス化を完了する必要があります.コンテナは、Webアプリケーションの最後のリクエストにサービスを提供するまで、各リスナーの参照を維持する必要があります.
サーブレットContextとHttpSessionオブジェクトの属性変更が同時に発生する場合があります.コンテナがプロパティリスナークラスに同期して生成された通知は要求されません.メンテナンスステータスのリスナークラスは、データの整合性を担当し、この状況を明確に処理する必要があります.
11.6 Listener異常
リスナー内のアプリケーションコードが実行中に異常を放出する可能性があります.一部のリスナー通知は、アプリケーション内の別のコンポーネント呼び出しツリー中に発生します.この態様の一例は、サーブレットが未処理例外を放出するセッション属性を設定することである.コンテナは、未処理の例外を10.9節の「エラー処理」に記載されたエラーページメカニズムによって処理することを許可する必要があります.これらの例外にエラーページが指定されていない場合、コンテナは500のステータスコードの応答を返す必要があります.この場合、イベントに基づいてリスナーが呼び出されることはなくなります.
一部の例外は、アプリケーション内の別のコンポーネント呼び出しスタック中に発生しません.この態様の一例では、SessionListenerが通知を受信したセッションがタイムアウトして未処理の例外を投げ出すか、サーブレットContextListenerがサーブレットコンテキスト初期化通知中に未処理の例外を投げ出すか、サーブレットRequestListenerが要求オブジェクトを初期化または破棄する通知中に未処理の例外を投げ出す.この場合、開発者はこのような異常を処理する機会がありません.コンテナは、HTTPステータスコード500で、その後のWebアプリケーションへの要求に応答して、アプリケーションエラーを示すことができる.
開発者は、リスナーに異常が発生し、通知方法で自分の異常を処理しなければならない後の正常な処理を望んでいます.
11.7分散容器
分散型Webコンテナでは、HttpSessionインスタンスは、特定のJVMサービスセッション要求に限定され、サーブレットContextオブジェクトは、Webコンテナが存在するJVMに限定される.分散コンテナは、サーブレットコンテキストイベントまたはHttpSessionイベントを他のJVMに伝播する必要はありません.Listenerクラスインスタンスは、各JVMの各配置記述子宣言に限定される.
11.8セッションイベント
Listenerクラスは、Webアプリケーション内のセッションを追跡する方法を開発者に提供します.コンテナタイムアウトセッションのため、またはアプリケーション内のWebコンポーネントがinvalidateメソッドを呼び出したため、セッションが失効したかどうかを追跡するのに役立ちます.この違いは、リスナーおよびHttpSessionAPIメソッドの使用を間接的に決定する可能性がある.