public interface HandlerInterceptor
A HandlerInterceptor gets called before the appropriate HandlerAdapter triggers the execution of the handler itself. This mechanism can be used for a large field of preprocessing aspects, e.g. for authorization checks, or common handler behavior like locale or theme changes. Its main purpose is to allow for factoring out repetitive handler code.
In an async processing scenario, the handler may be executed in a separate
thread while the main thread exits without rendering or invoking the
afterCompletion callbacks. When concurrent
handler execution completes, the request is dispatched back in order to
proceed with rendering the model and all methods of this contract are invoked
again. For further options and details see
Typically an interceptor chain is defined per HandlerMapping bean, sharing its granularity. To be able to apply a certain interceptor chain to a group of handlers, one needs to map the desired handlers via one HandlerMapping bean. The interceptors themselves are defined as beans in the application context, referenced by the mapping bean definition via its "interceptors" property (in XML: a <list> of <ref>).
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.
|Modifier and Type||Method and Description|
Callback after completion of request processing, that is, after rendering the view.
Intercept the execution of a handler.
Intercept the execution of a handler.
boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception
DispatcherServlet processes a handler in an execution chain, consisting of any number of interceptors, with the handler itself at the end. With this method, each interceptor can decide to abort the execution chain, typically sending a HTTP error or writing a custom response.
request- current HTTP request
response- current HTTP response
handler- chosen handler to execute, for type and/or instance evaluation
trueif the execution chain should proceed with the next interceptor or the handler itself. Else, DispatcherServlet assumes that this interceptor has already dealt with the response itself.
Exception- in case of errors
void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception
DispatcherServlet processes a handler in an execution chain, consisting of any number of interceptors, with the handler itself at the end. With this method, each interceptor can post-process an execution, getting applied in inverse order of the execution chain.
void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception
Note: Will only be called if this interceptor's
method has successfully completed and returned
As with the
postHandle method, the method will be invoked on each
interceptor in the chain in reverse order, so the first interceptor will be
the last to be invoked.