Wednesday, July 28, 2010

Tomcat crashing silently

Sometimes I'm surprised to see strange Tomcat crash - no error message in log, the process just stopped running.

As usual, the root cause is between the keyboard and the chair - I have some infinite loop in the code :)

Too bad that there is no log to give a hint. So the only way to tell is to do remote debugging and find out the code line where the problem occurs.

Of course this can happen also on Jetty, or whatever other servlet container.

Wednesday, July 7, 2010

Common Spring aspects

It is amazing how many people still write some log.debug() to track execution time of their methods or create a caching proxy class for each class they want to cache.

Come on, this is done million times before, why not reuse ?

Today I've written some documentation on the Common Spring aspects project. This project collects some handy aspects that I find myself using on almost every project - currently, performance logging (using JaMon library) and caching bean method invocations results (using Ehcache). The code itself is fairly small, mostly it just delegates execution to the respective library.

Thursday, May 20, 2010

Java for Mac OS X 10.5 Update 7 causes problem with Eclipse SVN

Yesterday I updated my Mac Java version to Update 7 - it's always better to use new things, isn't it ? :) Alas, after the upgrade my Eclipse Subversion plugin stopped working - every attempt of interaction with SVN (browsing, commit etc) caused freezing.

After long and painful investigation I've narrowed the problem: it occurs when using SVNKit with some (not all) SVN servers that use HTTPS client certificate authentication. It turned out that Java Update 7 fixes a security vulnerability by disabling SSL renegotiation. As the server tries to renegotiate SSL session and client (using JSSE) refuses, the whole process enters infinite loop with SVNKit log showing "javax.net.ssl.SSLHandshakeException: renegotiation is not allowed".

The workaround is to re-enable SSL renegotiation in JSEE (yes, this means exposing yourself to the vulnerability again). To do this, set the JVM option allowUnsafeRenegotiation:

-Dsun.security.ssl.allowUnsafeRenegotiation=true
In case of Eclipse, it can be set in eclipse.ini.

Wednesday, March 31, 2010

Loading Java properties in UTF-8

One of the latest stupid problems I've encountered: Java *.properties files are always loaded in ISO-8859-1 encoding and there is no way to change that. But in our project we wanted to have them in UTF-8 so that non-Latin files could be human readable. We use JSTL "fmt" tag library which loads messages from *.properties files (and guess in which encoding).

The simple solution I've come up is build-time native2ascii conversion. This can be done using the native2ascii-maven-plugin. This example shows what to add to pom.xml (assuming that your *.properties files are in src/main/resources/l10n):

<build>
 ...
 <resources>
     <resource>
         <directory>src/main/resources</directory>
         <excludes>
             <!-- exclude resources handled by native2ascii-maven-plugin (otherwise they will be overwritten again) -->
             <exclude>l10n/*</exclude>
         </excludes>
     </resource>
 </resources>

<plugins>
 <plugin>
     <groupId>org.codehaus.mojo</groupId>
     <artifactId>native2ascii-maven-plugin</artifactId>
     <executions>
         <execution>
             <goals>
                 <goal>native2ascii</goal>
             </goals>
             <configuration>
                 <src>src/main/resources</src>
                 <includes>l10n/*</includes>
                 <encoding>UTF8</encoding>
             </configuration>
         </execution>
     </executions>
 </plugin>

Wednesday, March 17, 2010

Servlet + SSI + Apache HTTPD

I was confronted with a requirement to add some SSI (Server Side Includes) processing to my Java web app. The application would get some external text containing SSI tags, prepend it with text containing SSI #set tags which will set some needed variables and all this would be processed by SSI to get the final HTML. Sounds easy enough.

What I've found is that SSI is not actually a standard - it is more like an Apache HTTPD proprietary feature. Some other webservers claim to support it (most notably Tomcat), but certainly not 100%. For example, Tomcat does not understand regular expressions in #if tags and this makes Tomcat SSI totally unusable for my purpose.

So, the only working solution right now is to have Apache in front of Tomcat (or other servlet container) with help of mod_jk or mod_proxy.

After couple of hours try-and-fails, I have found how to configure it in httpd.conf:

<Proxy *>
  Options IncludesNoExec
  SetOutputFilter INCLUDES
  Order deny,allow
  Allow from all
</Proxy>

The critical part here is the first two lines inside