Dynamically registering WebFilter with Java EE 6

DZone 's Guide to

Dynamically registering WebFilter with Java EE 6

· Java Zone ·
Free Resource

Yeah. Security. I start loving this stuff. I have a nice little application running with Java EE 6. And if you are following my posts lately, you know, that it has little more security requirements than usual and therefore we definitely have some custom filter logic in place. The javax.servlet.Filter is a great place to start, if you are looking for a way to implement cross cutting concerns.

Filters perform filtering in the doFilter method. Every Filter has access to a FilterConfig object from which it can obtain its initialization parameters, and a reference to the ServletContext which it can use, for example, to load resources needed for filtering tasks.

Beside Logging and Auditing, compression and conversion this is also suitable for placing security related stuff.

Beginning with Java EE 6 the implementation is straight forward and easy.

Add a @WebFilter annotation to your implementation class and you are done:

@WebFilter(dispatcherTypes = {DispatcherType.REQUEST, DispatcherType.FORWARD}, urlPatterns = {"/something/*"})
public class SecurityFilter implements Filter {


But: What to do, if you are running different environments and you have some very heavy filter logic in place, which in fact depends on other infrastructure components placing header variables or other stuff into the request before processing? You have to disable them in development. Enable them in production or integration testing.

Building for different environments basically is not a big issue, but you end up commenting in and out the @WebFilter annotation. That ...cks.

Solution: Dynamically register your WebFilter

But hey, the Servlet 3.0 API is here. And you are able to register your components dynamically. A good place to register filters is a ServletContextListener. And you don't even have to forgo your beloved annotations. Let's start with the basics.

public class FilterStartupListener implements ServletContextListener {

public void contextInitialized(ServletContextEvent sce) {
ServletContext ctx =

Next is to find any way to figure out, if you are running in production mode or not. You could think about using a system property or even reading the projectStage

property from your JSF implementation. Whatever you chose, the magic happens here:
if (Util.isProduction()) {
// if we are running in production mode
// register with servletContext
FilterRegistration fr = ctx.addFilter("SecurityFilter", SecurityFilter.class);
fr.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST, DispatcherType.FORWARD),
true, "/something/*");

That's it. It does all the magic for you and you no longer have to care about them. If the property of your choice changes, your filters get registered dynamically or not.

From http://blog.eisele.net/2011/06/dynamically-registering-webfilter-with.html


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}