ava filters, first introduced in the Java Servlet specification 2.3, are a powerful addition to any Java Web application toolkit, yet they probably are the most under-used and under-appreciated of the servlet components. These classes intercept requests coming into and responses coming out of the Java servlet container, allowing developers to inspect and manipulate these messages, as well as take other actions based on the messages’ content. Despite this useful functionality, many Java developers are unfamiliar with filters.

What makes filters so powerful is the range of tasks they can perform. For example, you can use them to:

• block non-authenticated users or encrypt sensitive content as it travels back to the client
• compress pages returned from your Web app in order to save bandwidth
• log application access statistics
• transform all your GIF images to PNG images on the fly

Authentication, logging, compression, encryption, transformation?filters can do a lot.

This article demonstrates using filters for Web-application testing?specifically, applying a filter that validates a Web app’s HTML against the HTML DTD. The filter uses the W3C’s online Markup Validation Service to perform the actual HTML code validation. Since the W3C service can return an XML description of the validation results, you can parse those results and display a formatted list of any issues in the HTML page itself.

You may be wondering: why use a filter when static HTML and public sections of Web apps are so easy to validate? All you need to do is submit the URL to the W3C Validation Service and read the results, right? In fact, browser toolbars and various techniques make this process simple (for example, the W3C site recommends using “favelets” for this purpose). The reason is these techniques do not work for most sophisticated Web apps. Authentication and authorization layers, or using HTTP POSTs eliminate the possibility of submitting simple browser URLs.

Your Java filter gets around these restrictions by buffering the HTTP response, writing it out as a static HTML page, and submitting that static file to the W3C Validation Service. In short, your filter will turn the dynamic request into a static resource and submit that resource, which gets around any security code or other HTTP-related issues.

Validating your Web application’s HTML is an important task in its own right?and the subject of more than a few other articles out there?so I won’t belabor the point. The numerous reasons for verifying whether your application returns valid HTML include the following:

• Ensuring backwards and forward browser compatibility for your interfaces
• Helping make interface code easier to understand and maintain
• Assisting in correct search-engine parsing and indexing
• Helping make Web pages more accessible

Getting Started with the Filter API
One of the nicest things about Java filters is that the API itself is short and simple. All told, it adds only three new interfaces and eight methods to the javax.servlet package. The three interfaces are Filter, FilterConfig, and FilterChain. FilterConfig’s only job is to hold configuration information for the filter, which accesses this information by calling the getInitParameter() method.

FilterChain isn’t complex either; it represents the stack?or “chain”?of filters that this request must pass through (a request may have to pass through many filters). It contains a single method, doFilter(), which you call to allow the request to pass down the stack to the next filter. When the last filter in the chain calls doFilter(), the servlet container invokes the requested JSP/servlet, or otherwise handles the request. As a filter developer, you must call doFilter() or the request will not continue its journey.

The Filter interface is where most of the action occurs. It consists of three methods: init(), doFilter(), and destroy(). Each method’s logic is fairly transparent:

• When the servlet container calls init(), it notifies the filter that it is about to be used.
• The doFilter() method is called once for each request/response pair passed along the FilterChain.
• The destroy() method notifies the filter that it is about to be taken out of service.

Go ahead and start your class, HTMLValidatorFilterLite, by supplying empty init() and destroy() methods after your initial imports and class definition:

