Last updated by 3 years ago

Page: 1.3.5 Release Notes, Version:22

Grails 1.3.5 Release Notes

Grails 1.3.5 has not been released yet. This page is a placeholder.

Grails is a dynamic web application framework built on Java and Groovy, leveraging best of breed APIs from the Java EE sphere including Spring, Hibernate and SiteMesh. Grails brings to Java and Groovy developers the joys of convention-based rapid development while allowing them to leverage their existing knowledge and capitalize on the proven and performant APIs Java developers have been using for years.

New Features & Improvements

Now using Groovy 1.7.5

Release notes for Groovy 1.7.5 can be found here.

New Feature: Named Queries Now Support Sorting

The list method attached to named queries now support the same parameters as the static list method that is added to domain classes including "sort", "ordering", "ignoreCase" etc...

Person.recentPublications.list(sort: 'title', order: 'desc', ignoreCase: true)

New feature: view information about templates used to render a single url

Related issue: GRAILS-5163

GSP templates are re-used in large web applications by using the g:render taglib. A lot of small templates can be used to render a single page. It might be hard to find out what gsp template actually renders the html seen in the result. The debug templates -feature adds html comments to the output. The comments contain debug information about gsp templates used to render the page.

Usage is simple: append "?debugTemplates" or "&debugTemplates" to the url and view the source of the result in your browser. "debugTemplates" is restricted to the development mode.

Here is an example of comments added by debugTemplates :

<!-- GSP #2 START template: /home/user/sampleapp/grails-app/views/_carousel.gsp precompiled: false lastmodified: 22.6.2010 10:45 -->
.
.
.
<!-- GSP #2 END template: /home/user/sampleapp/grails-app/views/_carousel.gsp rendering time: 115 ms -->

Each comment block has a unique id so that you can find the start & end of each template call.

Improvement: GSP reloading is supported for precompiled GSPs now

Related issue: GRAILS-5787

Details are in the Grails reference documentation

i18n reloading is also enabled if GSP reloading is enabled. New message_*.properties files won't be detected. Only changes to existing properties files are reloaded (5 sec interval).

Example of enabling GSP reloading in Config.groovy.

grails.gsp.reload.enable = true

It has been tested with Tomcat, that you can directly edit the GSP files found in the "exploded war directory" found f.e. in tomcat_home/webapps/myapp-0.1/WEB-INF/grails-app/views . You can also edit the messages.properties files found in the tomcat_home/webapps/myapp-0.1/WEB-INF/grails-app/i18n directory. Make sure you backup your changes if you are using war-files for deployment. The changes will get overwritten by Tomcat when you deploy a new version of the application. You might even lose your changes after a restart if you use war-file deployment. Therefore it's recommended to use "exploded war deployment" if you plan to use this feature.

Improvement: URL link creation is cached by default

Grails will cache links created with the g:createLink tag (and other tags that create links using the Grails UrlMappingsHolder/UrlCreator interfaces) in a weighted LRU cache. The size of the cache is 160000 characters by default. The maximum cache size (number of characters in the cache) can be controlled with "grails.urlcreator.cache.maxsize" config parameter:

// set UrlCreatorCache size to 200000 characters 
grails.urlcreator.cache.maxsize = 200000

// disable UrlCreatorCache 
grails.urlcreator.cache.maxsize = 0

The LRU cache implementation is concurrentlinkedhashmap 1.0_jdk5. This is a new dependency in Grails 1.3.5. The same cache implementation is used for caching url matches (GRAILS-6622, fixes a memory leak in url matching).

Improvement: The application instance can be easily accessed inside resources.groovy

Related issue: GRAILS-6363

Previously you had to either use the ApplicationHolder (or ConfigurationHolder if you wanted the config) to get access to this. Now you can just refer to “application”.

import grails.util.*
beans = {
    if (application.config.my.company.mockService) {
        myBean(my.company.mock.MockImpl) {
            bookService = ref("bookService")
        }   
    } else {
        myBean(my.company.MyBeanImpl) {
            bookService = ref("bookService")
        }
    }
}

New Feature: Enhancements to functional testing support

The functional testing support provided to plugins has been enhanced to include testing remote instances or running tests against a WAR deployed version of the application. Not all testing plugins will be immediately compatible, but support should follow quickly.

For more information see the functional testing section in the manual

Improvement: Tomcat JVM can be configured when using run-war

By default, the Tomcat plugin uses a forked JVM with a max heap size of 512m which may not be enough for your application. You can now control the JVM options via the the following parameter in BuildConfig.groovy:

grails.tomcat.jvmArgs = ["-Xmx1024m", "-XX:MaxPermSize=256m"]

Notice about performance when grails.logging.jul.usebridge is enabled

The default Config.groovy for new Grails applications has grails.logging.jul.usebridge setting enabled (GRAILS-6778, will change in 1.3.6). The SLF4J documentation mentions the negative performance impact of the JUL to SLF4J bridge. In Grails applications it's recommended not to enable grails.logging.jul.usebridge in production environments.

This release includes previous fixes in 1.3.x release train: