CHAPTER 10 INTRODUCTION TO FILTERING 431 Summary In this chapter, you ve been introduced to the filtering feature of Servlet 2.5 containers (such as Tomcat 5). You ve discovered the following: Filters enable web-application programmers to tap into the request-processing pipeline of the container. Filters are packaged code components in a web application, at the same level as servlets and JSP pages. Filters are deployed in the same way as servlets and JSP pages, through the deployment descriptor for the application. The filter has access to incoming requests before they reach the final resource and to the outgoing response immediately after the resource processing. Filters can also substitute their own version of the request and response (typically wrapped) for consumption of the resource. Symbiotic, well-defined interactions between the request dispatcher and filters enable you to create filters that act as in-series processors for request-switching web applications and application frameworks such as Apache s Struts and Turbine. You ve explored the life cycle of a filter, as managed by the container. You ve seen how to define filters in deployment descriptors, how to supply initialization data to a filter instance, how to specify its interaction with the request dispatcher, and how to define filter mappings. You ve noted how Servlet 2.3 is unable to filter dispatched requests and learned how Servlet 2.4 has remedied the situation. Next, we discussed the very important concept of filter chaining. You learned that Servlet 2.5 filter chaining uses a nested call mechanism, unlike most other filtering schemes. One major advantage of this approach is the preservation of thread state throughout the filter invocation. Working with code, you ve created two simple filters and practiced deploying them. You ve experimented with filter chaining and observed its effect by using log files. You ve also created a useful audit filter and learned how easily it can be constructed. Finally, we provided some guidelines for you to follow when programming filters and contrasted two other filterlike mechanisms (valves and interceptors) noting the differences in approach and level of abstraction to that of filters. This chapter has hopefully provided a sound foundation for proceeding to the next chapter, which will be code-intensive as you explore a variety of filter designs. Along the way, you ll create wrapped requests and responses to offer customized dynamic behavior throughout the request-processing pipeline.
Searching for affordable and proven webhost to host and run your servlet applications? Go to Linux Web Hosting services and you will find it.

430 CHAPTER 10 INTRODUCTION TO FILTERING You should note that, in general, filters should not maintain state across multiple requests because the very same instance of a filter can service a large number of requests in a given period. Logic requiring this degree of state maintenance is best served by servlets or JSP pages. In other words, the filter should depend on little or no session information to process a request or response. Think of Filters As In-Series Resource Processors When designing web applications that follow the well-documented Model-View-Controller (MVC) design pattern or Model 2 JSP architecture, consider the use of filters as in-series resource processors in conjunction with the request dispatcher. For example, in a push-model web application, a filter may perform part of the controller s responsibility by fetching data from the model and attaching it to the request in the form of attributes for the view component to display. Another interesting example is form processing. When a form is submitted and before the controller component is called, a filter can be used to perform data validation on the incoming form data. Reusing a Filter via Chaining Break up your filter-processing work into reusable, independent, chainable filters whenever possible. This will enhance the reuse potential of the filters and also allow users to use your filters in new and innovative ways. Also design your filters to be easily configurable at deployment time. Often a filter can be reused through the careful planning and use of initialization parameters. Avoid Duplicating System Features Many problems addressed by filters can be solved instead via configuration of standard server features. This is especially true with Tomcat 5, which has logging, authentication, authorization, and fine-grained access control support built-in. Encrypted sessions via Transport Layer Security (TLS), more commonly known as secure sockets (HTTPS), are also supported natively. You should avoid duplicating system features in your filter design. Investigate all the server features first, looking to see whether your filter application can be accomplished by simple server configuration. Write your filter only after you have determined that it s the only appropriate solution, given project requirements and constraints. Avoid Unnecessary Filter Mappings When mapping filters, always use the most restrictive mapping possible use instead of if possible. The overhead of filter operations can be significantly increased if the filter is consistently applied to web resources that don t need it.
We recommend you use shared web hosting services, because many users agree that it is cheap, reliable and customer-satisfying webhost.

