Head First Servlets & JSP -13-Filters and wrappers

Tag: Service blank filter Note run End IMA work block

What is a filter?

Very similar to a servlet, a filter is a Java component that can be intercepted and processed by a filter before a request is sent to the servlet, and the response can be processed with a filter before the response is sent back to the client after the servlet has finished working.
The container determines when the filter is called based on the declaration in DD. In DD, the Deployer wants to build the mapping. Specify which filters to invoke for which request URL pattern. Therefore, it is up to the deployer (not the programmer) to determine which of the requests or responses should be handled by which filters.

What the filter is going to do

There is only one filter interface: filter, depending on how you use it, you can perform tasks such as the following:

The request filter can be completed:

• Complete Security Checks
• Reformat request header or body
• Create a request audit or log

The response filter can be completed:

• Compressed response stream
• Append or modify a response flow
• Create a completely different response

Note that there is no interface such as Requestfilter or responsefilter, there is only one filter interface.

The filter is modular and can be configured in DD

• Container knows filter API
  A class implements the filter interface, which changes from a normal Java class to a EE filter, and the filter API or other member allows the filter to access the ServletContext and can be linked to other filters.
• Lifecycle of container Management filters
  Like Servlets, filters have the init () and Destroy () methods, and the Dofilter () method.
• DECLARE in DD
  DD can declare which filters are requested to run and the order in which they are run.

Example: Creating a request tracking filter

Life cycle of filters

• Init ()
  Complete all initialization tasks before invoking the filter, as shown in the code above to save a reference to the Filterconfig object for later use by the filter.
• DoFilter ()
  The real work is done here, such as logging the user name to a file and compressing the response output.
  It consists of three parameters:
  ServletRequest (not HttpServletRequest)
  Servletresponse (not HttpServletResponse)
  Filterchain
• Destroy ()
  Cleanup done before the instance is revoked.

Note that the dofilter of the Filterchain interface differs from the Dofilter () of the filter interface.
The former is responsible for identifying the Dofilter () method of the next call (if no filter is called the servlet's Service () method).
The latter is the real method of the filter.

Filters can be viewed as "in-stack"

This stack is conceptual and may not exist.

Declaring and determining filters in DD

Configuring the filter in DD will do 3 things:

• Declaring filters
• Map filters to Web resources that you want to filter
• Organize these mappings, create a filter call sequence

Two rules:

• Filter element rules
  There must be filter-name.
  There must be filter-class.
  Init-param Optional, can be multiple

• filter-mapping element Rules
  There must be filter-name.
  Url-patter or servlet-name must have a
  The Url-pattern element defines which Web application resources use this filter
  The Servlet-name element defines which Servlet uses this filter

Filters can be applied to the request dispatcher

Version 2.4, which allows you to declare a filter map for a web resource that dispatches requests, as follows:

• Claim rules
  There must be filter-name.
  There must be one of the Url-pattern or servlet-name elements.
  There can be 0~4 of dispatcher element.
  The request value indicates that the filter is enabled for customer requests. If the dispatcher element is not specified. The default is request.
  The include value indicates that a filter is enabled for requests that are sent by an include () call.
  The forward bit indicates that a filter is enabled for requests sent by a forward () call.
  Error indicates that the filter is enabled on the resource called by the error handler.

Compressing the output with a response-side filter

The container has implemented the HttpServletResponse interface, and the DoFilter () and service () methods are the parameters of such a response. But for this compression filter to work properly, we have to build our own HttpServletResponse interface custom implementation and pass it through the Chain.dofilter () call to the servlet. And this custom implementation must also include a custom output stream, as this is our goal, and the filter can get this output after the servlet writes the output and before the output is returned to the customer.

• Disadvantage: Complex httpservletresponse interfaces need to be implemented, but usually not.
  

To achieve their own httpservletresponse too responsible, how to do? --servlet Packaging Device

Creating a specific version of a request or response is so common in creating filters that Sun creates 4 "convenience" classes to make it easier to do this, and we just need to inherit a wrapper class:

• Servletrequestwrapper
• Httpservletrequestwrapper
• Servletresponsewrapper
• Httpservletresponsewrapper

Pseudo code

• Look at the following pseudo-code that inherits the wrapper class:
  
• Add a 2nd Wrapper
  

Look at the specific implementation code

• Compression Filter Code
  
  

• Calling the compression wrapper code
  (This is one of the most complex issues in the servlet world.)
  
  

• Compression wrapper, Auxiliary class:
  

Head First Servlets & JSP -13-Filters and wrappers