Quick fixes - the road to pain

After adding some new dependencies to our application we discovered that the Cloud Foundry deploy would no longer work.  The error related to duplicate files being found in the jar file's manifest folder.

A pair of developers did some investigation, changed some config and "fixed" the issue - great.

Later in the day another pair decided to try actually making the application execute some of the new code's functionality in the cloud - just some relatively trivial calls to a RESTful service.  The unit tests had all worked in development and the continuous build pipeline so surely there won't be any problems?


BANG!

java.lang.NullPointerException
    at javax.ws.rs.core.MediaType.valueOf

For our application this was a runtime exception being thrown from a dependency of a dependency.

To cut a long story short, if your application needs to be deployed as one uberjar, don't blindly exclude configuration files from the resultant META-INF directory structure.  Some systems expect and require configuration to be in place.

For my team I expect this to act as some motivation to set up some automated smoke tests that will interact with the web application inside the Cloud Foundry environment.

Tomcat configuration

Sorry for the lack of content in this post, but I sometimes use this blog as a bookmark/reminder for myself.

Here are a couple of blog posts from one of the maintainers of Tomcat.

http://blog.springsource.com/2008/08/08/optimising-and-tuning-apache-tomcat/

http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

I found it reassuring to see the load testing tools that Mark uses matched up with what I had been using a few months back.