Groovy on Grails: May 2009 Archives

This is a simple one.

Mysteriously the auto-compile for controllers (but not views) in my grails v1.1.1 application stopped working.  It worked fine for the other engineers on this project so I did the normal poking around.  Surprisingly I could not find anything on Google.

To fix this problem, try deleting your ~/.grails directory.  You'll need to download all of your plugins again, but autocompile will work once again.

Grails does not like loading the same class twice.  I've observed this several times in Grails v1.1.1 and each time there was a different fix.  The stack traces look pretty similar no matter what the root cause.

Example stack trace:

[groovyc] Compiling 33 source files to /Users/me/.grails/1.1.1/projects/trunk/classes
Error executing script TestApp: : java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "org/w3c/dom/Attr"
gant.TargetExecutionException: : java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "org/w3c/dom/Attr"
	at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:331)
	at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
	at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
	at gant.Gant.withBuildListeners(Gant.groovy:344)
	at gant.Gant.this$2$withBuildListeners(Gant.groovy)
	at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
	at gant.Gant.dispatch(Gant.groovy:334)
	at gant.Gant.this$2$dispatch(Gant.groovy)
	at gant.Gant.invokeMethod(Gant.groovy)
	at gant.Gant.processTargets(Gant.groovy:495)
	at gant.Gant.processTargets(Gant.groovy:480)
Caused by: : java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "org/w3c/dom/Attr"

Case 1: /lib/ jar file conflicts with a Grails plugin

I was using a functional test plugin which included xerces.  I already had xerces in the /lib folder of my grails project.

Solution to Case 1:

Remove the jar file from /lib as long as I was using this plugin...  I found the conflicting jar file the crude way: grep -r 'org.w3c.dom.Attr' ./ This solution is kind of messy but solved the problem until I stopped using this functional testing plugin at which time I had to add the jar back into the /lib/ folder.

Case 2: A maven assembly jar-with-dependencies contained a class that conflicted with a grails dependency

In this case I was using a library of my own creation built in maven. To keep the dependency nightmare to a minimum, I used the super-jar provided by the assembly plugin to package all of the dependent classes into my library. This works great in most cases, but as it turns out one of the included libraries, Xerces, is also used by grails internally.

I discovered the conflicting jar files the same way as last time: grep

Solution to Case 2:

I didn't find a satisfactory solution to this issue. Lacking time to investigate the inclusion / exclusion features of the maven assembly plugin, I simply used the standard maven jar and selectively copied the dependencies into the /lib folder of my grails project.

This 'solution' is fairly unsatisfying, but for now it works. Once I end up with dependency hell I'll revisit this issue and update this blog entry. In the mean time if anyone else solves this problem, please comment.

Other Solutions

Although I have not run into any of these solutions, other people have had luck with them

• Deleting ~/.ant/lib
• Removing JVM provided libraries that conflict

Grails comes with a database schema manager that is perfect for development and testing.  It's fast, transparent, and sometimes magical.  Being magic, though, it gets confused on occasion such as when you do a roll back to an older application version.  In development and testing this is easily solved by dropping the DB.  This is not sufficient for production.

It's time for me to explore production database management.  It seems that there are a few options:

• Liquibase

The most mature player.  It's been proven on many other projects that I've done.  It has two big downsides, though.  First off, it's another hand-edited XML configuration nightmare, which is precisely why I had stopped developing Java web applications for years (yes, I'm talking about you Spring).  Second, although it does have a grails plug in, the plug in does not actually do much except script some commands.  Integration is hence very loose.

• dbmigate

I read that this behaves a lot like the rails which has an OK database migration technique, although I always had challenges merging migrations from many developers and hated the 1000 migrations that built up after a few months of development.

I did not test this tool very much since at the time of this blog post, it seems to be an abandoned project.

• Autobase

This tool is still a baby, but it looks incredibly promising.  It claims to offer the features of Liquibase with the convience of the built in grails migration tool.  It's also being actively developed.

While I'd love to start contributing to Autobase, I'm afraid that I don't have time to dive into that project at the moment.  In the end I decided to start with Liquibase and keep a close eye on Autobase.  Perhaps in a couple of months I'll be able to ditch Liquibase and be free of XML files once again.