CHAPTER 10 INTRODUCTION TO FILTERING 429 while others may save you significant debugging time during the development cycle. This section presents an encapsulation of six such guidelines. You ll see several more in the next chapter when you explore the design and coding of more complex filters. Make Code Thread-Safe Making code thread-safe cannot be stressed enough. Remember that there is typically only one instance of a filter per Java VM (unless the same filter is declared multiple times with different names or initial parameters). This makes it inevitable that the doFilter() method will be entered by many threads simultaneously, so your filter code must be thread-safe. This means the following: Local variables in doFilter() may be used freely (except for complex objects that may hold references to instance variables, in which case the next bullet applies). Instance variables in the filter class scope should be read-only, or the scope s access must be synchronized. Beware of calling methods that may modify instance variables indirectly or outside of synchronization. Figure 10-12 provides a spatial representation of this approach. Figure 10-12. One of the first steps to writing thread-safe filters is to make instance variables read-only, or access protected. Local variables are generally thread-safe and can be used to store request-specific information. Handle State Carefully State information can be readily maintained via local variables in doFilter(). The prerequest and postresponse processing window within the doFilter() method has full access to this state information. To pass state information between filters on the same chain, you can associate attributes with the ServletContext, returned by the FilterConfig.getServletContext() method. The reason why ServletContext attributes rather than request attributes can be used will be clear when you examine request and response wrapping in the next chapter.
Looking for affordable and reliable webhost to host and run your business application? Then look no more and go to servlet web hosting services.

428 CHAPTER 10 INTRODUCTION TO FILTERING You can glean some interesting data from this. The initial compiling and loading of the JSP page took 1578 milliseconds to complete, whereas subsequent access required negligible time. Also, you can see that the requests for FindProd.jsp were processed by only the audit filter. In contrast, the last request for http://localhost:8080/filters1/was processed by all three filters. Notice that because the audit filter did not log anything during the request portion of the processing, its only entry to the log appears after the return from SimpleFilter2 and SimpleFilter1. Writing this potentially useful auditing filter has been quite painless. You ll find in general that, after you re familiar with the model of operation of the Servlet 2.5 filter, writing highly functional filters can be quite straightforward. Other Filter-Like Technologies Prior to Servlet 2.4 filters, there had been many server extension mechanisms based on similar concepts to filtering. In fact, interceptors form a key server-extension mechanism that is used quite heavily in many Tomcat 3.x-based containers. Tomcat 4.x uses a technology called valves to perform filter-like processing. However, there are fundamental differences between filters and these mechanisms: they aren t the same. This section briefly describes the essential differences between the technologies. Filters Aren t Tomcat 3.x Interceptors Interceptors are a server-level extension mechanism for servers that support them. Interceptors are not an application-level technology. Being a server-extension technology, it s specific to Tomcat. Furthermore, effects of interceptors are typically global to the server filter effects are local to the web application that the filters belong to. The general architectures of interceptors and filters are completely different. Interceptors are hooked in modules that are called at specified points in the processing pipeline by the container. There are different types of interceptors for different access points. Filters, however, rely on nested chain calling (and custom wrapping of the request or response) to get their work done. There is only one type of filter. All filters implement the same javax.servlet.Filter interface. Filters Aren t Valves Valves are a system-level mechanism used extensively within the design of Tomcat 4.x and 5.x. On an architectural level, they re almost identical to filters. But that s where the similarity ends. Valves are Tomcat-specific and typically aren t portable to other Servlet 2.5 compatible servers. On the other hand, filters are portable. Valves are also internal to the Tomcat server and have privileged access to many structures and resources that application-level filters cannot access. Filter Design Best Practices There are a few rules of thumb that you should consider when designing and writing filters. Some of these may give you novel ideas on how you can use filters in your own applications,
We recommend cheap and reliable webhost to host and run your web applications: Coldfusion Web Hosting services.

CHAPTER 10 INTRODUCTION TO FILTERING 427 Simple Filter 2 /index.jsp This new mapping tells the container to apply the audit filter to all resources, and the simple filters only to requests for index.jsp. To make things more interesting, we ll use a different JSP resource to do this test. The FindProd.jsp Listing 10-7 shows the JSP page that will be accessed to test the audit filter. Again, this JSP page is very straightforward. It uses an expression language statement to display the DEPT request parameter value on screen. Listing 10-7. FindProd.jsp

You have submitted as ${param.DEPT} department!

