Software development is often seen as a "man vs machine" endeavour. In reality, it's still people who do the work, a work that often has a clear artistic component. It is work we do with others, for others. And here are some of my thoughts on that

Monday, August 1, 2011

I was trying to debug a particularly strange oddity, and as far as I could tell, Grails was reusing a dirty command object. That's not possible, right? Further investigation showed that no, it's not using a dirty command object, well, not really. Its only doing what it's supposed to: dependency injection and convention over configuration.

Here is the simplest form of the problem I have been able to put together.

The controller:

def debug = { DebugCommand d ->
render new JSON(d)
}

The command objects: I have nested commands, with DebugCommand being the outer command (used by the controller) and DebugMapCommand, a map holding some values. I'm using a LazyMap since that's why I used in my real-life problem.

So, what's happening? The DebugCommand's reference to the DebugMapCommand is called debugMapCommand, and Grails thinks I want a DebugMapCommand injected, so it created a singleton, and passed it to all my DebugCommand instances. Oops.

Trying to prove this wasn't too easy. It would seem that a number of factors are necessary for this particular issue to manifest:

The field name must be the same as the class name with the first letter lowercased

The inner/sub command, DebugMapCommand, must be annotated with @Validateable

The inner/sub command must be in a package that is searched for "validateable" classes (in Config.groovy, you have to have grails.validateable.packages = ['com.example.yourpackage', ...])