Grails Pitfalls and Tips

I have worked with Grails for some time now and thought I would share some of the common mistakes I have made early on. I also thought I could discuss some things that can make developing with Grails easier. Here is my short list of items:

Zero Turnaround Time

One of the convenient features of Grails is the ability to make a change and have that change be available immediately in your application. This is an obvious time saver and allows you to be more productive while developing your application. However, there are times when you will make major refactoring changes on the fly that the JVM cannot deal with. An example of this might be when you introduce something new in the middle of an existing class hierarchy. While it may appear that Grails is happy and your environment is sailing along you might see odd behaviour in the application and see some strange runtime exceptions along the way. What usually remedies this situation is instructing Grails to rebuild the internal structures in your application. This can be done by executing the following command and restarting your application:

# grails clean

Grails Console

One tool that you will want to keep in your Grails toolkit is the Grails console. This allows you to run a your application in an enviroment so you can experiment with code on the fly. One of the main reasons I do this is to try out my unit and integration code in the console before, or during, writing my tests. This is a fast way to get confidence that your test code will provide the results you want. And because you are doing this in the console you do not have to keep executing the grails test-app command to reinitialize the environment.

Since you have the full environment in the Grails console you can easily get references to your Spring beans and services. You are automatically provided a reference to the org.codehaus.groovy.grails.commons.spring.GrailsWebApplicationContext class with a variable named ctx. This allows you to do things like this in the Grails console:

  def service = ctx.bookStoreService
  def book = service.getCurrentBook()
  println "The most recent book is ${book.name} by ${book.author}"
  println book.dump()

You can see all of the defined beans that Grails is aware of like this:

ctx.beanDefinitionNames.sort().each {println it}

Manually Assigning Primary Keys

Most of the time your domain objects will have autogenerated primary key values for the id field. However, I ran into a situation where I needed to manually assign a primary keys for one of my domain objects. This took a little bit of trial and error to make this work. Here is how you do this correctly:

          
String id
static mapping = {
  id generator:'assigned', column:'RECORD_ID', type:'string'
}

Also note that you must set the id manually outside of the object constructor on a separate line like this:

def obj = new MyDomainObject(name:'whatever')
obj.id = 'REC000001'
obj.save(flush:true)

Not like this:

def obj = new MyDomainObjects(name:'whatever', id:'REC000001')
obj.save(flush:true)  

because the value will not be saved.

Manually Triggering Quartz Jobs in Grails

Grails has an excellent plugin for managing scheduled Quartz jobs. However, I had a situation where I wanted to manually schedule a job. I could not find this in the documentation so after poking around in the source I figured out how to do this using the following technique. First you have to define the job name and group like this:

class MyValidationJob {
      
  def name = 'MyJobName'
  def group = 'MyGroup'

  // your executable job method here...
}

Then you can manually trigger the job like this:

          // trigger the job manually by job name and group from your controller/service/whatever
        def quartzScheduler // inject this in your class
        quartzScheduler.triggerJob("MyJobName", "MyGroup")

Using Packages in the Grails

Grails provides a directory structure for your application components by convention similar to Rails. However, this can cause issues if you put your classes directly inside of these folders because they seen by Java in the default package. Using the default package can cause you issues when compiling your classes. Since we are using Groovy (and really Java) it is my opinion that you should add packages to your Groovy classes. I also think that modules in Ruby translate better than package structures at this point but we are stuck with Java constraints.

You can add packages to the provided services and domain folders and Grails will make Spring beans out of them. You just need to be careful not to use the same name for the bean twice. You just reference the bean by the name of the class. For example let's say you have a service called com.myco.service.validation.MyValidationService. Grails will expose this as a bean reference named myValidationService.

Base Classes with GORM

It is common practice that developers make a base domain class with common features of your subclassed domain objects. By defining an abstract class you can define common properties for your domain objects. There is a catch however. The GORM DSL allows you to define constraints and mappings blocks in these classes for validation purposes and defining ORM mappings respectively. The current problem is that if your subclasses have their own mappings and/or constraints defined they will override what is in your superclass instead of being merged with the superclass blocks. I am hoping that a future version of Grails addresses this issue (1.1 hopefully).

Unexpected NPEs

One of the earliest mistakes I made when working with Grails was generating NullPointerExceptions without much to decipher in the stack trace. The most common problem for me (which you will overcome quickly) was to make sure you validate your domain objects and handle the errors appropriately in your controllers. The errors object is automatically added to your domain objects and can be checked with the hasErrors method on those objects.

Viewing the Source of your GSP Files

This is just a quick tip that allows you to view the generated source of you GSP files. This is a simple as adding the 'showSource' parameter to your URL like this:

http://localhost/yourapp/yourController/list?sort=dateCreated&max=20&showSource