SQL logging is important not only for debugging problems but for keeping an eye on the database usage of your application.  No matter how efficient we try to be frameworks that isolate us from the database often result in problems like N+1 queries which can be catastrophic on large production data sets.

To enable SQL Logging in Grails v1.1.1, just add a single line to your data source configuration in /grails-app/conf/DataSource.groovy.

loggingSql=true

For example, if our development data source looks like this:

environments {
    development {
        dataSource {
            dbCreate = "update"
            url = "jdbc:postgresql:foobar"
        }
    }
}

This will be our version with SQL Logging enabled:

environments {
    development {
        dataSource {
            dbCreate = "update"
            url = "jdbc:postgresql:foobar"
            loggingSql=true
        }
    }
}

The time came for me to export data to Excel in my partially enterprise targeted application built on Grails v1.1.1.  My first impulse was to go for a grails plugin.  The export plugin seemed to be pretty close to what I needed.  Sadly I could not get it to work and anyway I need to export denormalized data that spans several domain objects.

Having given up on the plugin I hit google and found a really good solution that seems to offer about the best possible performance short of pregenerating the reports. 

This solution which uses Hibernate Projections seems like a good candidate for a plugin.

There are a lot of great validations built into Grails v1.1, but they are all focused on the object that is being validated. There are none that are capable of inspecting relationships. This is when we need to take advantage of the powerful custom validators that can be created with Grails. Here's an example of a simple case. I have a car class and I want to make sure that my car has at least one tire. < class="brush: groovy"> class Car { static hasMany[tires:Tire] static constraints = { tires(validator: { val, obj -> def retval = true if (!obj?.tires?.size()) { retval = 'car.validator.hasnotires.error' } return retval }) } } One tire a useful car does not make, though. We need four tires on our car. Let's tweak this to require exactly four tires. It's an easy change of just a few characters.

class Car {
  static hasMany[tires:Tire]
  static constraints = {
    tires(validator: { val, obj ->
      def retval = true
      if (!obj?.tires?.size() != 4) {
        retval = 'car.validator.haswrongtirecount.error'
      }
      return retval
    })
  }
}

It's easy to write similar validators that check for children of children, more detailed aspects of children, and so on. One more note. Although it may be obvious to some of you, it has tripped me up at least once. To save these data structures you must save them depth first. This means all children must be saved before you can save any parent object otherwise this validator will save since your children objects (your tires) will still be considered transient.

Was your grails v1.1 app just working and suddenly reports something like this whenever you fire it up? I bet your data source is set to 'create-drop' too.

