Inhalt | Abbildung | Source | SCWCD | |||
|< | < | > | >| | Generated by CoCoDiL |
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. |
Enthält ein Filter eine Anfrage, so hat er prinzipiell folgende Möglichkeiten:
Typische Aufgaben eines Filters sind:
Wenn ein Servlet Container eine Anfrage erhält, passiert folgendes:
Ein Filter wird in der Descriptor Datei nach folgender Syntax definiert
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.
Beispiel:
Das Element dispatcher kann innerhalb vom filter-mapping 4 mal vorkommen, und folgende Werte annehmen:
FORWARD | Filter wird angewendet, wenn die Anfrage auf das Servlet mittels forward Befehl und RequestDispatcher zugegriffen wird |
INCLUDE | Filter wird angewendet, wenn die Anfrage auf das Servlet mittels include Befehl und RequestDispatcher zugegriffen wird |
REQUEST | Dies ist die Standareinstellung und wird genommen, falls die Anfrage an das Servlet direkt vom Clienten kommt |
ERROR | Dies 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:
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.
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.
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
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 | Source | SCWCD | |||
|< | < | > | >| | Generated by CoCoDiL |