Exploring Grails 3

We’ve now reached the time of year when I need to think about initiating the Groovy & Grails eXchange call for papers, so I thought I’d take this opportunity to both resurrect the talk submissions app I created a while back and try to upgrade it to Grails 3. Up until now, I hadn’t properly used Grails 3 for anything, so it seemed like a good opportunity to learn how it differs from previous versions.

Here’s what happened next…

Rearranging the furniture

Superficially, not much has changed. You install Grails in the same way, you still have a grails command, and most of the subcommands you’re used to are still there. It’s also based on the same sets of artifacts: controllers, domain classes, views, etc.

Unusually for me, I decided to check out the user guide to find out where I should start with the migration. That turned out to be a good idea as there is a lot of useful information there. It covers most of the basic stuff about which files have moved or been removed, and some other necessary changes. As a quick taster, here are some of the documented changes:

  • Lots of things in grails-app/conf have been moved/removed. It’s no longer a source folder.
  • The web-app directory has been wiped from the face of the Earth.
  • Grails filters are gone to be replaced by something close to Spring’s handler interceptors.
  • Logging configuration is completely different and in a separate logback.groovy file.
  • BuildConfig.groovy is no more as the build stuff goes into a Gradle build file.

I managed to run through these initial steps quickly, even replacing my dynamic scaffolding with static scaffolding (dynamic is back in 3.0.4), until I reached the bit about plugins. This is where I got sad.

The plugin story

Ever since plugins were added to Grails, they’ve been distributed as source packages which are then compiled with the application. This largely worked fine and helped avoid binary incompatibility problems. An attempt was made to support binary plugins, i.e. pre-compiled ones, but I don’t think many plugin authors tried it.

That’s all changed now as Grails 3 plugins have to be pre-compiled and packaged as JARs. I guess this is partly so that they can be declared as normal Gradle dependencies rather than having to appear in a dedicated plugins {...} block. Regardless of the reason, this is probably going to be the biggest stumbling block for many people attempting a migration as there are lots of plugins that haven’t been upgraded, and some may never be. But before you’re turned off the whole idea of migrating, here are some things to consider:

  • The upgrade status of certain popular plugins is being tracked, so keep an eye on that.
  • Some plugins are trivial to upgrade, so you might consider doing it yourself.
  • Some libraries are almost as easily integrated through Spring Boot as through a plugin, so the plugin may not be worth upgrading.

Given that, why was I sad? Spring Security. This plugin has not been upgraded and I have no idea whether it’s actively being worked on. Some people have said that the Spring Boot Starter for Spring Security is enough, but I can categorically say it’s not. It’s amazing how much extra work the plugin does for you. I know, because I had to re-implement bits of it to get the GORM-based authentication working again.

At this point, I have to give a big shout out to David Spies for a timely and time-saving series of blog posts about upgrading a Spring Security Grails app to Grails 3. That got me far enough that I didn’t simply give up on the whole exercise.

I did run into a couple of extra issues that are worth mentioning:

  • I had problems using Spring Security’s @Secured annotation on controllers, so I went for URL-based access control instead.
  • Spring Boot uses the security. configuration prefix already, so don’t try to use it yourself!

All in all, I had to spend a lot of time on the Spring Security aspects. I hope someone feels up to migrating the Spring Security Core plugin because I think Grails users could definitely benefit from it! Things did run more smoothly after the security aspects were sorted out (I decided to also switch to pac4j for its OAuth support) and the only other thing that appears in my notes is the issue of configuration.

The joys of configuration

Despite the Convention over Configuration policy of Grails and Spring Boot, configuration is still a big part of app development. It just doesn’t hold you back in the early stages when you’re learning the platform.

The good news is that you can still use Groovy configuration files, as Grails adds an extra config loader to Spring Boot (which supports properties files and YAML out of the box). The big difference is how you name the configuration files and where you put them. The basic rule is that configuration files start with application, so application.groovy, application.properties etc. You can also provide environment-specific configuration files by adding the environment to the file name: application-production.groovy for example.

