Yeah, sorry, there isn't an exclude pattern in the servlet spec. Well I'm stupid and stubborn (the worst combination I guess), so of course I had to figure out some way to overcome this limitation. Even though you can basically do everything with include patterns and by examining the url in the filter code itself, the thing is that exclude url pattern would be very useful in various situations. Consider url authorization implemented with a filter for example. You might only have one or a few URLs, like the login page, that you want to be accessible to everyone, and for security reasons, you want say "check authorization to all URLs except for this one". If you just used include, there's a always a chance that you forget to add that new directory you just created into your filter mapping. If you included everything and then bypassed the one URL in you filter code, you'd essentially have to hard-code the URL in. However, you could take the bypass idea a bit further and implement a simple exclude filter that would bypass all the subsequent filters in your filter chain by forwarding the request. Your whole doFilter() method in your BypassFilter could be just two lines of code (or even one):
HttpServletRequest httpRequest = (HttpServletRequest)request;
// consider if you'd like to add request parameters into the
// forwarded request (+ httpRequest.getQueryString() )
request.getRequestDispatcher( httpRequest.getRequestURI().substring(httpRequest.getContextPath().length()) ).forward(request, response);
Bypassing the filter chain also works well for loading static resources, such as images etc. for which you likely won't want to do any extra processing in filters.
While Java's inner classes are often mentioned with unit testing as a trick to call protected methods and as a way to test asynchronous (threaded) code, it's surprising that writing unit test classes as inner classes aren't one of those idiomatic, the-thing-to-learn-after-HelloWorld standard coding patterns in Java. Say, you are being a good programmer and you always write a unit test class for every class you write. More than once, I've encounter Java programmers mulling over the problem whether they should put their test classes inside the same package to access protected methods or in a different package to better separate them out from the business code. Instead, if you implement them all as inner classes, you get several benefits for free:
- Your unit test class is always kept with the main class if you decide to refactor it into a different package.
- You can name all your test classes the same way, for example as Tester (so you get a bunch of classes called
- Inner classes can access all of the fields and methods of the parent class, including private ones, so you don't need to compromise your code encapsulation and information hiding design to instantiate and populate the class you are testing.
- Since inner classes have the same scope as their parents, there's no need to rewrite import clauses.
Any good arguments why NOT to write unit tests as inner classes?
Oh yes! Java 1.5 has hit RC. Every Java programmer who has a little bit of self-dignity should download it immediately.