Deploy the FindProd JSP, AuditFilter, and web.xml. Now we re ready to test. Follow these steps: 1. Clear out the Tomcat logs directory. 2. Start Tomcat. 3. Navigate to http://localhost:8080/filters1/FindProd.jsp?DEPT=Engineering. 4. Next, go to http://localhost:8080/filters1/FindProd.jsp?DEPT=Accounting. 5. Open http://localhost:8080/filters1/. 6. Shut down Tomcat. Now, if you examine the log file, you ll see the audit trail left by AuditFilter: 2005-07-27 12:46:24 StandardContext[/filters1]User at IP 127.0.0.1 . (127.0.0.1) accessed resource /filters1/FindProd.jsp and used 1578 ms 2005-07-27 12:46:30 StandardContext[/filters1]User at IP 127.0.0.1 . (127.0.0.1) accessed resource /filters1/FindProd.jsp and used 15 ms 2005-07-27 12:46:36 StandardContext[/filters1]in SimpleFilter 2005-07-27 12:46:36 StandardContext[/filters1]in SimpleFilter2 2005-07-27 12:46:37 StandardContext[/filters1]leaving SimpleFilter2 2005-07-27 12:46:37 StandardContext[/filters1]Getting out of SimpleFilter 2005-07-27 12:46:37 StandardContext[/filters1]User at IP 127.0.0.1 . (127.0.0.1) accessed resource /filters1/ and used 563 ms
Looking for affordable and reliable webhost to host and run your business application? Then look no more and go to servlet web hosting services.