So far, so good. My first real issue came when I wanted to include Twitter and Google API keys in the configuration. I didn’t want to commit these to source control because they would then be publicly visible. So I tried the good old grails.config.locations setting to add external configuration files. Didn’t work. I eventually discovered what I needed to do by setting the logging level of org.springframework.boot to DEBUG and seeing what configuration files Spring Boot attempted to load. All I had to do was put an application.groovy file in the root directory of the project. Easy once you know how!

One small concern is that it’s not clear how Spring Boot merges configurations. What if you have the default datasource configuration in grails-app/conf/application.yml but want to override environment-specific settings in your external configuration file? I would love to see clear rules documented somewhere.

More worrying for me was that bean property overrides weren’t working. It’s one of those core features of Grails that’s been there for a long time, and is pretty much essential for configuration injection. That said, the main thing is that a functional test was added when the issue was fixed. Hopefully we will see fewer, if any, regressions in the Grails 3 line. BTW, if you don’t use configuration injection, I highly recommend it.


The eventual aim of any web application, unless it’s just a sample or experiment, is to be deployed where people can use it. The talk submissions application is no different. I’d previously deployed it to Heroku, so I thought I’d give that a go.

The really good news is that you can package and deploy a Grails application as an executable JAR file. Yay! This can significantly simplify deployments. The bad news is that I simply couldn’t get the application to start up in Heroku’s free tier. Despite the removal of much of the code in Grails’ core and web components, any non-trivial Grails application requires more than 512M of memory. I suspect the same goes for any non-trivial Spring Boot + Hibernate app, but I don’t know.

Regardless, this hurts anyone wanting to run a hobby web application, or one without much traffic. I eventually went with Boxfuse, which provides a fairly simple way to deploy apps to AWS and has specific support for Spring Boot and Gradle. I particularly like the way you can test your production app in a VirtualBox VM before pushing to AWS and all in all, I prefer it’s deployment model to that of Heroku. I hope to write a bit more about Boxfuse in a separate post.

I do fear that the memory requirements of an average Grails application will hurt adoption of the framework in the brand new(ish) world of multiple web apps and cloud/container deployments. I’m sure you can bring the memory requirements down by dropping things like GORM and GSPs, but I’m not sure we’ll know by how much until people start trying it. And the JVM + Spring foundation puts a hefty lower limit on memory consumption. This is partly speculation on my part, though, and I’d love to see some real world comparisons of memory usage.


So where does this leave Grails? I honestly don’t know. The competitive space for web frameworks is much more crowded now than it was back in the early days, even on just the JVM. Don’t forget node.js, golang and all the other platforms too. Having struggled with the Spring Security integration on this project, I definitely feel that Grails has something to offer in the JVM space with its strong conventions and its plugins.

I can see Grails becoming a viable option for those folks on the JVM that just want to get stuff done and don’t want to live on the bleeding edge. Or would like a more gradual on-ramp to the bleeding edge. For that to happen, I think Grails has to repair its image somewhat by focusing on robustness of releases. It’s also quite challenging to target such an audience because for every clever feature you add, you need a clever solution to user feedback when things inevitably go wrong. Easier upgrades wouldn’t go amiss either!

A good first step would be some guidance from the Grails team on what direction they hope to take the framework. I’ve talked about this in a more general way before, but I do think a vision and a set of values are essential for an open source project. That lets users and contributors know where they stand and where to focus any effort for contributions, among other benefits. Until that happens, it’s hard to know where Grails fits and hence how widely used it could be. I certainly wish the framework the best for the future and hope the OCI sponsorship proves to be a catalyst for its revival.

