Fred's Random Thoughts Frederic Jean's Weblog

Speaking of Filters...

It might surprise some people that Sun doesn't always use the greatest and the latest to host internal applications. A good example is my current project. It will still be hosted on the Sun Java System Web Server 6.0 when it goes live. The main reason is inertia. People tend to stay with what they know best, and it is a non-trivial exercise to migrate from one web server to the next. Of course, you are already looking into deploying application on the Sun Java System Application Server 8 and you don't have to worry about "legacy" software...

One feature of the Servlet 2.3 specifications that I really wanted to use is the Servlet Filters. I was pleasantly surprised when I did discover that the SJS Web Server 6.0 does support servlet filters. You need to move the filter and filter-mapping elements from the web.xml to the web server's web-apps.xml. The filters themselves work great, but there is a bug where enabling the filters remove the ServletException stacktraces from the errors log file.

This doesn't mean that you should abandon servlet filters. It is really easy to write a filter that wraps the whole chain in a try/catch block:

public class CatchFilter implements Filter {

...

    public void doFilter(ServletRequest request,
            ServletResponse response,
            FilterChain chain)

        throws IOException, ServletException
    {
        try {
            chain.doFilter(request, response);
        } catch (ServletException se) {
            // Do something with the exception.
            // Oh, common! You didn't really think I would give you *everything* now, don't you???
        }
    }

....
}

This worth doing in the catch block would be to generate an exception report, log it, display it to the user and send an email to the support team that something went wrong.

This technique allows me to log and display much more detailed information about what caused that server error. I also avoid getting change requests that state "I got a Server Error. Can you fix it?".

Sometimes every bit helps.

Caching, Compression & Web App Performance

As you might guess, web application performance can be a hot ticket issue with my internal users. As a result, I am always looking around for tricks to improve the performance of the application I write.

A quick and easy way is to use a GZIP Servlet Filter to compress the HTML sent back to browsers that support GZIP compressed streams (Mozilla does). The end result is a page that appears to load a lot faster in the browser. I have been surprised more than once while testing one application that was rather slow. A good thing is that the source itself is available, so it is possible to customize the filter to add niceties such as logging.

Another method is to cache some objects in memory. This TSS article describes how to use the flyweight pattern to design a basic object caching system where different users are able to share a list of objects rather than to each maintain their own.