Wednesday, July 29, 2009

Cobertura ExceptionInInitializerError with Java 1.6.0_14

I ran into a problem running Cobertura via Maven with Java 1.6.0_14 and version 2.2 of the cobertura-maven-plugin.

Basically, every class, whether it be a Java or Groovy, was reported to have 0% coverage. The exception I found in the build log:
Results :

Tests run: 31, Failures: 0, Errors: 0, Skipped: 0

Exception in thread "Thread-0" java.lang.ExceptionInInitializerError
at net.sourceforge.cobertura.util.FileLocker.(
at net.sourceforge.cobertura.coveragedata.ProjectData.saveGlobalProjectData(
Caused by: java.lang.IllegalStateException: Shutdown in progress
at java.lang.Shutdown.add(
at java.lang.System$2.registerShutdownHook(
... 5 more
Anyone who runs into a similar problem can resolve it by upgrading to version 2.3 of the plugin which uses Cobertura 1.9.2. Upgrading to 1.9.2 would likely resolve the issue for non-Maven users too.

Sunday, July 26, 2009

Using Restlet to create a RFC 1123 formatted Date

I have a service that uses Restlet 1.1.1 where the client requested a header be returned in RFC 1123 format. I needed to override the default returned by the container in use for the header to match the standard format.

In order to accommodate the request, I looked into the Restlet API and found the DateUtils class.

This little example hopefully will give someone with a similar need something to go on:

import java.util.List;
import java.util.Date;
import org.restlet.util.DateUtils;

class Rfc {
public static void main(String[] args) {
List format = DateUtils.FORMAT_RFC_1123;
String formatString = format.get(0);
Date date = new Date();
String formattedDate = DateUtils.format(date, formatString);

System.out.println("Format: " + formatString);
System.out.println("Original Date: " + date);
System.out.println("Formatted Date: " + formattedDate);
The output from a run of this class:
Format: EEE, dd MMM yyyy HH:mm:ss zzz
Original Date: Sun Jul 26 11:26:45 EDT 2009
Formatted Date: Sun, 26 Jul 2009 15:26:45 GMT

Friday, July 3, 2009

Apache Commons Lang: CompareToBuilder() Example with some TDD

In a previous post, I talked about using commons-lang to implement equalsTo(), hashCode(), and toString(), using the Builders provided by the library. Now I've had some time to play with CompareToBuilder and I thought I would take a small step at presenting an example using with some TDD thrown in after reading Kent Beck's Test Driven Development. As this is my first attempt at TDD, please forgive any sins against the methodology :)

My object under test has two simple properties:

import org.apache.commons.lang.builder.EqualsBuilder;

public class Namespace {
private Integer id;
private String uri;
public boolean equals(Object object) {
return EqualsBuilder.reflectionEquals(this, object);

Before I start to implement comparesTo(), I write my first test under the assumption that two equals Namespaces should compare equally:
void testEqualsAndCompareTo() {
def namespace = new Namespace(id, uri)
def equalNamespace = new Namespace(id, uri)
assertEquals namespace, equalNamespace
assertEquals 0, namespace.compareTo(equalNamespace)

The test of course fails before it runs as there is no Namespace.compareTo() method. To get to a green bar quickly, I add the method, not providing the final implementation, to get the green bar:
public int compareTo(Object o) {
return 0;

The test passes, so it's time for another test, comparing two Namespaces with unequal id properties:
void testCompareToWithGreaterId() {
def namespace = new Namespace(id, uri)
def greaterNamespace = new Namespace(id + 1, uri)
assertEquals(-1, namespace.compareTo(greaterNamespace))

It is worth noting omitting the parentheses in the assertEquals call causes a Groovy compiler error. Red bar:
junit.framework.AssertionFailedError: expected:<1> but was:<0>

Now the debate starts about how far I should go to get a green bar. I could implement the method incrementally to achieve the happy green state, or go with my first shot at the final implementation. I know I want to use CompareToBuilder so I'll start there. Hopefully, this falls somewhere in the middle:

import org.apache.commons.lang.CompareToBuilder;
public class Namespace() {
public int compareTo(Object o) {
Namespace namespace = (Namespace) o;
return new CompareToBuilder()
.append(this.getId(), namespace.getId())

Back to green. Another test for the case when the id is lesser:

void testCompareToWithLesserId() {
def namespace = new Namespace(id, uri)
def lesserNamespace = new Namespace(id - 1, uri)
assertEquals 1, namespace.compareTo(lesserNamespace)

Whew... still green... let's write a test that includes the uri property:
void testCompareToWithGreaterUri() {
def uri = "a"
def greaterUri = "z"
def namespace = new Namespace(id, uri)
def greaterNamespace = new Namespace(id, greaterUri)
assertEquals(-1, namespace.compareTo(greaterNamespace)
Sweet crimson:
Time elapsed: 0.004 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<-1> but was:<0>

Back to the method under test:
public int compareTo(Object o) {
Namespace namespace = (Namespace) o;
return new CompareToBuilder()
.append(this.getId(), namespace.getId())
.append(this.getUri(), namespace.getUri())
Green. Another test like before:
void testCompareToWithLesserUri() {
def uri = "z"
def lesserUri = "a"
def namespace = new Namespace(id, uri)
def lesserNamespace = new Namespace(id, lesserUri)
assertEquals 1, namespace.compareTo(lesserNamespace)

Red? Maybe I don't understand comparison like I probably should.
junit.framework.AssertionFailedError: expected:<1> but was:<25>
Eh, it's getting late, but I think I need to be testing that the result is simply greater than zero? I'm thinking the result was 25 as 'z' is 25 characters greater than 'a'. The Comparable API states that I should be looking for a a negative integer, zero, or a positive integer:
assertTrue namespace.compareTo(greaterNamespace) > 0
Green, but I should probably due more research...

An alternative to the compareTo() method above is to use reflection to implement the method:

public int compareTo(Object o) {
return CompareToBuilder.reflectionCompare(this, o);
Do the tests still pass? Yeah, is this a step towards the "final" implementation? Some might argue this approach is better because the first implementation requires maintenance if a property was added or removed. Others might not trust the reflective nature of the second method. Thoughts?

Thursday, July 2, 2009

GMock: Mocking Property Setting via a setProperty() Method

Below is a Java method I wanted to mock using GMock. The class under test is validating an incoming message in a Mule container. The features and properties passed into the set methods below are static in the class under test, OrderValidationRouter.
    private void setSchemaValidationFeatures(SAXReader reader) throws Exception {
reader.setFeature(VALIDATION_SCHEMA, true);
reader.setProperty(SCHEMA_SOURCE, getXsdAsStream());
My first attempt at testing the method with GMock:
class OrderValidationRouterTest {

OrderValidationRouter router

void setUp() {
router = new OrderValidationRouter()

void testSettingSchemaValidationFeatures() {
def readerMock = mock(SAXReader)
def xsdStream = new ByteArrayInputStream()


OrderValidationRouter.VALIDATION_SCHEMA, true)
readerMock.setProperty(OrderValidationRouter.SCHEMA_SOURCE, xsdStream)

play {
The test worked fine with the exception of the setProperty() expectations, producing the following test failure:
junit.framework.AssertionFailedError: Unexpected property setter call 
'"" =
Turns out I need to mock the actual setting of the property and not the method call. There are several ways to do this, but I went with the first thing that came to mind:
   def property = OrderValidationRouter.SCHEMA_LANGUAGE
def value = OrderValidationRouter.SCHEMA_LANGUAGE_VALUE

property = OrderValidationRouter.SCHEMA_SOURCE
value = xsdStream

The property variable needs to be interpolated in a GString or else the mock will be expecting for a property named property to be set.

If you have any alternatives, feel free to post them, thanks