Filters and wrappers

Filters allow you to intercept requests and also allow you to control responses. Filter is much like a servlet, and the container manages the life cycle of the filter. Like Servlets, filters also have the init () and Destroy () methods, which correspond to the doget ()/dopost () of the servlet, and the filter has a Dofilter () method. Filters also need to be declared in DD, and the order in which the filters are run is also declared in DD.

1. Life cycle in the filter

First, there is a inti (), the most common implementation is to save a filterconfig reference in Inti () in case the filter is used later (get filter parameters, etc.).

The real work is done in Dofilter (). The Dofilter method has 3 parameters:

A servletrequest (not httpservletrequest);

A servletresponse (not httpservletresponse);

A filterchain, the filter does not know the other filters involved in the request, but someone must know the order in which the filter executes, and this person is filterchain, which is driven by the filter element specified in DD. Filterchain the Dofilter () method to invoke the next filter or servlet;

Finally, destroy (), which completes the cleanup required before undoing the instance.

2. Declaring and determining the filter order

When you configure a filter in DD, you typically do 3 things:

1) Declare filter and filter parameters:

In DD, declare:

Declare by using dynamic injection:

2) Map the filter to the Web resources you want to filter;

3) Organize these mappings and create the filter invocation order;

When multiple filters are mapped to a given resource, the container uses the following rules:

• Find all filters that match the URL pattern first and make a chain in the order declared in DD.
• Then find the filter that matches the <servlet-name> and put it in the chain.

4) The filter can be applied directly to the client's request, but the filter cannot function if the request comes from forwarding, inclusion, and error handling. Servlet 2.4 provides a <dispatcher> element to solve this problem.

3. Packaging device

The wrapper functionality in the Servlet API is powerful, and they implement all the required methods for what you want to wrap and delegate all calls to the underlying request or to the corresponding object. All you have to do is extend a wrapper, and if you want to do some special customization work in which methods, you can just overwrite these methods. Wrapper classes are a typical example of using decorative patterns.

Create a specific version of a request or response, which is too common when creating filters. So Sun has created 4 "convenience classes" that are easier to accomplish with this task:

• Servletrequestwrapper
• Httpservletrequestwrapper
• Servletresponsewrapper
• Httpservletresponsewrapper

A request wrapper is the use of the Httpservletrequestwrapper class to make uniform modifications to the contents of the request, such as modifying the request character encoding, substitution characters, permission validation, and so on.

The response wrapper refers to the use of the Httpservletresponsewrapper class to make the corresponding content in a uniform modification, such as compressed output content, replace output content and so on. Since the httpservletresponse cannot cache the output, it is too late for the filter to process the output after dofilter (), when the servlet has directly returned the output to the customer. So you need to customize a cache-capable response so that the filter can handle the output after Dofilter ().

Filters and wrappers