(Quick Reference) # 3.1 Upgrading from Grails 3.1 Version: 3.2.8 ## 3.1 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` | Quick Reference (hide)