Interceptor and filter of spring boot project

@H_ 403_ 2 @ I. interceptors and filters

Before we talk about spring boot, let's take a look at filters and interceptors. The two are similar in function, but there is still a big gap in specific technical implementation. Before analyzing the difference between the two, let's first understand the concept of AOP. AOP is not a specific technology, but a programming idea. In the process of object-oriented programming, we can easily solve the vertical expansion through inheritance and polymorphism. However, for horizontal functions, such as opening transactions in all service methods or uniformly recording logs, object-oriented cannot be solved. Therefore, AOP -- aspect oriented programming is actually a supplement to the idea of object-oriented programming. The filters and interceptors we are talking about today belong to the specific implementation of aspect oriented programming. The main differences between the two include the following aspects:

1. Filter depends on the servlet container and is a part of the servlet specification, while interceptor exists independently and can be used in any case.

2. The implementation of filter is completed by servlet container callback, and interceptor is usually executed by dynamic proxy.

3. The life cycle of the filter is managed by the servlet container, while the interceptor can be managed through the IOC container. Therefore, you can obtain instances of other beans through injection, so it will be more convenient to use.

@H_ 403_ 2 @ II. Filter configuration

Now we realize the function of recording request execution time through the filter, which is implemented as follows:

The logic of this code is relatively simple, that is, record the timestamp before the method is executed, then complete the request execution through the filter chain, and calculate the execution time between the returned results. This class must inherit the filter class. This is the servlet specification, which is no different from previous web projects. However, with the filter class, previous web projects can be created on the web XML, but the spring boot project does not have a web XML file, how to configure it? In spring boot, we need filterregistrationbean to complete the configuration. The implementation process is as follows:

This completes the configuration. The options to be configured mainly include instantiating the filter class, specifying the matching pattern of the URL, setting the filter name and execution order. This process is similar to that in the web Configuration in XML is no different, just in different forms. Now we can start the server to access any URL:

You can see that the above configuration has taken effect. In addition to configuring through filterregistrationbean, there is a more direct method, which can be completed directly through annotation:

Here, you can configure it directly with @ webfilter. Similarly, you can set URL matching pattern, filter name, etc. One thing to note here is that the annotation @ webfilter is servlet3 0 is not provided by spring boot. In addition to this annotation, we also need to add another annotation in the configuration class: @ servletcomponetscan, which specifies the scanned package.

Now let's visit any URL:

You can see that the two filters we configured are effective. Careful readers will find that we do not specify the order of execution for the second filter, but it is executed before the first filter. It should be explained here that the @ webfilter annotation does not specify the attribute of execution order, and its execution order depends on the name of the filter, It is arranged in reverse alphabetical order according to the filter class name (note that it is not the name of the configured filter), and the filter priority specified by @ webfilter is higher than that configured by filterregistrationbean. Interested friends can experiment by themselves.

@H_ 403_ 2 @ III. interceptor configuration

We have introduced the filter configuration method above. Next, let's see how to configure an interceptor. We use interceptors to achieve the same function above and record the execution time of the request. First, we implement the interceptor class:

Here, we need to implement the handlerinterceptor interface, which includes three methods. The prehandle is executed before the request is executed, the posthandler is executed after the request, but it will be executed only when the prehandle method returns true, and the aftercompletion is executed only after the view rendering is completed. Similarly, the prehandle needs to return true, This method is usually used to clean up resources. In addition to implementing the above interfaces, we also need to configure them:

Here we inherit webmvcconfigureradapter. Friends who have read the previous articles should have seen this class. We used this class when configuring static resource directories. Here, we rewrite the addinterceptors method to configure the interceptor. There are two main configuration items: one is to specify the interceptor and the other is to specify the intercepting URL. Now let's start the system and access any URL:

As you can see, we have achieved the same function through interceptors. However, it should also be noted here that there is a problem with this implementation. Because prehandle and posthandle are two methods, we have to set a shared variable start to store the start value, but there will be a thread safety problem. Of course, we can solve this problem through other methods, such as ThreadLocal. Interested students can realize it by themselves. However, from this point, we can actually see that although the interceptor is better than the filter in many scenarios, the filter is simpler to implement than the interceptor in this scenario.

@H_ 403_ 2 @ IV. summary

This article mainly explains the configuration of filters and interceptors based on spring boot. Both filters and interceptors belong to the specific implementation of AOP (aspect oriented programming). In addition to these two implementations, we have also seen another more flexible AOP implementation technology, aspect, through which we can complete more and more powerful functions. I will share this later.