Introduction

1. Filters help in writing logic that applies to an entire web application.

2. So all such logic is written here.
3. Filters are like java components that can
a. intercept and process requests before they are sent to servlet
b. process response after the servlet has completed and before it is sent
back to client
4. the container decides when to invoke the filter based on declaratios in DD
5. in the DD the deployer configures which filter wud be invoked for which
request url patterns.

6. Chained : filters ca be chained together to run one after another.

7. Filters are designed to be totally self contained.

8. 3 ways filters are like servlets

a. Container knows their API
i. When a class implements the Filter interface its no longer a POJO
it becomes a Filter
ii. Other members of this API allow filter access to ServletContext
and to be linked to oine another
b. Container manages their lifecycle : init(),doFilter(),destroy()
c. Theyre declared in the DD.

9. Filters Life Cycle : every filter must implement the 3 methods.

a. init() : set-up tasks.Most common is saving a reference to FilterConfig
object to be used later.
b. doFilter() :
i. called every time the container decides that filter has to be
applied to this request.
ii. This method implements ur filters function : log user
names,compress response,etc.
iii. It takes 3 arguments :
ServletRequest,ServetResponse,FilterChain
c. destroy() : when the conainer decides to remove a filter.any clean up
task is done here.

10.FilterChain knows what comes next based on elements u specify in DD

11.chain.doFilter() calls the next filter or the Servlets or JSPs service() if its the
end of chain.

Declaring and Ordering Filters

As of version 2.4 filters can be applied to

RequestDispatchers

Response Filter

1. Bu the problem is before the doFilter of the 1 st filter tries to compress the
servlet might send the output to the client.
2. So we need to control the output.

3. The solution : instead of passing the real response object pass a custom
response object whose output stream u control

4. Implement our own response

a. Create our custom implementation of HttpServetResponse
b. This implementation must also include a custom output stream as
well , since thats the goal to capture the output after the servlet
writes to it but before it is set back to client.

5. Problem : now we have to implement all the methods I the

HttpServletResponse interface

6. Solution : Wrapper classes

a. They implement all the methods for the class u r trying to wrap
delegating all calls to the underlying request or response object
b. All u need to do is extend the wrapper and override the methods u
need to do ur custom work

c. These classes r a little different the the Listener adapter classes for
GUIs , they dont just provide an interface implementation they hold a
reference to the object of the same interface type to which they
delegate method calls.
d. Wrapper classes created by sun
i. ServletRequestWrapper
ii. HttpServletRequestWrapper
iii. ServletResponseWrapper
iv. HttpServletResponseWrapper

A full example

Wrappers implement the Decorator pattern