426 CHAPTER 10 INTRODUCTION TO FILTERING chaining order is the order of declaration within the web.xml file, as expected. Creating an AuditFilter Both SimpleFilter and SimpleFilter2just write to the log, so now let s create the first filter that delivers a little extra. It will audit resource access by logging the time of access, the IP address of the client, the resource being accessed, and the time spent fulfilling the request. For brevity, we ll show the code for only the doFilter() method from the AuditFilter class here (see Listing 10-6); the rest of the code is no different from the previous filters. This filter takes advantage of the request object to obtain the required information. It also times the access to the resource by storing the system time before the FilterChain.doFilter() call. After the resource processing, it creates the log entry containing all the information. Listing 10-6. AuditFilter.java (doFilter() Method) public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { long startTime = System.currentTimeMillis(); String remoteAddress = request.getRemoteAddr(); String remoteHost = request.getRemoteHost(); HttpServletRequest myReq = (HttpServletRequest) request; String reqURI = myReq.getRequestURI(); chain.doFilter(request, response); filterConfig.getServletContext().log( “User at IP ” + remoteAddress + “(” + remoteHost + “) accessed resource ” + reqURI + ” and used ” + (System.currentTimeMillis() - startTime) + ” ms”); } Note the ease with which this summary information is maintained and written, using local variables in the doFilter()method itself. Thanks to the nested-call nature of filters, maintaining states across the two processing windows before and after resource access is simple. Edit the web.xml file by adding the following declarations to the file and changing the entries for SimpleFilter and SimpleFilter2from the previous example: Audit Filter com.apress.projsp.filters.AuditFilter Audit Filter /* Simple Filter /index.jsp
In case you need affordable webhost to host your website, our recommendation is ecommerce web host services.

CHAPTER 10 INTRODUCTION TO FILTERING 425 Listing 10-5. web.xml ProJSP Example Filters Simple Filter com.apress.projsp.filters.SimpleFilter Simple Filter 2 com.apress.projsp.filters.SimpleFilter2 Simple Filter /* Simple Filter 2 /* This mapping now maps both SimpleFilter and SimpleFilter2 to all resources being accessed. This effectively chains them for all resources. Deploy the new web application to Tomcat. Clear the log files, start Tomcat, access the URL http://localhost:8080/filters1/ again, and then shut down Tomcat. Now, open the log file again and you should see something similar to the following: 2005-07-27 10:21:52 StandardContext[/filters1]in SimpleFilter 2005-07-27 10:21:52 StandardContext[/filters1]in SimpleFilter2 2005-07-27 10:21:53 StandardContext[/filters1]leaving SimpleFilter2 2005-07-27 10:21:53 StandardContext[/filters1]Getting out of SimpleFilter Notice the nesting of the log entries, which clearly show that the filter-chaining mechanism consists of a series of nested doFilter() calls on the two participating filters. The
In case you need quality webspace to host and run your web applications, try our personal web hosting services.

424 CHAPTER 10 INTRODUCTION TO FILTERING Now to check that the filter has actually worked for this simple static page, let s read the application log file found lurking in the Tomcat logs directory. The log file will be named after the current date, something like localhost_log.2005-08-04.txt. Inside, you should find the two log entries written by the filter, one entry created by the log() method prior to the doFilter() method call, and one created by the log() method after the doFilter() method call. On our test system, here are the two log entries: 2005-07-27 10:09:58 StandardContext[/filters1]in SimpleFilter 2005-07-27 10:09:59 StandardContext[/filters1]Getting out of SimpleFilter Experimentation with Filter Chaining Now you ll create a second filter called SimpleFilter2 (see Listing 10-4). Like SimpleFilter, it just logs each request in the log file. Chaining these filters together will give us some insight into the action of filter chaining under Tomcat 5. Listing 10-4. SimpleFilter2.java package com.apress.projsp.filters; import java.io.IOException; import javax.servlet.*; public final class SimpleFilter2 implements Filter { private FilterConfig filterConfig = null; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { filterConfig.getServletContext().log(”in SimpleFilter2″); chain.doFilter(request, response); filterConfig.getServletContext().log(”leaving SimpleFilter2″); } public void init(FilterConfig filterConfig) { this.filterConfig = filterConfig; } public void destroy() {} } Additions to web.xml You can now add SimpleFilter2 to the chain. Listing 10-5 shows the updated web.xml, with a new entry for SimpleFilter2, and an updated sequence of elements. Ensure the ordering of entries is followed exactly.
If you are searching for cheap webhost for your web application, please visit MySQL5 Web Hosting services.

CHAPTER 10 INTRODUCTION TO FILTERING 423 ProJSP Example Filters Simple Filter com.apress.projsp.filters.SimpleFilter Simple Filter /* Note If you re working with the source-code distribution downloaded from the book s website, these filter definitions and mappings are included but commented out. You should uncomment each set as appropriate as you progress through the example. All that s left to do now is to create a resource to access. Listing 10-3 shows a simple JSP page. Because we re more interested in the filter processing than the JSP processing, this JSP page does no processing; it is just a convenient resource we can access to demonstrate filter processing. Listing 10-3. index.jsp

Welcome to Filtering Demo Application!

Testing the Filter You re now ready to test the filter. Assuming that Tomcat isn t currently running, perform the following steps: 1. Go to Tomcat s logs subdirectory and delete all files. 2. Create a web application with the filter and index.jsp and deploy it. 3. Start Tomcat 5. 4. Start a browser and navigate to http://localhost:8080/filters1/index.jsp. 5. After the web page has loaded in the browser, shut down Tomcat.
Note: If you are looking for cheap and reliable webhost to host and run your mysql application check mysql web server services.

422 CHAPTER 10 INTRODUCTION TO FILTERING Listing 10-1. SimpleFilter.java package com.apress.projsp.filters; import java.io.*; import javax.servlet.*; public final class SimpleFilter implements Filter { private FilterConfig filterConfig = null; public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { filterConfig.getServletContext().log(”in SimpleFilter”); chain.doFilter(request, response); filterConfig.getServletContext().log(”Getting out of SimpleFilter”); } public void init(FilterConfig filterConfig) { this.filterConfig = filterConfig; } public void destroy() {} } As mentioned before, all filters must implement the javax.servlet.Filter interface, and the SimpleFilter is no exception. The filter does its work in the doFilter() method. Note the parameters: a request, response, and a FilterChain object. However, before the container calls doFilter(), it will pass a FilterConfigobject to the filter through the init()method. If the filter needs to access any resources from the FilterConfig object, the class must save a reference to that object. To write to the log, you access the ServletContext from FilterConfigas provided by the container. The log() method will write a line by using the logger set up earlier for this context. The rest of the methods are standard trivial implementations required for the Filter interface. Declaring the Filter and Configuring Filter Mapping Now, you need to add a element to the web.xml file, the deployment descriptor for your web application. Listing 10-2 shows the web.xmlfile for this example. Listing 10-2. web.xml
Check Tomcat Web Hosting services for best quality webspace to host your web application.