Filter Interceptor Service Execution order

Since some of the most recent projects are interface remote invocation, using Access and business permissions to authenticate, the need to use SPRINGMVC interceptor, used to use Struts2 when the Interceptor, and the SPRINGMVC interceptor function has not been studied before, so this time to a little research, The conclusion is that the SPRINGMVC interceptor and the Struts2 interceptor principle are almost identical, using the reflection function to implement the dynamic proxy.

Because there are many similarities or even similarities between filters and interceptors, because they can achieve the same ability in many cases. So I looked at the filter again.

The difference between the filter and the interceptor, Baidu a bit:

The ① interceptor is based on the Java reflection mechanism, and the filter is based on a function callback.

The ② interceptor does not depend on the servlet container, and the filter relies on the servlet container.

The ③ interceptor can only function on action requests, and filters can work on almost any request.

The ④ interceptor can access the action context, the object in the value stack, and the filter is inaccessible.

⑤ in the life cycle of the action, the interceptor can be invoked multiple times, and the filter can only be invoked once when the container is initialized

Write a bit of test code, by the way to tidy up the idea, to find out the order between these people:

1. The filter is a Java EE standard, using a function callback method. is preprocessing before the request enters the container, before it has entered the servlet, and is returned to the front end at the end of the request for later processing.

@Override public
    void Dofilter (ServletRequest request, servletresponse response, Filterchain chain) throws IOException, servletexception {
        System.out.println ("before ...");
        Chain.dofilter (request, response);
        System.out.println ("After ...");
    

Chain.dofilter (request, response); This method is invoked as a watershed. In fact, the Doservice () method of invoking the servlet is done in Chain.dofilter (request, response), in this method.

2. The interceptor is wrapped in a filter.

@Override Public
  Boolean prehandle (httpservletrequest request, httpservletresponse response, Object handler) Throws Exception {
    System.out.println ("Prehandle");
    Return true;//returns True posthandle,aftercompletion the request succeeds, the execution is not performed,
  }
  @Override public
  void Posthandle ( HttpServletRequest request, HttpServletResponse response, Object handler, Modelandview Modelandview) throws Exception C6/>system.out.println ("Posthandle");
  }
  @Override public
  void Aftercompletion (HttpServletRequest request, httpservletresponse response, Object handler, Exception ex) throws Exception {
    System.out.println ("aftercompletion");
  }

A.prehandle () This method is performed in the previous step of the Chain.dofilter (request, Response) method of the filter, that is, in [System.out.println ("Before ...")] [ Chain.dofilter (Request, response)] executed between.

After the B.prehandle () method, the Modelandview content of controller can be manipulated before return Modelandview.

The C.aftercompletion () method is performed one step before the filter is returned to the front end, i.e., in [Chain.dofilter (Request, Response)][system.out.println ("After ...")] Executed between.

The 3.SpringMVC mechanism is to distribute requests to different controller by the same servlet, in fact this step is performed in the Servlet Service () method. So the filter, Interceptor, Service () method, DISPATC () method of the execution order should be like this, roughly drawing a picture: Actually very good test, write a filter, a interceptor, and then in these methods are added a breakpoint, all the way F8 down to come to the conclusion.

Summary: Interceptor work is really useful in the authentication of request authority, in the project I participate in, the third party remote call each request must participate in authentication, so it is very convenient, and he is very independent logic, so that the business logic code is very clean. And the other features of the framework, the principle is very simple, the use is very simple, roughly see the next SPRINGMVC this part of the source code, in fact, it is relatively easy to understand.

Our project only uses the Prehandle method, and without the other, the framework provides an adapter class Handlerinterceptoradapter that implements the Interceptor interface, inherits the class and rewrites the methods that need to be used, can be a few lines of code, This approach is reflected in many parts of Java.