Spring HandlerInterceptor vs Servlet Filters

[HandlerInterceptor][1]s in Spring can now be configured to be invoked only on certain URLs using `<mvc:interceptors>`.

Servlet Filters can achieve same functionality (logging, security etc). So which one should be used?

I think with Interceptors, one can use `ModelAndView` object to work with Models so it has more advantages. Can anyone draw out scenarios where Filters or Interceptors have advantages over the other?


[1]:

[To see links please register here]

With a Spring interceptor, you have access to the Handler which may be useful. Also, with a Spring interceptor, you have access to execute logic before the view renders and after the view is rendered.

Spring Handler interceptors allow you to hook into more parts of the request lifecycle, and get access to more information in the process. They're often more intimately coupled to the request/response cycle than filters.

Filters are more suitable when treating your request/response as a black box system. They'll work regardless of how the servlet is implemented.

If you're using Spring MVC, there's little reason to write new logic as a servlet filter. Everything filters can do, interceptors can do more easily and more elegantly.

Remember also, servlet filters have been around for much longer than interceptors.

The `org.springframework.web.servlet.HanderInterceptor` Interface [JavaDoc][1] itself has a two paragraphs that discuss this question:

> HandlerInterceptor is basically similar to a Servlet 2.3 Filter, but
> in contrast to the latter it just allows custom pre-processing with
> the option of prohibiting the execution of the handler itself, and
> custom post-processing. Filters are more powerful, for example they
> allow for exchanging the request and response objects that are handed
> down the chain. Note that a filter gets configured in web.xml, a
> HandlerInterceptor in the application context.
>
> As a basic guideline, fine-grained handler-related preprocessing tasks
> are candidates for HandlerInterceptor implementations, especially
> factored-out common handler code and authorization checks. On the
> other hand, a Filter is well-suited for request content and view
> content handling, like multipart forms and GZIP compression. This
> typically shows when one needs to map the filter to certain content
> types (e.g. images), or to all requests.


[1]:

[To see links please register here]

**`Servlet Filter:`**

A filter as the name suggests is a Java class executed by the servlet container for each incoming http request and for each http response. This way, is possible to manage HTTP incoming requests before them reach the resource, such as a JSP page, a servlet or a simple static page; in the same way is possible to manage HTTP outbound response after resource execution.

This behaviour allow to implement common functionality reused in many different contexts.

[![enter image description here][1]][1]


As shown in the figure above, the filter runs in the web container so its definition will also be contained in the web.xml file.

**The filter include three main methods:**

1. *init*: Executed to initialize filter using init-param element in
filter definition.
2. *doFilter*: Executed for all HTTP incoming request that satisfy
"url-pattern".
3. *destroy*: Release resources used by the filter.


**`Interceptor:`**

Spring Interceptors are similar to Servlet Filters but they acts in Spring Context so are many powerful to manage HTTP Request and Response but they can implement more sofisticated behaviour because can access to all Spring context.

[![enter image description here][2]][2]


[1]:

[2]:

The Spring interceptor are execute in SpringMVC context so they have be defined in rest-servlet.xml file:

**The interceptor include three main methods:**

1. *preHandle*: Executed before the execution of the target resource.
2. *afterCompletion*: Executed after the execution of the target resource
(after rendering the view).
3. *postHandle*: Intercept the execution of a handler.