Caused by: java.lang.ClassNotFoundException: org.grails.datastore.gorm.GormEntity$Trait$FieldHelper
... 8 more
3.2 Upgrading from Grails 3.0
Version: 3.2.3
3.2 Upgrading from Grails 3.0
Generally to upgrade an application from Grails 3.0 you can simply modify the version of Grails in gradle.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:
You are using a plugin or class that was compiled with a previous version of GORM and these will need to be recompiled to be Grails 3.1 and GORM 5 compatible.
Hibernate Plugin
For the GORM 5 release the hibernate
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 from src/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')}
Will produce a URI such as /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'
You would also need to move the filters to any other source directory (e.g. grails-app/controllers
) as grails-app/conf
is not considered a source directory anymore.
Spring Transactional Proxies
Because the grails.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 for new applications.
This means that if you have any services that use the transactional
property and not the Transactional
annotation they should be altered. For example the following service:
class FooService {
static transactional = true
}
Becomes:
import grails.transaction.Transactional
@Transactional
class FooService {
}
In addition because in previous versions of a Grails transactional
defaulted to true
any services that do not declare transactional
should be altered too.
If you wish to adopt the new behavior then transctional proxies can be disabled with the following configuration:
grails:
spring:
transactionManagement:
proxies: false
JSON Converter changes
The default JSON converter no longer includes the class
property by default. This can be re-enable with the following configuration:
grails:
converters:
domain:
include:
class: true
In addition the default JSON converter will no longer render the id
property if it is null
.
JSON Builder Groovy Alignment
The class grails.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"
}
Should instead be written as:
render(contentType:"application/json") {
title "The Stand"
}
If you are upgrading and prefer to continue to use the previous implementation then you can re-enable the deprecated JSONBuilder with the following configuration:
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 your build.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 {}
This will restore the Grails 3.0.x behavior.
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 in build.grade
:
testRuntime 'org.seleniumhq.selenium:selenium-htmlunit-driver:2.47.1'
testRuntime 'net.sourceforge.htmlunit:htmlunit:2.18'
Note that there are also some changes in behavior in HTMLUnit 2.18 that may cause issues in existing tests including:
-
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.
application.groovy
Changes (3.1.11+)
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.