2009-05-12 17:32:09,671 [main] ERROR hbm2ddl.SchemaExport  - Unsuccessful: create table foo (id int8 not null, ...
2009-05-12 17:32:09,672 [main] ERROR hbm2ddl.SchemaExport  - ERROR: relation "foo" already exists
2009-05-12 17:32:09,694 [main] ERROR hbm2ddl.SchemaExport  - Unsuccessful: create table bar (id int8 not null, ...
2009-05-12 17:32:09,694 [main] ERROR hbm2ddl.SchemaExport  - ERROR: relation "bar" already exists
2009-05-12 17:32:09,695 [main] ERROR hbm2ddl.SchemaExport  - Unsuccessful: create table myfoo (id int8 not null,...
2009-05-12 17:32:09,695 [main] ERROR hbm2ddl.SchemaExport  - ERROR: relation "myfoo" already exists
2009-05-12 17:32:09,703 [main] ERROR hbm2ddl.SchemaExport  - Unsuccessful: create table mybar (id int8 not null,...
2009-05-12 17:32:09,703 [main] ERROR hbm2ddl.SchemaExport  - ERROR: relation "mybar" already exists

Well you're in luck. I've discovered three possible causes and they're all easy to fix:

• Your database is locked by an existing grails process.  This happens to me sometimes when I close my IDE (IntelliJ) without killing the process.  Just kill the orphaned process to resolve this.
• You have some DB tool connected to your database which is preventing the drop command from being executed.  Simply close all of your database tools.
• You are attempting to do a backwards migration.  If you have moved from a new schema to an older one (revisiting an old tag, for instance) Grails may not be able to drop the DB.  Drop and recreate it by hand.

If none of these work, and you find another root cause, please drop me a comment and I'll update this list.

This issue has gotten me more than once. I've just checked a Grails project out of SVN and I fire it up. It complains that it 'Could not open ServletContext resource [/WEB-INF/applicationContext.xml]'. What the heck does that mean? I didn't do any xml hacking. Grails is supposed to take care of this, right? Well, kind of. If you followed the '[how to check grails into svn](http://www.grails.org/Checking+Projects+into+SVN)' document, you did not check in the WEB-INF folder. This is your problem. To fix this issue, just run this command and respond 'yes' to any prompts:

grails upgrade

Just to validate that you're experiencing the same issue, here's exactly what I see when I run into this problem:

$  grails run-app
Welcome to Grails 1.1 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /local/dev/grails-1.1

Base Directory: /local/grails_app/trunk
Running Grails application..
2009-04-29 13:21:03,085 [main] ERROR context.ContextLoader  - Context initialization failed
org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml]
	at grails.web.container.EmbeddableServer$start.call(Unknown Source)
	at _GrailsRun_groovy$_run_closure5_closure11.doCall(_GrailsRun_groovy:145)
	at _GrailsRun_groovy$_run_closure5_closure11.doCall(_GrailsRun_groovy)
	at _GrailsSettings_groovy$_run_closure10.doCall(_GrailsSettings_groovy:269)
	at _GrailsRun_groovy$_run_closure5.doCall(_GrailsRun_groovy:137)
	at _GrailsRun_groovy.runInline(_GrailsRun_groovy:104)
	at _GrailsRun_groovy.this$4$runInline(_GrailsRun_groovy)
	at _GrailsRun_groovy$_run_closure1.doCall(_GrailsRun_groovy:58)
	at RunApp$_run_closure1.doCall(RunApp.groovy:33)
	at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324)
	at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
	at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
	at gant.Gant.withBuildListeners(Gant.groovy:344)
	at gant.Gant.this$2$withBuildListeners(Gant.groovy)
	at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
	at gant.Gant.dispatch(Gant.groovy:334)
	at gant.Gant.this$2$dispatch(Gant.groovy)
	at gant.Gant.invokeMethod(Gant.groovy)
	at gant.Gant.processTargets(Gant.groovy:495)
	at gant.Gant.processTargets(Gant.groovy:480)
Caused by: java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml]
	... 20 more
2009-04-29 13:21:03,086 [main] ERROR mortbay.log  - Failed startup of context org.mortbay.jetty.webapp.WebAppContext@61c8cd04{/grails_app,/local/svncopy/grails_app/trunk/web-app}
org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml]
	at grails.web.container.EmbeddableServer$start.call(Unknown Source)
	at _GrailsRun_groovy$_run_closure5_closure11.doCall(_GrailsRun_groovy:145)
	at _GrailsRun_groovy$_run_closure5_closure11.doCall(_GrailsRun_groovy)
	at _GrailsSettings_groovy$_run_closure10.doCall(_GrailsSettings_groovy:269)
	at _GrailsRun_groovy$_run_closure5.doCall(_GrailsRun_groovy:137)
	at _GrailsRun_groovy.runInline(_GrailsRun_groovy:104)
	at _GrailsRun_groovy.this$4$runInline(_GrailsRun_groovy)
	at _GrailsRun_groovy$_run_closure1.doCall(_GrailsRun_groovy:58)
	at RunApp$_run_closure1.doCall(RunApp.groovy:33)
	at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324)
	at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
	at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
	at gant.Gant.withBuildListeners(Gant.groovy:344)
	at gant.Gant.this$2$withBuildListeners(Gant.groovy)
	at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
	at gant.Gant.dispatch(Gant.groovy:334)
	at gant.Gant.this$2$dispatch(Gant.groovy)
	at gant.Gant.invokeMethod(Gant.groovy)
	at gant.Gant.processTargets(Gant.groovy:495)
	at gant.Gant.processTargets(Gant.groovy:480)
Caused by: java.io.FileNotFoundException: Could not open ServletContext resource [/WEB-INF/applicationContext.xml]
	... 20 more
Server running. Browse to http://localhost:8080/grails_app