Splitting Spring configuration in Grails applications

My colleague Andre wrote an interesting post about this topic already and I have to do a follow up. In one of our projects we followed the assumptions Andre made and we found out that there are some things you might be careful not to stumble over them.

First when experimenting with Spring bean configurations in your Grails application it is useful to change the log level for org.codehaus.groovy.grails.commons to at least warning level. It is configured for error per default which does not show if something is wrong in your XML configuration files.

No on to the problem and my findings. If you try to import Spring XML bean configuration files via your resources.groovy file it would like the following:

beans = { 
  importBeans('file:grails-app/conf/spring/context.xml') 
}

The problem is that this seems to work, but only if you run the application via grails run-app with the embedded servlet container.

As soon as you create a WAR file and deploy it into a tomcat you are getting into trouble. The Spring XML bean configuration files are moved into the folder WEB-INF/spring inside the WAR file. This means the XML files are not reachable via the configured path anymore. The spring folder is not in the classpath so using the classpath: prefix will not work either.

Of course you could make some weird configuration hacks that use a different path in the production environment but the best way in my opinion is to not import Spring XML configurations from the groovy DSL files and vice versa. Just add an additional resources.xml for Spring XML configuration and import other XML files from there with a relative path. You can have both a resources.groovy and a resources.xml side by side.

Default naming strategies with Grails an plain Hibernate

Last year (damn so long ago? seems like last week) I wrote a post about naming strategies and reusing an existing Hibernate domain model in a Grails app. I stumbled across this because I created a Grails application that is used as a “back office” management application for our time tracking product timr.com the uses the existing Hibernate domain model classes from the Spring application. There has also been a blog post on the official Springsource blog about this where I made a comment.

Lately I tried to upgrade the Grails application from 1.3.4 to a never version. I tried version 1.3.5 last year and version 1.3.6 later. Both made problem with the naming strategy reoccur. I had no time to look into the details but today I gave it another try with the newest Grails release 1.3.7. It again modified my existing database and created tables and columns with a different naming strategy (having dbCreate set to update).

I found out that this issue and the patch for it caused the change in the behavior between 1.3.4 and 1.3.5. As you can see from the patch the GrailsAnnotationConfiguration.java (which has to be configured in Grails to use existing Hibernate domain classes) looks for a naming_strategy config setting. The Grails documentation says you have to configure hibernate.naming_strategy for GORM which means you have to define two values if you want to have the same naming strategy for GORM and the existing domain classes.

If the values are not used Grails uses the ImprovedNamingStrategy for both GORM and the Hibernate domain classes. By debugging into the Hibernate configuration of my project I found out that using Hibernate Annotations automatically configures the EJB3NamingStrategy. So I had to configure this strategy both for hibernate.naming_strategy and naming_strategy. To make it clearer I also configured it explicitly in my Spring project:


		...