Whats the difference between DelegatingFilterProxy and GenericFilterBean?

Question

• DelegatingFilterProxy enables you to use a Spring Bean as a servlet filter. So you can use the spring context inside the filter, inject other beans and so on. It extends GenericFilterBean in order to gain this functionality.
• GenericFilterBean enables you to do the same.

Both classes seem to claim to provide the same functionality in the end. Both classes seem to be able to be wired directly in the web.xml . The code of DelegatingFilterProxy seems to be just a thin layer of indirection.

But why is this even necessary, where you could just extend GenericFilterBean instead? Why, for example, does Spring Security use a DelegatingFilterProxy in order to call the FilterChainProxy , although the latter already extends GenericFilterBean ?

Answer 1

It extends GenericFilterBean in order to gain this functionality.

I think I'd word that differently. According to GenericFilterBean 's JavaDoc :

/**
 * This generic filter base class has no dependency on the Spring  
 * org.springframework.context.ApplicationContext concept. Filters usually 
 * don't load their own context but rather access service beans from the 
 * Spring root application context, accessible via the filter's 
 * ServletContext
 **/

Note also from GenericFilterBean 's JavaDoc:

/**
 * This filter leaves actual filtering to subclasses, which have to implement 
 * the Filter.doFilter method.
 **/

Or, IOW, GenericFilterBean picks up init-param s, registers them as Spring bean properties, and applies those properties to the filter. init-param s are limited in their capacity and also doFilter still needs implementing either way.

This is where DelegatingFilterProxy comes in. It looks up a bean of type Filter from the application context and proxies to it in its own doFilter method. This proxy allows applications to specify a bean of type Filter that relies on Spring's lifecycle instead of the servlet container's.

You can see this detailed in DelegatingFilterProxy 's JavaDoc :

/**
  * This approach is particularly useful for Filter implementation with 
  * complex setup needs, allowing to apply the full Spring bean definition 
  * machinery to Filter instances.
  */

NOTE : Spring Boot applications can alternatively publish beans of type FilterRegistrationBean to specify both the underlying filter, its order and dispatcher types.

Both classes seem to be able to be wired directly in the web.xml

What gives you this impression? Given that GenericFilterBean is abstract , I'm not clear on how it could be referenced in a web.xml file. The Servlet container would not be able to construct it.

does Spring Security use a DelegatingFilterProxy in order to call the FilterChainProxy

Yes .

Spring Security chooses to use the Filter API instead of inventing its own. Because of that, it fits nicely inside the purpose of DelegatingFilterProxy . (You can imagine how limiting it might be for folks to configure Spring Security though web.xml init-param s alone, for example.)

Hypothetically, if Spring Security had decided to create its own filter-like API, it would have its own implementation of GenericFilterBean that implements doFilter differently.

although the latter already extends GenericFilterBean

I think this part of your question is asking "couldn't FilterChainProxy just be specified as a filter to the servlet container since it implements GenericFilterBean ?". And the answer is "no" . From Spring Security's docs:

Another benefit of DelegatingFilterProxy is that it allows delaying looking Filter bean instances. This is important because the container needs to register the Filter instances before the container can startup. However, Spring typically uses a ContextLoaderListener to load the Spring Beans which will not be done until after the Filter instances need to be registered.

Why does it extend GenericFilterBean , then? Most Spring filters extend GenericFilterBean because it allows more flexibility for applications to use them like building blocks. Like its JavaDoc says:

/**
  * A handy superclass for any type of filter.
  */