Note that the filter in Listing 6-1 uses the initialization parameter targetClass . The
servlet filter delegates the actual processing to this FilterChainProxy . On initialization,
the Spring Security filter gateway looks for a bean of type FilterChainProxy in the Spring
web application context. It then delegates all the handling to this filter chain proxy. You
can configure multiple filter chain proxies. In that case, the one found first will be used.
If no filter chain proxy object is found, an exception will be raised. It is possible to set the
targetBean initialization parameter instead of targetClass . This will allow the gateway
filter to look for a bean with the given name in the application context. But this can lead
to a bug that's hard to detect. If you rename this bean in the Spring configuration, you
will have to do the same in web.xml as well. The filter mapping configuration in Listing 6-1
forces all web requests to be passed through this filter.
For Spring Security to work, the Spring application context must be loaded. Since
the goal all along has been to separate security concerns from presentation concerns,
ContextLoaderListener will load the application context for Spring Security. This will load
the parent Spring web application context. The dispatcher servlet described in Chapter 2
will load its own application context with the presentation tier beans. This application
context is a child of the context loaded by the servlet context listener, as shown in
Listing 6-2. The parent web application context will be loaded from the classpath
resource applicationContext-security.xml . Note that the Spring web application context
is bound to the servlet context, so there is no performance concern here because you're
not reloading the context for each request.
Listing 6-2. web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns= http://java.sun.com/xml/ns/j2ee