Differences between Java filters and Springmvc interceptors learn notes

Study Excerpt address: http://blog.csdn.net/chenleixing/article/details/44573495

Today to learn and understand, filter and SPRINGMVC of the difference between the interceptor, learned a lot of things, has always thought that the interceptor is a filter to achieve, now think of is really a mistake ah, and look at the relatively superficial, not a global and meticulous understanding, due to the late night, time reason, I will take some of the points of view of netizens, we carefully look after there will certainly be a relatively new understanding (in this very grateful to those who are the selfless dedication, sharing their experiences and experience, in order to let the small white like me have the opportunity to stand on the shoulders of you giants, you can take a few detours).

The difference between filters and interceptors:

① interceptors are based on the reflection mechanism of Java, and filters are based on function callbacks.
The ② interceptor is not dependent on the servlet container, and the filter relies on the servlet container.
The ③ interceptor only works on action requests, while filters can work on almost all requests.
The ④ interceptor can access the action context, the object in the value stack, and the filter cannot be accessed.
⑤ in the life cycle of an action, the interceptor can be called multiple times, and the filter can only be called once when the container is initialized.

It is important that the ⑥ interceptor can get the individual beans in the IOC container, and that the filter is not, which is a matter of injecting a service into the interceptor to invoke the business logic.

Write a bit of test code, by the way, to figure out the sequence of these people:

1. Filter is Java EE standard, using function callback method. is pre-processing after the request enters the container, before it enters the servlet, and after the request is returned to the front end.

@Override      Public void throws IOException, servletexception {        System.out.println ("before ...");        Chain.dofilter (request, response);        System.out.println ("after ...");    

Chain.dofilter (request, response); The invocation of this method serves as a watershed. In fact, the Doservice () method of calling the servlet is in Chain.dofilter (request, response), which is done in this method.

2. The interceptor is wrapped in a filter.

@Override Public BooleanPrehandle (HttpServletRequest request, httpservletresponse response, Object handler)throwsException {System.out.println ("Prehandle"); return true; } @Override Public voidPosthandle (HttpServletRequest request, httpservletresponse response, Object handler, Modelandview Modelandview)throwsException {System.out.println ("Posthandle"); } @Override Public voidAftercompletion (HttpServletRequest request, httpservletresponse response, Object handler, Exception ex)throwsException {System.out.println ("Aftercompletion"); }

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

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

The C.aftercompletion () method is performed in the previous step of the filter return to the front end, that is, in [Chain.dofilter (Request, Response)][system.out.println ("After ...")] executed between them.

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

Summary: The interceptor work is really useful in the authentication of the request authority, in the project I am involved in, the third party's remote invocation of each request needs to participate in the authentication, so it is very convenient, and he is very independent logic, so that the business logic code is very clean. And the other functions of the framework, the principle is very simple, it is very simple to use, a general look at the next SPRINGMVC this part of the source code, in fact, it is relatively easy to understand.

We only used the Prehandle method in our project, but not the other, the framework provides an adapter class Handlerinterceptoradapter that has implemented the Interceptor interface, inherits the class and then rewrites the method that needs to be used, can be a few lines of code, This approach is manifested in many places in Java.

You can also refer to this ebook:

Differences between Java filters and Springmvc interceptors learn notes