filter is a reusable code snippet that can be used to convert HTTP requests, responses, and header information. Filter is not like a servlet. It cannot generate a request or response. It just modifies a request to a certain resource or modifies a response from a certain resource.
Recently, when using scripting, I used cookies to identify the computer, added filtering, and carefully studied servlets and filters. The main difference is:
The life cycle of a filter generally goes through the following three stages:
The characteristics of servlets are:
initialization
The init() method is called when the container first loads the filter. This class contains a reference to the Filter Config object in this method. Our filters don't actually need to do this, as there is no initialization information used, here is just for demonstration purposes.
filter
Most of the time of the filter is consumed here. The doFilter method is called by the container, and references to the Servlet Request, Servlet Response and Filter Chain objects in the request/response chain are passed in at the same time. The filter then has the opportunity to process the request, pass the processing task to the next resource in the chain (by calling the doFilter method on the Filter Chain object reference), and then process the response when the processing control returns to the filter.
Destruction
The container calls the destroy() method immediately before garbage collection to be able to execute any required cleanup code.
Regarding chain.doFilter(request, response) His function is to forward the request to the next object on the filter chain. The next one here refers to the next filter, if there is no filter, it is the resource you requested. Generally, filters are one chain, and there are only a few configurations in web.xml. Connected one by one
request -> filter1 -> filter2 -> filter3 -> .... -> request resource.
The filter is a chain operation, so when processing a single filter, you must finally jump to the servlet to respond to the request.
If you go through chain, the chain.doFilter(request, response) method will immediately jump to the intercepted servlet and return to the filter.chain is equivalent to a door, go out from this door and then return from this door. The method to call filter is to configure it in web.xml, and you need to configure a url-pattern that is the same as the servlet you need to intercept.
<!-- Configure a filter --> <filter> <filter-name>suibianxie</filter-name> <filter-class>com.etoak.filter.MyEncoding</filter-class> <!-- Configure a private parameter --> <init-param> <param-name>mycode</param-name> <param-value>gbk</param-value> </init-param> </filter> <!-- The order of interception is related to the order of mapping --> <filter-mapping> <filter-name>suibianxie</filter-name> <!-- Note that this must be consistent with the url-pattern of the servlet to be intercepted, which means that the filter intercepts before the servlet --> <url-pattern>/servlet/Test</url-pattern> </filter-mapping> <!-- Configure the second filter --> <filter> <filter-name>suibianxie2</filter-name> <filter-class>com.etoak.filter.Naming</filter-class> </filter><filter-mapping> <filter-name>suibianxie2</filter-name> <url-pattern>/servlet/Test</url-pattern> </filter-mapping> <servlet> <servlet-name>Test</servlet-name> <servlet-class>com.etoak.servlet.Test</servlet-class> </servlet> <servlet-mapping> <servlet-name>Test</servlet-name> <url-pattern>/servlet/Test</url-pattern> </servlet-mapping>
The above is the difference and connection between Servlets and Filters introduced to you by the editor. I hope it will be helpful to everyone!