import java.io.*;import javax.servlet.*;import javax.servlet.http.*;import javax.xml.parsers.*;import org.w3c.dom.*;public final class HTMLValidatorFilterLite implements Filter {public void init(FilterConfig filterConfig) throws ServletException {}public void destroy() {}

All the work for your Filter takes place in the doFilter() method, which starts off with a few housekeeping tasks:

public void doFilter(ServletRequest request, ServletResponse response,		FilterChain chain) throws IOException, ServletException {		HttpServletRequest req = (HttpServletRequest) request;		HttpServletResponse res = (HttpServletResponse) response;		PrintWriter out = res.getWriter();

For simplicity, cast the ServletRequest and ServletResponse objects to their HTTP cousins to avoid repeatedly having to cast in the code that follows. You then get a reference to the PrintWriter, which is the component that sends character text back to the client. You will use this object later to write data to the client.

Next, set up buffering for the HTTP response:

ResponseBuffer buffer = new ResponseBuffer(res);

ResponseBuffer is a wrapper around the ServletResponse object. The servlet API class HttpServletResponseWrapper, which ResponseBuffer extends, enables you to wrap the response. ResponseBuffer‘s only job is to buffer the output of this request. So as your application components write to the ServletResponse object, ResponseBuffer holds that data and keeps it from being sent to the client until you’re ready.

Confused? Don’t worry: this is a standard Java filters technique that you will see frequently. Just copy it when you need to buffer a response. You’ll find the code for ResponseBuffer.java in the downloadable source code for this article.

Once you have started the buffering, send the request on to any other filters in the FilterChain, and then grab the results:

chain.doFilter(request, buffer);// lots of stuff can have happened!String contents = wrapper.toString();

With the call to doFilter(), the request is dispatched to the next filter. If no other filters are present, the request is dispatched to the requested servlet. That is, code in the filter before this call to doFilter() executes before the requested servlet executes, while code after this point executes after the requested servlet executes. It’s as if your code steps through a rift in time?whole worlds of activity could take place after this method call. In this example, once you make the call to doFilter(), your ResponseBuffer fills and you can access the HTML content of the response in the very next line.

Getting Started with the Filter API (cont’d)
With your HTML in hand, the real work begins. Examine the remaining code below and read the highlights at the end:

// determine the script pathsString filePath 		= req.getSession().getServletContext().getRealPath		(req.getServletPath())		+ ".validate.htm";String fileUrl = http:// + req.getServerName() + ":"		+ req.getServerPort()		+ req.getRequestURI()		+ ".validate.htm";// write the temporary page out to diskFileWriter fw = new FileWriter(filePath);fw.write(contents);fw.close();// validate the pageString results = this.validate(req, fileUrl, contents);// delete the page on diskFile f = new File(filePath);f.delete();// insert our validation results into the pagecontents = contents + results;// send the page to the browserCharArrayWriter caw = new CharArrayWriter();caw.write(contents);response.setContentLength(caw.toString().length());out.write(caw.toString());out.close();

The code should be easy enough to read. First, you determine where to write your file and the corresponding URL where the W3C Validation Service can access it. Then you write the file out. The following line performs the actual submission to the W3C Validation Service and formats the XML results, via the validate() method:

String results = this.validate(req, fileUrl, contents);

I’ve left out the code for the validate() method, as it has little to do with Java filters specifically. If you have worked with XML in Java?using JAXP and DOM and such?the code should be familiar territory. If not, it’s not tough to follow anyway. You can find the complete source code in the downloadable code for this article.

Since your temporary HTML page has been validated, you can now delete it:

File f = new File(filePath);f.delete();

After that, send the results back to the Web browser with these lines:

CharArrayWriter caw = new CharArrayWriter();caw.write(contents);response.setContentLength(caw.toString().length());out.write(caw.toString());

Almost There, Just Configure the Filter
You are not quite done yet. You still need to deploy the filter so your servlet container knows you want to use it. One of the nice things about filters is that you do not have to modify any existing code in order to introduce them into your Web app. All you need to do is add a element into the web.xml file:

     HTMLValidatorFilterLite   org.twine.filter.HTMLValidatorFilterLite         

Then you need to set up a mapping in your web.xml file that tells the servlet container when to use this filter. To set the filter up to validate all JSP files, you use the following code:

         HTMLValidatorFilterLite      *.jsp     

Be careful with these mappings. The W3C Validation Service will make requests to your server as well. So if you set up the filter to catch all requests (*), the W3C Validation Service’s request will trigger another invocation of the filter, followed by another request, and so on. The file written to disk has a default extension of ‘.htm’, so any you use should avoid that one.

Filters Simplify Web-app Testing
Validating HTML is an important part of any Web-app testing process. Using Java filters to implement this aspect of testing makes some complex problems easy to solve. You can also find the code in this article on SourceForge’s TWINE page. There, I include a more robust version of the HTMLValidatorFilterLite class, which includes some useful configuration options that I left out here in order to simplify the code and discussion. If you are interested in standards-based interface development and Web accessibility in general, please check it out. The project’s goal is to provide tools that make dynamic Web-application interface validation easy, and Java filters are the ideal Web technology to make that happen for servlets.