Groovy on Grails: July 2009 Archives

Since Grails v1.1.1 has come out, there has been a strange issue. It seems to sneak up on me every time something important happens, like a production release. Grails throws an exception and I see an error page on my web browser. The exception always looks something like this:

2009-07-16 21:10:16,923 ERROR   org.codehaus.groovy.grails.web.errors.GrailsExceptionResolver:60        groovy.lang.MissingPropertyException: No such property: save for class: foo.Bar
org.codehaus.groovy.runtime.InvokerInvocationException: groovy.lang.MissingPropertyException: No such property: save for class: foo.Bar
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:92)
       ...
Caused by: groovy.lang.MissingPropertyException: No such property: save for class: foo.Bar
        at foo.BarController$_closure8.doCall(BarController.groovy:105)
        at foo.BarController$_closure8.doCall(BarController.groovy)

Research has revealed that other people face this issue as well. Some solutions that people have proposed:

• Wait a few minutes and try again
• Restart your application server (this seems to work well for me)
• run MyDomainClass.count in your Bootstrap.groovy
• run MyDomainClass.get(-1) before you attempt save

These all seem like black magic to me, though. I wanted to actually understand what was going on. I found the related JIRA (GRAILS-4580) and even the commit that Graeme made to fix it (which will be available in grails 1.2).

After everything I’ve read it seems like it’s another problem with Hibernate proxy objects not getting initialized correctly. This, however, does not explain why it’s been fixed with an application server restart for me each time, or if there’s anything I can do to avoid it while I’m still using Grails v1.1.1.

My plan going forward: Do not change my approach. When I see this issue in the future I’ll continue to attempt black magic. If I have a show stopper issue, I’ll apply the fix to grails v1.1.1.

Configuration can be a bit hairy to test in grails unit tests. While there is an official technique that I found in a JIRA that looks like this:

mockConfig '''
john.doe.name = "bill"
'''

I’ve never gotten it to work. I’ve fallen back to using the Groovy provided meta-programming techniques. This means you need to mock the configuration differently depending on how you access your configuration.

No matter what, start by creating a ConfigObject()

def mockedConfig = new ConfigObject()
mockedConfig.john.doe.name = "bill"

The next step depends on how you’re accessing config in the code you’re testing. If you’re using ConfiguratoinHolder, try this

ConfigurationHolder.config = mockedConfig

On the other hand, if you’re using grailsApplication, this will work better.

GrailsApplication.metaClass.getConfig = {-> mockedConfig }

This is yet another reason to be consistent in your coding. If you’re not consistent you may end up mocking both.

Maybe you’re experiencing trouble with your IDE debugger, or you’re just a hard core VI kind of guy. Either way sometimes you need something a little more than println. Lucky for you Groovy has a pretty powerful yet undocumented debugging tool built right in called the Object Browser. It’s far from a full blown debugger, but it’s a great object inspector.

To use this inspector just add this anywhere in your Groovy program where someObject is the object that you’d like to inspect:

groovy.inspect.swingui.ObjectBrowser.inspect(someObject)

You’ve probably already noticed the swingui part of it. This brings up a handy dandy window for interactive inspection. It looks something like this:

But wait, there’s more. If you’re working with closures, as is the case almost everywhere in Groovy on Grails, try inspecting the object owner. This will inspect the container for the closure you’re currently running, which provides a ton vital information.