Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "what is the difference between filter and interceptor". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

We configure both interceptors and filters in the project.

The configuration of the filter is relatively simple, you can directly implement the Filter interface, or you can intercept a specific URL through the @ WebFilter annotation. You can see that there are three methods defined in the Filter interface.

Init (): this method is called when the container starts initializing the filter, and it is called only once during the lifetime of the Filter. Note: this method must be executed successfully, or the filter will not work.

DoFilter (): this method is called for every request in the container, and FilterChain is used to call the next filter, Filter.

Destroy (): this method is called when the container destroys the filter instance, usually destroys or closes the resource in the method, and will only be called once during the entire life cycle of the filter Filter.

@ Componentpublic class MyFilter implements Filter {@ Override public void init (FilterConfig filterConfig) throws ServletException {System.out.println ("Filter Front");} @ Override public void doFilter (ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {System.out.println ("Filter processing"); filterChain.doFilter (servletRequest, servletResponse);} @ Override public void destroy () {System.out.println ("Filter Post") }}

Interceptor it is a chain call, an application can have multiple interceptors Interceptor, a request can also trigger multiple interceptors, and each interceptor call will be executed according to its declaration order.

First of all, write a simple interceptor processing class, the interception of requests is achieved through HandlerInterceptor, you can see that three methods are also defined in the HandlerInterceptor interface.

PreHandle (): this method will be called before the request is processed. Note: if the return value of this method is false, it will be regarded as the end of the current request, which will not only invalidate its own interceptor, but also cause other interceptors to no longer execute.

PostHandle (): executes only if the preHandle () method returns a value of true. It is called after the method call in the Controller and before the DispatcherServlet returns to the rendered view. What's interesting is that the postHandle () method is called in the reverse order of preHandle (). The interceptor preHandle () method that is declared first is executed first, while the postHandle () method is executed later.

AfterCompletion (): executes only if the preHandle () method returns a value of true. After the entire request is completed, DispatcherServlet renders the corresponding view and executes.

@ Componentpublic class MyInterceptor implements HandlerInterceptor {@ Override public boolean preHandle (HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {System.out.println ("Interceptor Front"); return true;} @ Override public void postHandle (HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {System.out.println ("Interceptor processing") } @ Override public void afterCompletion (HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {System.out.println ("Interceptor Post");}}

Register the custom interceptor handling class, and set the URL that needs to be intercepted or excluded through addPathPatterns, excludePathPatterns, and other properties.

@ Configurationpublic class MyMvcConfig implements WebMvcConfigurer {@ Override public void addInterceptors (InterceptorRegistry registry) {registry.addInterceptor (new MyInterceptor ()) .addPathPatterns ("/ * *"); registry.addInterceptor (new MyInterceptor1 ()) .addPathPatterns ("/ *");}}

Both filter and interceptor embody the programming idea of AOP, and both can achieve functions such as logging, login authentication and so on, but there are many differences between them, which will be explained one by one.

The underlying implementation of the filter is quite different from that of the interceptor. The filter is based on function callbacks, while the interceptor is implemented based on Java's reflection mechanism (dynamic proxy).

Here is the focus on the filter!

We implement a doFilter () method in our custom filter, which takes a FilterChain parameter, when in fact it is a callback interface. ApplicationFilterChain is its implementation class, and there is also a doFilter () method inside the implementation class that is the callback method.

Public interface FilterChain {void doFilter (ServletRequest var1, ServletResponse var2) throws IOException, ServletException;}

ApplicationFilterChain can get our custom xxxFilter class, call each custom xxxFilter filter in its internal callback method doFilter (), and execute the doFilter () method.

Public final class ApplicationFilterChain implements FilterChain {@ Override public void doFilter (ServletRequest request, ServletResponse response) {. / / omit internalDoFilter (request,response);} private void internalDoFilter (ServletRequest request, ServletResponse response) {if (pos)

< n) { //获取第pos个filter ApplicationFilterConfig filterConfig = filters[pos++]; Filter filter = filterConfig.getFilter(); ... filter.doFilter(request, response, this); } } } 而每个xxxFilter 会先执行自身的 doFilter() 过滤逻辑，最后在执行结束前会执行filterChain.doFilter(servletRequest, servletResponse)，也就是回调ApplicationFilterChain的doFilter() 方法，以此循环执行实现函数回调。 @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { filterChain.doFilter(servletRequest, servletResponse); } 我们看到过滤器 实现的是 javax.servlet.Filter 接口，而这个接口是在Servlet规范中定义的，也就是说过滤器Filter 的使用要依赖于Tomcat等容器，导致它只能在web程序中使用。 而拦截器(Interceptor) 它是一个Spring组件，并由Spring容器管理，并不依赖Tomcat等容器，是可以单独使用的。不仅能应用在web程序中，也可以用于Application、Swing等程序中。 过滤器 和 拦截器的触发时机也不同，我们看下边这张图。

The filter Filter is preprocessed after the request enters the container, but before entering the servlet, and the request ends after the servlet has finished processing.

Interceptor Interceptor preprocesses the request after entering servlet and before entering Controller. After rendering the corresponding view in Controller, the request ends.

Above we have configured both the filter and the interceptor, and then build a Controller to receive requests for testing.

@ Controller@RequestMapping () public class Test {@ RequestMapping ("/ test1") @ ResponseBody public String test1 (String a) {System.out.println ("I am controller"); return null;}}

During the startup of the project, it is found that the filter's init () method is initialized with the startup of the container.

Insert a picture description here

When the browser sends a request, F12 sees that there are two requests, one is our custom Controller request, and the other is the request to access static icon resources.

You can see that the printed log of the console is as follows:

Execution order: Filter processing-> Interceptor front-> I am controller-> Interceptor processing-> after Interceptor processing

In Filter processing, Interceptor pre-Interceptor processing, Interceptor post-Filter processing.

The filter Filter is executed twice, and the interceptor Interceptor is executed only once. This is because the filter works on almost all requests that enter the container, while the interceptor only works on requests in Controller or requests to access resources under the static directory.

In actual business scenarios, some service services will inevitably be introduced to deal with business logic when applied to filters or interceptors.

Let's inject service into both the filter and the interceptor to see the difference.

@ Componentpublic class TestServiceImpl implements TestService {@ Override public void a () {System.out.println ("I am method A");}}

Inject service into the filter, initiate a request to test it, and the log prints "I am method A" normally.

@ Autowired private TestService testService; @ Override public void doFilter (ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {System.out.println ("Filter processing"); testService.a (); filterChain.doFilter (servletRequest, servletResponse);} I am the method AInterceptor front in Filter processing I am the Interceptor post in controllerInterceptor processing

Inject service into the interceptor and initiate a request for testing, but TM reported an error. Debug followed up and found that the injected service is Null.

Insert a picture description here

This is due to a problem caused by the loading order, where the interceptor loads before springcontext, while Bean is managed by spring.

Interceptor: I'm going into the bridal chamber today.

Spring: dude, come on, I haven't had your wife yet!

The solution is also simple: we manually inject Interceptor before registering the interceptor. Note: the getMyInterceptor () instance is registered with registry.addInterceptor ().

@ Configurationpublic class MyMvcConfig implements WebMvcConfigurer {@ Bean public MyInterceptor getMyInterceptor () {System.out.println ("MyInterceptor injected"); return new MyInterceptor ();} @ Override public void addInterceptors (InterceptorRegistry registry) {registry.addInterceptor (getMyInterceptor ()) .addPathPatterns ("/ *");}}

In the actual development process, there will be multiple filters or interceptors exist at the same time, but sometimes we want a filter or interceptor to be executed first, which involves the order of their execution.

The filter controls the order of execution with the @ Order annotation, and the level of the filter is controlled by @ Order. The smaller the value, the higher the level, the first to execute.

@ Order (Ordered.HIGHEST_PRECEDENCE) @ Componentpublic class MyFilter2 implements Filter {

The default execution order of the interceptor, that is, its registration order, can also be manually set by Order. The smaller the value, the earlier the execution.

@ Override public void addInterceptors (InterceptorRegistry registry) {registry.addInterceptor (new MyInterceptor2 ()) .addPathPatterns ("/ * *"). Order (2); registry.addInterceptor (new MyInterceptor1 ()) .addPathPatterns ("/ *"). Order (1); registry.addInterceptor (new MyInterceptor ()) .addPathPatterns ("/ *") .order (3);}

When you see the output, you find that the interceptor preHandle () method that is declared first executes first, while the postHandle () method executes later.

The order in which the postHandle () method is called is the opposite of preHandle ()! If the execution sequence is strictly required in the actual development, you need to pay special attention to this.

Interceptor1 front Interceptor2 front Interceptor front I am in controllerInterceptor processing, Interceptor2 processing, Interceptor1 processing, Interceptor post Interceptor2 processing, after Interceptor1 processing.

Then why is this happening? To get the answer, we can only look at the source code. We need to know that all requests in controller are routed through the core component DispatcherServlet and execute its doDispatch () method, in which interceptor postHandle () and preHandle () methods are called.

Protected void doDispatch (HttpServletRequest request, HttpServletResponse response) throws Exception {try {. Try {/ / get the adapter HandlerAdapter ha = getHandlerAdapter (mappedHandler.getHandler ()) that can execute the current Handler; / / Process last-modified header, if supported by the handler. String method = request.getMethod (); boolean isGet = "GET" .equals (method); if (isGet | | "HEAD" .equals (method)) {long lastModified = ha.getLastModified (request, mappedHandler.getHandler ()) If (logger.isDebugEnabled ()) {logger.debug ("Last-Modified value for [" + getRequestUri (request) + "] is:" + lastModified);} if (new ServletWebRequest (request, response) .checkNotModified (lastModified) & & isGet) {return }} / / Note: execute the PreHandle () method if (! mappedHandler.applyPreHandle (processedRequest, response)) {return in Interceptor } / Note: execute Handle [including our business logic, which will be Try, catch to] mv = ha.handle (processedRequest, response, mappedHandler.getHandler ()); if (asyncManager.isConcurrentHandlingStarted ()) {return;} applyDefaultViewName (processedRequest, mv) when an exception is thrown / / Note: execute PostHandle method in Interceptor [cannot be executed when throwing an exception] mappedHandler.applyPostHandle (processedRequest, response, mv);}}. }

Looking at exactly how the two methods applyPreHandle () and applyPostHandle () are called, you can see why postHandle () and preHandle () are executed in the opposite order.

Boolean applyPreHandle (HttpServletRequest request, HttpServletResponse response) throws Exception {HandlerInterceptor [] interceptors = this.getInterceptors (); if (! ObjectUtils.isEmpty (interceptors)) {for (int I = 0; I)

< interceptors.length; this.interceptorIndex = i++) { HandlerInterceptor interceptor = interceptors[i]; if(!interceptor.preHandle(request, response, this.handler)) { this.triggerAfterCompletion(request, response, (Exception)null); return false; } } } return true; }void applyPostHandle(HttpServletRequest request, HttpServletResponse response, @Nullable ModelAndView mv) throws Exception { HandlerInterceptor[] interceptors = this.getInterceptors(); if(!ObjectUtils.isEmpty(interceptors)) { for(int i = interceptors.length - 1; i >

= 0;-- I) {HandlerInterceptor interceptor = interceptors [I]; interceptor.postHandle (request, response, this.handler, mv);}

It is found that when the interceptor array HandlerInterceptor [] is called in the two methods, the order of the loops is actually the opposite. Causing the postHandle () and preHandle () methods to be executed in the reverse order.

That's all for the content of "what's the difference between a filter and an interceptor". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.