Gotcha: Error handling in JSP

Struggled a lot with error handling in JSP (yeah, JSP is not my first choice).

The problem I've encountered: if an exception occurs directly in some JSP tag then:

•  the rendered HTML appear broken at some random point
•  the error message bypasses the application log and ends up in application server's log (localhost.log in case of Tomcat)

Example problem in JSP:

<%@ page pageEncoding="UTF-8" contentType="text/html; charset=utf-8" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>

<!-- some amount of markup here -->

<fmt:formatNumber value="100" type="currency" currencyCode="${myMissingAttribute}"/>

<!-- some more markup -->

What I've found while investigating:

1. JSP default buffer is 8k and auto flush is on. That means after rendering of each 8k chunk the result is sent back to browser. And if your error occurs later in the JSP, browser will end up with incomplete HTML.
2. To avoid having broken HTML, you should set up big enough buffer for each page and switch auto flush off, for example: <%@ page buffer="512kb" autoFlush="false" %>
3. And last but not least in the JSP misery list: <jsp:include> fails silently when the page path is incorrect, no errors whatsoever in ANY log !

How to easily create local SVN repository on Mac

Version control is addictive - once you get used to it, it's hard to go without, even on small temporary "pet" projects. You want to have a history of working versions to revert to if you get something totally messed up.
But what if you don't want to commit to your usual "official" repo and also don't bother to set up Assembla or something? Local repository comes to rescue!

If you are lucky to be on Mac it's a piece of cake to set up:

mkdir -p ~/repositories/svn
svnadmin create ~/repositories/svn/local

And then you can use file:///Users/yourname/repositories/svn/local as the SVN root for your projects. e.g. file:///Users/yourname/repositories/svn/local/MyProject

Win!

Attempt to prevent XSS in JSP... failed

As every web developer should know, you have to escape untrusted output to prevent Cross-site scripting vulnerabilities. Most web frameworks do it by default, but not JSP. In JSP, you have to do it manually every time, either using <c:out>...</c:out> or ${fn:escapeXml(...)}. Needless to say, it is easy to forget (especially if you are used to modern framework) and it clutters the template.

It feels logical that this problem should have been solved somehow already, given that thousands of developers have been using JSP every day, for years. But I've found only one solution that looks promising: http://pukkaone.github.com/2011/01/03/jsp-cross-site-scripting-elresolver.html.

I've given it a try and found that it basically works as expected. And the most important, you can override the escaping where needed, by using the custom tag. But there are 2 problems that prevented me from using it:

1. The effect of this resolver is global (as expected), so you must remove existing escaping from every JSP where you have it, and re-test the whole application
2. If you use <jsp:include> with parameters (and I use it a lot), you must override escaping of the parameter values, to avoid double escaping

So, while the first problem is solvable (given the time and resources), the second makes the whole solution look doubtful. Instead of being careful to use escaping everywhere, now I need to be careful to override escaping on each <jsp:include>. And again, it creates a lot of clutter.

Map of Android Market supported countries, UPDATED

Good news, the Android Market has expanded list of countries where you can buy paid apps.

Click to see large image

Green countries - users can buy and developers can publish paid apps.
Blue countries - users can buy but developers cannot publish.
Yellow countries - same as blue but for some reason Google calls them "Rest of the world" (maybe some restrictions will apply).

Sadly, no new countries added to support paid apps developers.

ForkingAspect added to Common Spring Aspects

A small but useful addition to the common-spring-aspects project: forked execution of a bean method.

Using the ForkAspect, it is possible to define bean methods to be executed in a separate thread. This is useful to avoid waiting on slow methods whose results we do not actually need to proceed (common examples - email sending, statistics event registration, etc).

NoSuchAlgorithmException: SunTlsRsaPremasterSecret after Java upgrade on Mac OS X

I've this weird problem after upgrading to new Java version on Mac. My (maven) project ran OK from command line but got the "SunTlsRsaPremasterSecret" error in Eclipse.

Caused by: java.security.NoSuchAlgorithmException: SunTlsRsaPremasterSecret KeyGenerator not available
at javax.crypto.KeyGenerator.<init>(DashoA13*..)
at javax.crypto.KeyGenerator.getInstance(DashoA13*..)
at com.sun.net.ssl.internal.ssl.JsseJce.getKeyGenerator(JsseJce.java:223)
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(RSAClientKeyExchange.java:89)

The solution was to remove Installed JREs in Eclipse configuration and add them again (using the "Search..." button).

Map of Android Market supported countries

As you might know, Android Market only allows people in certain countries to buy paid apps. Also, developers can only publish those applications if located in supported countries. The list of those countries is published here.

As I'm a visual type of person, I like to see maps. Surprisingly, there is no map of of Android Market supported countries available anywhere yet. So I've created one myself:

(click to see full size)

Developers based in "green" countries can publish paid apps. Users based in "green" or "blue" countries can buy them.

As you see, all the "Western world" is covered. What is notably not covered is Eastern Europe and Asia. And that's unfortunate, as there is a lot of good developers (and potential buyers) in those regions.