Inhalt Abbildung PDF Source SCWCD
 |<    <     >    >|  Generated by CoCoDiL

5.3 Filter

Describe the Web container request processing model; write and configure a filter; create a request or response wrapper; and given a design problem, describe how to apply a filter or a wrapper.

5.3.1 Was sind Filter

Filter setzen sich vor einem Servlet. Sie können Anfragen abblocken, bzw ändern und sie können Antworten ändern. Mehrere Filter können zu einer Filterkette zusammengebaut werden.


Abb. 5.1: Prinzip der Filter

Enthält ein Filter eine Anfrage, so hat er prinzipiell folgende Möglichkeiten:

Typische Aufgaben eines Filters sind:

5.3.2 Das Request Processing Model

Wenn ein Servlet Container eine Anfrage erhält, passiert folgendes:

  1. Anhand der servlet-mapping Elemente in Datei web.xml sucht er das Ziel-Servlet.
  2. Anhand der filter-mappging Elemente in Datei web.xml sucht er die Filter die dem Ziel Servlet vorgeschaltet werden. Der Container laedt diese Filter entsprechend dem <filter> Elementen der Datei web.xml, instantiiert und initialisiert sie.
  3. Der Container baut die gefundenen Filter zu einer Filterkette zusammen.
  4. Die Anfrage wird an den ersten Filter geleitet.
  5. Es ist dann die Aufgabe des jeweiligen Filters die Anfrage an den nächsten Filter weiterzuleiten (oder auch nicht).

5.3.3 Konfiguration einer Filterkette

Ein Filter wird in der Descriptor Datei nach folgender Syntax definiert


Abb. 5.2: Aufbau eines Filter Elementes

Ein filter Element hat fast den gleichen Aufbau eines servlet Elements, und braucht daher keine weitere Erklärung.

Entscheident welche Filter vor einem Servlet gestellt werden ist das filter-mapping Element.


Abb. 5.3: Aufau eines Filter Mapping Elements

Beispiel:

Das Element dispatcher kann innerhalb vom filter-mapping 4 mal vorkommen, und folgende Werte annehmen:

FORWARDFilter wird angewendet, wenn die Anfrage auf das Servlet mittels forward Befehl und RequestDispatcher zugegriffen wird
INCLUDEFilter wird angewendet, wenn die Anfrage auf das Servlet mittels include Befehl und RequestDispatcher zugegriffen wird
REQUESTDies ist die Standareinstellung und wird genommen, falls die Anfrage an das Servlet direkt vom Clienten kommt
ERRORDies wird genommen falls das Servlet ueber den error-mapping Mechanismus aufgerufen wird

Bemerkung: Der RequestDispatcher Mechanismus dient dazu Anfragen von einem Servlet an ein anderes einzubinden, ohne dass der Browser es mitbekommt (im Gegensatz zu sendRedirect()), Dieser Mechanismus wird später behandelt.

So findet ein Servlet Container die Filter zu einem Servlet:

  1. Jeder Filter dessen url-pattern das Servlet matcht, wird als Filter genommen. Die Regeln für das url-pattern sind dieselbe wie beim servlet-mapping Element
  2. Jeder Filter dessen servlet-name dem zugehörigen Servlet entspricht, wird als Filter genommen.
  3. Die Reihenfolge der Filter wird folgendermassen definiert
    1. Nehme zuerst die Filter die durch ein url-pattern gematcht wurden.
    2. Nehme danach die Filter die durch servlet-name gematcht wurden.
    3. lnnerhalb dieser 2 Gruppen entscheidet die Reihenfolge in der die Filter in der Datei web.xml definiert sind.

5.3.4 Das Filter Interface

Jeder Filter muss das folgende Interface erfüllen:

die Methoden init(), doFilter() und destroy() spiegeln den Lebenszyklus eines Filters wieder.

init() Methode

Die init(FilterConfig) Methode entspricht der init(ServletConfig) Methode eines Servlets. FilterConfig enthält alle Initialisierungsparameter aus der web.xml Datei.

Das folgende FilterConfig Interface zeigt, wie man diese Initialisierungsparameter ausliest.

doFilter() Methode

Die doFilter() Methode ist analog zur service() Methode eines Servlets. Beachte dass als Argument kein HttpServletRequest und HttpServletResponse besitzt, sondern ein ServletRequest bzw. ServletResponse übergeben wird. Im allgemeinen wird auf am Anfang einer doFilter() Methode, die Argumente zu den entsprechenden Http Typen gecastet.

Zusätzlich hat die doFilter() Methode ein FilterChain Objekt als Argument.

Das FilterChain Objekt dient dazu mit der doFilter Methode eine Anfrage an den nächsten Filter in der Filterkette (bzw. dem entgütigen Servlet) weiterzuleiten.

destroy() Methode

Die destroy() Methode wird als letzte Methode aufgerufen, kurz bevor der Filter zerstört wird. Sie ist analog der destroy() Methode eines Servlets.

5.3.5 Umgang mit ServletRequestWrappers bzw. -ResponseWrappers

Es existieren 4 verschiedene Wrapper Klassen:

Eine Wrapperklasse hat als Constructor genau ein Argument, das das Objekt enthaelt, was der Wrapper umwickelt. Dieses Argument hat ein je nach Art des Wrappers eine konkrete Klasse des (Http) ServletRequest bzw. (Http) ServletResponse.

Beispiel: Im unteren Beispiel, wird dem nächsten Filter kein HttpServletResponse Objekt mitgegeben, sondern einen Wrapper um das HttpServletResponse Objekt.

Was haben wir dadurch gewonnen?. So wie das obige Beispiel implementiert ist, zunächst mal nichts. Der Wrapper hat dasselbe Interface wie das umwickelte Objekt. Die Anfragen an den Wrapper werden einfach an das umwickelte Objekt weitergeleitet.


Abb. 5.4: Grundprinzip der Wrapper

Der Programmierer wird i.a. nicht direkt die angegebenen Wrapper benutzen, sondern Unterklassen davon verwenden.

In diese Unterklasse kann man z.B. implementieren dass die erzeugten Fehler mitprotokolliert werden.

Beispiel


Abb. 5.5: Anwendungsbeispiel eines ResponseWrappers

Ein Wrapper dient dazu das Verhalten des umwickelten Objekts seinen eigenen Bedürfnissen anzupassen, ohne das umwickelte Objekt ändern zu müssen. Man könnte z.B. auch einen ResponseWrapper implementieren, der mit getOutputStream() statt einen normalen OutputStream ein Stream erzeugt, der die enthaltene Daten komprimiert.

Beachte HttpServletResponse ist ein Interface und keine Klasse. Der Wrapper weiss gar nicht, welche konkrete Klasse das Objekt besitzt, das er umwickelt. Der Wrapper kann aber trotzdem das Verhalten des umwickelten Objekts seinen Bedürfnissen anpassen.

Inhalt Abbildung PDF Source SCWCD
 |<    <     >    >|  Generated by CoCoDiL