11 thoughts on “Exploring Grails 3

  1. dovydas

    Some guys already ported spring security plugin. It seems it passes unit tests. Probably milestone relese will ocur soon. You should check out github issue on plugins repo. Sorry I can’t post link, because Im on phone.

    On other note while using spring boot security I have found bug that checkbox tag doesn’t work correctly. Have it occured to you to?

  2. John Stacy

    Having used and loved Grails since 1.3.7, Grails 3 is a major disappointment. For whatever improvements it brings to the table, it brings a lot of pain. For example, Grails 3 uses Bintray for plugins. That site is beyond confusing. I can’t imagine that there was a technical reason to abandon the grails.org site to manage/collect plugins.

    That’s just one example.

    Grails 3 feels like it’s a different product, managed by a different set of people.

    For the first time since falling in love with Grails in 1.3.7, I’m looking at other options.

  3. Peter Post author

    @John It’s the same people, and it doesn’t feel that different to me. The plugin portal situation is simply a result of lack of resources I think. I used to be responsible for maintaining it while I was at VMware (among many other jobs) and it’s pretty time consuming. I recommend dropping feedback to the Bintray folks about your experience. I’m sure they’ll be receptive to recommendations for improvement.

  4. Peter Post author

    @dovydas I noticed the M1 release of the plugin was just released. Bad timing for me 🙂 I haven’t experienced any bugs with checkbox tag, but that doesn’t mean there isn’t one.

  5. Pingback: Settimanale Groovy #75 | BME

  6. Pingback: Diario Grails (settimana 33 del 2015) | BME

  7. Graeme Rocher

    John: The reason we are using Bintray for plugins is that we want to move away from custom infrastructure. There is a cost to running http://grails.org/plugins in terms of server resources that we would prefer not to continue to maintain. If Bintray had existed when we were looking to create a plugin portal we would not have created it at all.

    Anyway we are working on the Grails 3 plugin story and the situation will improve over time as more and more plugins are released for Grails 3. For all of the thousands of plugins that exist for Grails 2 there are many redundant / junk plugins so in a sense it is nice to start with a clean slate.

    Having said that I understand the confusion and hopefully soon we will develop something like plugins.gradle.org that provides a different, simpler view onto Bintray.

    Peter: For your Heroku problems did you try and limit the memory assigned to the JVM spun up by Heroku. Locally I am able to run simple Grails 3 applications in as little as 128mb:

    java -Xmx128m -jar myapp-0.1.jar

  8. Peter Post author

    Graeme: Yes, I tried adjusting the max heap size, but it didn’t seem to work. I think I tried 256M, 350M, and four hundred and something. You also have to remember that you’re specifying the max heap space, which is smaller than the VM memory size that Heroku knows about. Perhaps the way I was setting the VM options wasn’t taking effect for some reason, but I don’t know why that would be the case. I’m sure I followed instructions.

  9. Philippe Soares

    For me, the main bummer is that currently my IDE (intellij) is still not up to date for grails 3, although it seems scheduled for idea 15, which will be released sometime in Q4 (see https://youtrack.jetbrains.com/oauth?state=%2Fissue%2FIDEA-136970).

    Until then, I won’t spend time taking any steps at upgrading, but I keep hope that I’ll be able to in early 2016 (if all the plugins I use are upgraded by then or can be replaced easily through spring boot).

  10. Rafael C.

    Hi Peter,

    I am not a professional developer, but i like Grails Framework and I’m planning to user Grails 3.1 in my next experiment.

    My first contact with this framework was a long time ago, with stable version 1.3.7. I already use many others versions between 2.0 to 2.4. I’ve experimented version 2.5 but I think its a better idea to start exploring Grails 3.

    The changes are little painful , but I think that are for the best practices and the effort is worth it.

    Now I trying to be productive with Grails 3 Plugins, but I need some help/tip.

    In Grails 3, when we use build.gradle to specify plugins to install in dependecies{…}
    After instalation, the plugin is downloaded as a pre-compiled JAR and stored with many others external resources used by framework.

    I tried to set on build.gradle
    expecting the plugins to be separated, but not. I read in another page that it is helpful to get a subproject reloading.

    But my big “problem” is to edit/customize grails 3 Plugin files (gsp, groovy, js, css) in MyApp project. The JAR is not in my project directory and it is read-only. There is no way to reveal it in finder with IntelliJ IDE, so is very painful to find the JAR, decompress, edit, compress and compile aplication.

    Do you have any tip?
    I hope you decrypt my english =)

Leave a Reply

Your email address will not be published. Required fields are marked *