Lessons learned - Der DelegatingFilterProxy von Spring

Wenn man einen ServletFilter für die eigene Webapp baut, dann muss man drei Methoden des Interfaces implementieren: init(), doFilter() und destroy(). Der Filter wird danach in die web.xml aufgenommen und startet zusammen mit der Webapp, wobei beim Starten des Filters seine init()-Methode aufgerufen wird.

So weit die Theorie. Spring ermöglicht es, Filter im ApplicationContext zu definieren und ihnen damit Zugriff auf andere Beans zu bieten. Über die Namenskonvention Filtername == BeanId wird nun nicht mehr die Filterklasse in der web.xml eingetragen, sondern eine Klasse aus Spring:

 <filter>
   <filter-name>beispielFilter</filter-name>
   <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
 </filter>
 <filter-mapping>
   <filter-name>beispielFilter</filter-name>
   <url-pattern>/*</url-pattern>
 </filter-mapping>

Ärgerlicherweise führt diese per Default nicht die init()– und destroy()-Methoden aus. Im JavaDoc findet sich der entscheidende Hinweise: Ein init-Parameter muss in der web.xml gesetzt werden, damit der Filter-Lifecycle durchgeführt wird. Dies sieht am Ende so aus:

 <filter>
   <filter-name>beispielFilter</filter-name>
   <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
   <init-param>
     <param-name>targetFilterLifecycle</param-name>
     <param-value>true</param-value>
   </init-param>
 </filter>