3.1 Upgrading from Grails 3.0 - Reference Documentation
Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith, Lari Hotari
Version: 3.1.6
3.1 Upgrading from Grails 3.0
Generally to upgrade an application from Grails 3.0 you can simply modify the version of Grails ingradle.properties
.There are however some differences to Grails 3.0.x that are documented below.GORM 5 Upgrade
Grails 3.1 ships with GORM 5, which is a near complete rewrite of GORM ontop of Groovy traits and is not binary compatible with the previous version of GORM.If you receive an error such as:Caused by: java.lang.ClassNotFoundException: org.grails.datastore.gorm.GormEntity$Trait$FieldHelper … 8 more
Hibernate Plugin
For the GORM 5 release thehibernate
plugin has been renamed to hibernate4
(and there are hibernate3
and hibernate5
versions too). You should change your build.gradle
to reflect that:compile 'org.grails.plugins:hibernate4'
Static Resources Path
The default path for static resources resolved fromsrc/main/resources/public
has been changed to be nested under the static/*
pattern instead of directly under the root of the application. For example a link in GSP pages such as:${g.resource(dir:'files', file:'mydoc.pdf')}
/static/files/mydoc.pdf
instead of /files/mydoc.pdf
. If you wish to revert to the previous behavior you can configure this in application.yml
:grails: resources: pattern: '/**'
Filters Plugin Removed
The Filters plugin was replaced by Interceptors in Grails 3.0.x, although the plugin was still present. In Grails 3.1.x the Filters plugin has been removed. If you still wish to use the filters plugin you can add a dependency on the previous version provided by Grails 3.0.x. For example:compile 'org.grails:grails-plugin-filters:3.0.12'
Spring Transactional Proxies
Because thegrails.transactional.Transactional
transform already provides the ability to create transactional services without the need for proxies, traditional support for transactional proxies has been disabled by default.This means that if you have any services that use the transactional
property and not the Transactional
annotation they will need to be altered. For example the following service:class FooService { static transactional = true }
import grails.transaction.Transactional@Transactional
class FooService {}
transactional
defaulted to true
any services that do not declare transactional
should be altered too.If you wish to revert to the previous behavior then transctional proxies can be re-enabled with the following configuration:grails:
spring:
transactionManagement:
proxies: true
JSON Converter changes
The default JSON converter no longer includes theclass
property by default. This can be re-enable with the following configuration:grails:
converters:
domain:
include:
class: true
id
property if it is null
.JSON Builder Groovy Alignment
The classgrails.web.JSONBuilder
has been deprecated and replaced with groovy.json.StreamingJsonBuilder, the default JSON builder within Groovy. This avoids confusion with the differences between JSON builders and better aligns with Groovy's core libraries.This also means that any render
blocks that rendered JSON will need to be updated to use the groovy.json.StreamingJsonBuilder syntax. For example the following code:render(contentType:"application/json") { title = "The Stand" }
render(contentType:"application/json") { title "The Stand" }
grails:
json:
legacy:
builder: true
JSON Views Replace JSON Converters
With the addition of JSON views the previous API for using JSON converters is largely discouraged in favour of views. The converters plugin will in the future be separated into an external plugin and JSON views phased in to replace it. The JSON converter API is not deprecated, however JSON views provide a more fully featured, elegant API that is superior to writing JSON converters and/or marshallers.Spring Boot 1.3 and Spring 4.2
Grails 3.1 ships with upgraded third party libraries that may require changes. See the Spring Boot upgrade notes for information.Unlike Spring Boot 1.2, Spring Boot 1.3 no longer uses the Gradle Application Plugin so if you relied on any behavior the application plugin then the plugin will need to be re-applied to yourbuild.gradle
.Spring Boot 1.3 also uses Spring Security 4.x by default, so if you project depends on Spring Security 3.x you have to force a downgrade. For example:compile 'org.springframework.security:spring-security-core:3.2.9.RELEASE' compile 'org.springframework.security:spring-security-web:3.2.9.RELEASE'
Gradle run
task no longer available by default
Because the Gradle run
task for application startup was provided by the Gradle Application Plugin (see above), it is no longer available by default. If you use Gradle to start up your application, use the bootRun
task instead, or re-apply the Application plugin in your build.gradle
.Note: If you don't have need of the Gradle Application plugin's features, but have custom Gradle tasks or IDE configurations that depend on run
, you can supply your own run
task that depends on bootRun
in your build.gradle
:task run(dependsOn: ['bootRun'])
Resource annotation defaults to JSON instead of XML
The Resource annotation applied to domain classes defaults to XML in Grails 3.0.x, but in Grails 3.1.x and above it defaults to JSON.If you use this annotation with the expecation of produces XML responses as the default you can modify the definition as follows:import grails.rest.*@Resource(formats=['xml', 'json']) class MyDomainClass {}
Geb and HTMLUnit 2.18
If you use Geb with HTMLUnit (something that is not recommended, as a more native driver such as PhantomJS is recommended) you will need to upgrade your dependencies inbuild.grade
:testRuntime 'org.seleniumhq.selenium:selenium-htmlunit-driver:2.47.1' testRuntime 'net.sourceforge.htmlunit:htmlunit:2.18'
- Expressions that evaluate the title (Example
$('title')
) now return blank and should be replaced with justtitle
- If you return plain text in a response without surrounding HTML tags, these are no longer regarded as valid responses and should be wrapped in the required tags.