Servlet Listener

---

Servlet Listener sind Klassen, die ein Servlet Listener Interface implementieren, im DD der Anwendung dem Container bekannt gemacht werden und bei Lifecycle Ereignissen der Webanwendung vom Container gerufen werden. Listener werden pro Anwendung einmal in der Reihenfolge ihres Erscheinens im DD instanziiert, sie sind Application-Singletons. Die Angabe eines Typs ist nicht notwendig, der Container ermittelt diesen per Introspektion. Die Listenerklasse muss den Standardkonstruktor besitzen, damit der Container eine Instanz zur Abarbeitung des Events erzeugen kann.

<listener>
  <listener-class>
    a.b.MyRequestListener
  </listener-class>
</listener>

Beim Runterfahren der Anwendung werden erst die Session-Listener, dann die Context-Listener in der umgekehrten Reihenfolge ihres Erscheinens im DD benachrichtigt.

Die Singletoneigenschaft der Listenerinstanzen erzwingt, dass Zustände der entsprechenden Scopes nicht in den Listenerklassen gehalten werden dürfen. Zustände werden am entsprechenden Scope über die setAttribute-Methode hinterlegt. In einer Multithreadumgebung wie der eines Webcontainers werden diese Attribute potenziell nebenläufig geändert. Der Container wird in keiner Weise die Aufrufe unterschiedlicher Requests synchronisieren. Die Listener Implementierungen müssen selbst dafür sorgen und es gilt ähnlich wie für Filter: nichttriviale Listener werden synchronisierten Code enthalten und die Synchronisation erfolgt am entsprechenden Scope. Ein typisches Codefragment für das Setzen eines Zustands im Scope der Session eines Nutzers sieht dann so aus:

..
HttpSession session = event.getSession();
synchronized (session) {
  session.setAttribute("SOME_STATE", new Integer(1));
}
..

In Clusterumgebungen werden Lifecycle Events nicht zwischen den Knoten ausgetauscht.

Servlet Listener für den Lifecycle der Scopes

---

Es gibt drei Listener für die Lifecycle Ereignisse der drei Scopes:

Scope	Application	Session	Request
Interface	ServletContextListener	HttpSessionListener	ServletRequestListener
Ereignis	Starten und Stoppen der Anwendung	Erstellen oder Verwerfen einer HttpSession	Start und Ende eines Requests
Methoden	contextInitialized/Destroyed	sessionCreated/Destroyed	requestInitialized/Destroyed
Ereignisobjekt	ServletContextEvent	HttpSessionEvent	ServletRequestEvent
Objekte für Zustandsänderungen und Synchronisation	ServletContext	HttpSession oder ServletContext	ServletRequest, HttpSession oder ServletContext

Ein Servlet Lifecycle Listener ist überflüssig: der Lebenszyklus der Servlets selber wird über die init und destroy Callbacks am Servlet kontrolliert.

Servlet Listener für den Lifecycle der Scope-Attribute

---

Über die setAttribute und removeAttribute Methoden der Scopes können dort benamte Objektinstanzen hinterlegt werden, die den Status des entsprechenden Scopes repräsentieren. Für die dabei eintretenden Ereignisse kann man für die drei Scopes Listener anmelden:

Scope	Application	Session	Request
Interface	ServletContextAttributeListener	HttpSessionAttributeListener	ServletRequestAttributeListener
Ereignis	Attribut im Scope "Application" (Context) wird hinzugefügt, geändert oder gelöscht	Attribut im Scope "Session" wird hinzugefügt, geändert oder gelöscht	Attribut im Scope "Request" wird hinzugefügt, geändert oder gelöscht
Methoden	attributeAdded/Removed/Replaced	attributeAdded/Removed/Replaced	attributeAdded/Removed/Replaced
Ereignisobjekt	ServletContextAttributeEvent	HttpSessionBindingEvent	ServletRequestAttributeEvent
Synchronisation	ServletContext	HttpSession oder ServletContext	ServletRequest, HttpSession oder ServletContext

Achtung! Das Event enthält immer den alten Wert, auch bei attributeReplaced.

Einen "Servlet"AttributeListener gibt es nicht, denn Servlet-"Attribute" sind einfach Klassenvariablen!

HttpSessionActivationListener und HttpSessionBindingListener

---

Diese Listener werden direkt von den Attributklassen implementiert. Eine Deklaration im Deployment Deskriptor ist nicht erforderlich, die Klassen werden benachrichtigt, wenn sie als Attribute das entsprechende Interface implementieren.

• Eine Klasse die HttpSessionBindingListener implementiert, wird benachrichtigt, wenn ihre Instanzen einer Session hinzugefügt oder weggenommen werden. Typischer Einsatszweck ist die Initialisierung und Freigabe von Ressourcen im betroffenen Objekt.

public interface HttpSessionBindingListener {
  void valueBound(HttpSessionBindingEvent event);
  void valueUnbound(HttpSessionBindingEvent event);
}

• Klassen, die HttpSessionActivationListener implementieren, werden gerufen, wenn eine Session von einem Knoten eines Serverclusters zu einem anderen Knoten migiriert wird (Sessionmigration). Wird zum Beispiel ein Knoten im Cluster runtergefahren, werden alle Sessions serialisiert zu anderen Knoten geschickt und dort wieder deserialisiert. WIE die Serialisierung erfolgt ist containerspezifisch. Für Attribute die als Serializable gekennzeichnet sind ist zugesichert, dass sie an der Sessionmigration beteiligt werden. Der Server ist aber nicht gezwungen den Standardmechanimus der Serialisierung zu benutzen, das heißt es wird nicht notwendig writeObject() oder readResolve() der beteiligten Instanzen gerufen. Sollten gewisse Attribute einer Session für die Passivierung / Aktivierung besondere Behandlung erfordern, dann muss das Attribut HttpSessionActivationListener implementieren:

public interface HttpSessionActivationListener {
  void sessionDidActivate(HttpSessionEvent event);
  void sessionWillPassivate(HttpSessionEvent event);
}