(Quick Reference)

3.2 Upgrading from Grails 3.1

Version: 3.2.9

3.2 Upgrading from Grails 3.1

If you are upgrading from Grails 3.1 there are a few items to take into consideration.

Use WebPromises instead of Promises in Controllers

In versions of Grails prior to 3.2, grails.async.Promises used to allow the use of render and other controller methods, however this was unsafe as the request thread may have finished prior to the task executing leading to unexpected errors.

You should now instead use grails.async.web.WebPromises within a controller.

Deprecated Classes and Methods Removed

Classes and methods deprecated in Grails 3.0.x have been removed in Grails 3.2. This includes all classes in the org.codehaus.groovy.grails package. If your application or plugin uses deprecated classes they should be updated to use non-deprecated replacements.

Slf4j Now Default

The log property injected at compile time into all classes is now an Slf4j Logger instance and not an instance of the Commons Logging Log class.

This should be a simple upgrade for most use cases, however this change does have some implications, for example it is no longer possible to pass non-string types to the log method. Example:

log.info "this works"
Double notAString = 9.2
log.info notAString

The latter call to the info method will throw an exception as it is not a String.

Instead you should use Slf4j’s formatting anchors to log. The advantage is the toString() method is not called unless the message will be logged.

log.info "{}", 9.2D
log.debug "Key: {}, Value: {}", key, value
log.error "{}", exception.message, exception

See the Slf4j FAQ for more information.

Spring 4.3

Grails 3.2 comes with Spring 4.3 which no longer supports Hibernate 3 and hence Grails 3.2 no longer supports Hibernate 3 either and you will need to upgrade to Hibernate 4 or above.

Spring Boot 1.4

Spring Boot 1.4, through its dependency management mechanism, enforces the upgrade for many depndencies. You should review your dependencies following the upgrade to ensure the new versions are compatible with your application.

Spring Boot 1.4 also deprecates many testing annotations (such as WebIntegrationTest).

See the Spring Boot 1.4 release notes for more information on the changes required at the Boot level.

Hibernate 4 Usage

Related to Spring Boot 1.4, one important change is that Hibernate 5 is now the default version, so if you have declared a dependency on the hibernate4 plugin in Grails such as:

compile "org.grails.plugins:hibernate4"

This will not be enough to ensure that Hibernate 4 is used. You must instead also directly declare the Hibernate 4 dependencies:

dependencies {
    compile "org.grails.plugins:hibernate4"
    compile "org.hibernate:hibernate-core:4.3.10.Final"
    compile "org.hibernate:hibernate-ehcache:4.3.10.Final"
}

GORM 6 Configuration Model

In preparation for Hibernate 5.2 support the previous "SessionFactoryBean" notion has been removed. Now if you wish to customize SessionFactory creation you should instead register a custom org.grails.orm.hibernate.connections.HibernateConnectionSourceFactory in Spring.

HibernateTestMixin Dependency Changes

The grails-datastore-test-support dependency has been removed and the HibernateTestMixin class integrated directly into the plugin, so if you receive a resolve error remove the following dependency from your build.gradle:

dependencies {
    testCompile "org.grails:grails-datastore-test-support"
}

application.groovy Changes

An improvement was added to make groovy configuration behave like yml configuration when it comes to the CLI. Previously, configuration values in application.groovy were not available to commands like grails create-controller. A side effect of this change causes an exception when those commands are executed if the configuration relies on classes in the runtime.

Error occurred running Grails CLI: startup failed:
script14738267015581837265078.groovy: 13: unable to resolve class com.foo.Bar

The solution is to create a separate file called runtime.groovy in grails-app/conf. That file will not be parsed by the CLI and will only be included at runtime.

Stop using the default namespace

Using the default package in places like UrlMappings.groovy, BootStrap.groovy or in a taglib can cause that code to fail or not execute at all when packaged in a JAR or WAR file. Make sure all Groovy/Java files start with the package statement and move any affected files to the respective folder. For example, change:

class UrlMappings {

    static mappings = {

    ...

to:

package myapp

class UrlMappings {

    static mappings = {

    ...

and copy the file from grails-app/controllers/UrlMappings.groovy into .grails-app/controllers/myapp/UrlMappings.groovy