A HandlerInterceptor gives you more fine-grained control than a filter, because you have access to the actual target "handler" - this means that whatever action you perform can vary depending on what the request is actually doing (whereas the servlet filter is generically applied to all requests - only able to take into account the parameters of each request). The handlerInterceptor also provides 3 different methods, so that you can apply behavior prior to calling a handler, after the handler has completed but prior to view rendering (where you may even bypass view rendering altogether), or after the view itself has been rendered. Also, you can set up different interceptors for different groups of handlers - the interceptors are configured on the handlerMapping, and there may be multiple handlerMappings.
Therefore, if you have a need to do something completely generic (e.g. log all requests), then a filter is sufficient - but if the behavior depends on the target handler or you want to do something between the request handling and view rendering (for ex-to redirect to some other handler object or URL), then the HandlerInterceptor provides that flexibility.
Hope this gives you a general idea. You can also read more here: http://static.springframework.org/sp...ng-interceptor !
Therefore, if you have a need to do something completely generic (e.g. log all requests), then a filter is sufficient - but if the behavior depends on the target handler or you want to do something between the request handling and view rendering (for ex-to redirect to some other handler object or URL), then the HandlerInterceptor provides that flexibility.
Hope this gives you a general idea. You can also read more here: http://static.springframework.org/sp...ng-interceptor !
No comments:
Post a Comment