Friday, May 9, 2008

Spring Configuration

A recent task was to consume a simple comma-separated file and generate database records from it.

Our application is quite middle of the road in terms of the complexity of it's configuration. One of the most complex parts is the many databases which we access from our code. In this case, I wanted to import test data so we could check out the user interface we were developing for it.

I spent about a week on the task. Four and a half days working on the wiring, trying to find a way to build a configuration which would run and be able to access the database. Just half a day was required to write and debug the actual code.

In the end I gave up on trying to test it in the 'correct' place in the code, and hacked at some code where I knew that I would be able to access the database and have a existing user interface to invoke it from, and see the results.

The code works. Our user interface looks good and displays the imported data.

This configuration overhead adds to development time and makes it harder to justify extensive testing.

We have a number of cross-cutting concerns and use Java 5 annotations extensively. Not all these concerns result in annotations at the places which 'need' them. Our transaction interceptor is an example. For most of our code it 'just works'. The rest of the time it can be hard to know where to start on a solution to the problem.

To be fair, not all of the configuration overhead relates to our Spring wiring. I did lose a couple of hours when a Maven deploy on another branch caused a puzzling regression. That is clearly Maven configuration overhead.

While I have done some work with Groovy, I have not tried Grails yet. I have used Tapestry in the past but Tapestry 5 is a lot different than the Tapestry 3 I used. I doubt that Tapestry will ease these configuration issues. Grails might based on my experience with Ruby on Rails.

No comments: