Some thoughts on the Grails and Groovy communities

Sunday, September 20th, 2015 10:41pm

If you’re a Grails user then you’re probably aware of some recent events online (Twitter, the Grails Slack channels, etc.) that are unfortunately still ongoing as I write this, and the whole situation is quite a mess. I’m not going to link to any of it or discuss it directly, but it got me thinking again about the Grails and Groovy communities, and the other “GR8” communities in the Groovy ecosystem (Ratpack, Gradle, Griffon, Geb, GPars, etc.)

When I start working in a new area of tech I usually sign up for a mailing list or forum, or whatever they tend to use for discussions about usage, upcoming releases, future plans, etc. I rarely get involved though. When I’m new at the tech I usually find that questions I would have asked have been asked and answered, and once I get good enough at it I tend to rely less on those resources. So I tend to lurk in general and don’t actively participate.

My tendency toward being a lurker is also affected by not wanting to embarrass myself online. When I was a graduate student I discovered the TeX typesetting software and thought that it would be great to use for papers, so I started collecting software and resources. Windows 95 had recently been released1 and Windows options weren’t great then. Someone asked a question on one of the local Usenet groups and being an expert I replied. Except that I was far from an expert and gave rather bad advice, and a few others who actually knew what they were talking about jumped in and provided useful information. I tend to have to touch the pretty glowing orange thing on the stove to learn that it’s very hot and a painful thing to do, so this was a good experience for me. It continues to be a reminder to try to be humble and to help where possible, but be willing to say “I don’t know” when that’s the case, and stay out of the way if I don’t have anything to contribute.

When I discovered Grails I signed up for the user and dev mailing lists. There was a lot to learn, and many of the emails didn’t make sense but I saved a bunch that seemed like they’d be useful later. I quickly learned a lot thanks to the helpful developers and users on the lists. Eventually I got good enough that there were questions that I could answer, but often others would answer before I did. Occasionally a more obscure question would go unanswered, and those would nag at me from my inbox. Sometimes when I was stuck on something for work I would take a break and look at some of those questions and try to see what’s going on, either because it did or might affect what I was working on, or just because it was interesting. If I didn’t get anywhere, then I would let it go, but if I felt like I figured it out or that I at least could contribute useful insights, I would reply with what I found.

Getting a reply on the list from a frustrated user saying that I’ve helped them get past an annoying issue is a pretty cool thing, and a big motivator to continue. Much like teaching, helping others with tech support issues is usually beneficial for both sides since it forces you to understand what’s going on under the hood much more than when you just use the feature. In retrospect, although I was reluctant to start giving back, it didn’t make sense not to. The lists were active with lots of generally respectful discussions, and although people have come and gone, there remains an overall tone and it’s profoundly positive.

When I started going to Grails conferences, the subject of how helpful the communities are was (and still is) a common topic in hallway and mealtime discussions. This was weird to me because I hadn’t really noticed, mostly since I hadn’t really seen communities that weren’t. Of course I’ve become aware of some of what they were referring to :)

So the big question is: why are these communities so helpful and friendly? I can’t know for sure, but it obviously has a lot to do with the project leads and big names in the various techs. From the beginning, their personalities and temperaments set the tone that continues today. Why we were lucky to have these people driving the technologies in the first place is a topic for a future blog post, or at least something to discuss over beers at future conferences and meetups.

I’ve learned so much more than I could have expected by participating in all of this, and I’ve been lucky to meet a large number of smart, funny, inquisitive, amazing people. Thank you all, and keep up the great work. It’s easy to get distracted by the frustrating bits and the negative aspects, but weeks like this one are, if we’re able to see past them, a good reminder of how much we have and tend to take for granted.

As a side note, I cringed a bit when the Greach organizers announced that they had put up a code of conduct for this year’s conference. After some high-profile incidents at Python- and Ruby-related conferences (and elsewhere) many conferences did the same, but it didn’t make sense to me to do this at a Groovy-related conference since it’s not needed. It didn’t take long to realize that this was naive, and while we are a friendly bunch, there have likely been incidents where attendees were harassed or made uncomfortable and I wasn’t aware of them. And even if not, there’s nothing wrong with putting core beliefs and expectations in writing. My version would be a lot shorter though: “Don’t be a jerk”.

I rarely say this but it’s pretty much always the case – these are my thoughts and opinions and I don’t claim to speak for anyone or any company or organization I’ve worked with in the past, present or future.

Also, all comments on this blog are moderated and I will not accept any that aren’t constructive, and I reserve the right to disable comments entirely on this post if necessary.

  1. I pre-ordered my copy and it was delivered by FedEX the day it was released – very exciting![back]

One more approach for diagnosing spring-security-core login errors

Thursday, January 30th, 2014 10:16pm

I wrote up a few techniques to help determine what is happening when you are unable to authenticate with use the Grails spring-security-core plugin here and since then I’ve had to use them myself a couple of times. I have everything configured to easily debug the issues and often that ends up being the best approach, but not everyone is comfortable with a debugger, or not excited about the prospect of configuring their IDE with JAR sources and the other steps needed to properly debug. This and this Stack Overflow question prompted me to document another approach.

This one is a rather dangerous and should be removed as soon as the issue is resolved because it prints cleartext passwords to the console, which is a huge security risk.

There are a handful of places where the cleartext password is available, but I think the most convenient is in the additionalAuthenticationChecks method of DaoAuthenticationProvider. The arguments to the method are the UserDetails instance, which will have the hashed password from the database, and the UsernamePasswordAuthenticationToken which will have the cleartext password.

To access this, create a subclass of DaoAuthenticationProvider:

package deletethisasap

import as UPAT

class MyDaoAuthenticationProvider extends DaoAuthenticationProvider {

  protected void additionalAuthenticationChecks(UserDetails ud, UPAT auth) throws AuthenticationException {
    String hashedPassword = passwordEncoder.encodePassword(
         auth.credentials, null)
    boolean ok = passwordEncoder.isPasswordValid(
         ud.password, auth.credentials, null)
    println "Cleartext: '$auth.credentials' from DB: '$ud.password' hashed '$hashedPassword' Valid: $ok"
    super.additionalAuthenticationChecks ud, auth

and register it with the same bean name in grails-app/conf/spring/resources.groovy:

import deletethisasap.MyDaoAuthenticationProvider

beans = {
  daoAuthenticationProvider(MyDaoAuthenticationProvider) {
    userDetailsService = ref('userDetailsService')
    passwordEncoder = ref('passwordEncoder')
    userCache = ref('userCache')
    saltSource = ref('saltSource')
    preAuthenticationChecks = ref('preAuthenticationChecks')
    postAuthenticationChecks = ref('postAuthenticationChecks')
    authoritiesMapper = ref('authoritiesMapper')
    hideUserNotFoundExceptions = true

It prints the hashed password and the cleartext password, and the cleartext password hashed for comparison. This won’t necessarily be the same as the value from the database, for example when using bcrypt, but the encoder has an isPasswordValid method to verify that they’re equivalent, so that is also printed.

This code assumes that you’re using standard form-based authentication (i.e. DaoAuthenticationProvider) and that you’re not using a salt. If you are using salted passwords, dependency-inject the saltSource bean and use it in the encodePassword and isPasswordValid methods.

Automatically converting password hashes in Grails spring-security-core

Friday, December 20th, 2013 5:13pm

I was looking at this Stack Overflow question about converting password hashes and realized that it’s possible and rather convenient when using the spring-security-core plugin to automate the process.

To start, we’ll need a PasswordEncoder that can work with both algorithms. Here I’m assuming that you’ll be converting from SHA-256 (optionally with a salt) to bcrypt, but the general approach is mostly independent of the algorithms. Sha256ToBCryptPasswordEncoder will always hash new passwords using bcrypt, but can detect the difference between hashes from SHA-256 and bcrypt in isPasswordValid:


import grails.plugin.springsecurity.authentication.encoding.BCryptPasswordEncoder;


public class Sha256ToBCryptPasswordEncoder
       implements {

   protected MessageDigestPasswordEncoder sha256PasswordEncoder;
   protected BCryptPasswordEncoder bcryptPasswordEncoder;

   public String encodePassword(String rawPass, Object salt) {
      return bcryptPasswordEncoder.encodePassword(rawPass, null);

   public boolean isPasswordValid(String encPass,
            String rawPass, Object salt) {
      if (encPass.startsWith("$2a$10$") && encPass.length() == 60) {
         // already bcrypt
         return bcryptPasswordEncoder.isPasswordValid(
                    encPass, rawPass, null);

      if (encPass.length() == 64) {
         return sha256PasswordEncoder.isPasswordValid(
                    encPass, rawPass, salt);

      // TODO
      return false;

    * Dependency injection for the bcrypt password encoder
    * @param encoder the encoder
   public void setBcryptPasswordEncoder(BCryptPasswordEncoder encoder) {
      bcryptPasswordEncoder = encoder;

    * Dependency injection for the SHA-256 password encoder
    * @param encoder the encoder
   public void setSha256PasswordEncoder(
           MessageDigestPasswordEncoder encoder) {
      sha256PasswordEncoder = encoder;

This needs dependency injections for properly configured SHA-256 and bcrypt encoders, and we’ll see that in a bit.

Sha256ToBCryptPasswordEncoder cannot make any changes as only password information is available, so we’ll subclass DaoAuthenticationProvider and do this work in additionalAuthenticationChecks:


import grails.plugin.springsecurity.SpringSecurityUtils
import grails.plugin.springsecurity.userdetails.GrailsUser


class PasswordFixingDaoAuthenticationProvider
extends DaoAuthenticationProvider {

   def grailsApplication

   protected void additionalAuthenticationChecks(
         UserDetails userDetails,
         UsernamePasswordAuthenticationToken authentication)
            throws AuthenticationException {
      super.additionalAuthenticationChecks userDetails, authentication

      // if we got this far the password was ok

      String oldHashedPassword = userDetails.getPassword()
      if (oldHashedPassword.startsWith('$2a$10$') &&
            oldHashedPassword.length() == 60) {
         // already bcrypt

      if (oldHashedPassword.length() != 64) {
         // TODO

      String bcryptPassword = getPasswordEncoder().encodePassword(
               authentication.credentials, null) 

      // use HQL to update the password in the database directly

      def conf = SpringSecurityUtils.securityConfig
      String userClassName = conf.userLookup.userDomainClassName
      Class<?> User = grailsApplication.getDomainClass(userClassName).clazz

      def args = [p: bcryptPassword]
      String hql = 'update ' + + ' u set u.password=:p where '
      if (userDetails instanceof GrailsUser) {
         hql += '' =
      else {
         hql += 'u.' + conf.userLookup.usernamePropertyName + '=:un'
         args.un = userDetails.username

      User.withNewSession {
         User.withTransaction {
            User.executeUpdate hql, args

Calling super.additionalAuthenticationChecks() will ensure that a password was provided and it will be verified using either SHA-256 or bcrypt by Sha256ToBCryptPasswordEncoder, so if there is no exception thrown it’s safe to update the password. Note that the update code is generic and can be made more compact by hard-coding your class and property names.

We register Sha256ToBCryptPasswordEncoder as the passwordEncoder bean, and create bcryptPasswordEncoder and sha256PasswordEncoder beans, configured with the SHA-256 settings that were being used, and the bcrypt settings that will be used (configure those in Config.groovy as described in the docs). Also configure the bean override of daoAuthenticationProvider to be a PasswordFixingDaoAuthenticationProvider with the same configuration as is done in SpringSecurityCoreGrailsPlugin.groovy with the addition of the grailsApplication reference:

import grails.plugin.springsecurity.SpringSecurityUtils
import grails.plugin.springsecurity.authentication.encoding.BCryptPasswordEncoder



beans = {

   def conf = SpringSecurityUtils.securityConfig

   bcryptPasswordEncoder(BCryptPasswordEncoder, conf.password.bcrypt.logrounds) // 10

   sha256PasswordEncoder(MessageDigestPasswordEncoder, conf.password.algorithm) {
      encodeHashAsBase64 = conf.password.encodeHashAsBase64 // false
      iterations = conf.password.hash.iterations // 10000

   passwordEncoder(Sha256ToBCryptPasswordEncoder) {
      bcryptPasswordEncoder = ref('bcryptPasswordEncoder')
      sha256PasswordEncoder = ref('sha256PasswordEncoder')

   daoAuthenticationProvider(PasswordFixingDaoAuthenticationProvider) {
      userDetailsService = ref('userDetailsService')
      passwordEncoder = ref('passwordEncoder')
      userCache = ref('userCache')
      saltSource = ref('saltSource')
      preAuthenticationChecks = ref('preAuthenticationChecks')
      postAuthenticationChecks = ref('postAuthenticationChecks')
      authoritiesMapper = ref('authoritiesMapper')
      hideUserNotFoundExceptions = conf.dao.hideUserNotFoundExceptions // true
      grailsApplication = ref('grailsApplication')

With this configuration, new users’ passwords will be hashed with bcrypt, and valid existing users’ passwords will be converted to bcrypt using the plaintext passwords used during login. Once your users are converted, back out these changes and convert to the standard bcrypt approach. This would involve deleting the grails.plugin.springsecurity.password.algorithm attribute and all salt configuration since bcrypt doesn’t support a salt, deleting Sha256ToBCryptPasswordEncoder and PasswordFixingDaoAuthenticationProvider, and removing the bcryptPasswordEncoder and sha256PasswordEncoder bean definitions and passwordEncoder and daoAuthenticationProvider overrides from resources.groovy since the beans configured by the plugin using Config.groovy settings will be sufficient. Also if you had added salt to the User class encodePassword method, e.g.

protected void encodePassword() {
   password = springSecurityService.encodePassword(password, username)

convert it back to the default without a salt:

protected void encodePassword() {
   password = springSecurityService.encodePassword(password)

Some approaches for diagnosing spring-security-core login errors

Wednesday, December 11th, 2013 10:08pm

If you use the Grails spring-security-core plugin and you’re unable to authenticate, it can be hard to know where to start looking for the cause. Often it’s due to confusion from older blog posts that tell you to explicitly hash the password when creating a user, e.g.

def user = new User(username: 'me', enabled: true,
     password: springSecurityService.encodePassword('password')).save()

But the generated User domain class auto-hashes your password for you, so you would just do this (I omitted setting enabled since in 2.0 it defaults to true):

def user = new User(username: 'me', password: 'password').save()

If that isn’t the problem, Spring Security logs a lot at the debug level, so enable that in the log4j block in Config.groovy:

log4j = {
   debug ''

With any luck there will be a useful signal in the noise and it’ll point you in the right direction.

If that doesn’t do it, you can configure a debugger and set a breakpoint in in the authenticate method. That’s where each registered AuthenticationProvider gets a chance to attempt an authentication if it supports the current Authentication.

Not everyone likes to use a debugger though. Another option is to register an event listener and look at the failure events. This is described in the plugin docs here. Here’s a simple configuration that will print information to the console for all failure events:

grails.plugin.springsecurity.useSecurityEventListener = true
grails.plugin.springsecurity.onAbstractAuthenticationFailureEvent = { e, appCtx ->
   println "\nERROR auth failed for user $ $e.exception.message\n"

Using MongoDB With Version 2.x of the Grails Spring Security Core Plugin

Sunday, December 01st, 2013 10:32pm

With a few customization steps it’s easy to use MongoDB to store user and role information for the spring-security-core plugin instead of using Hibernate, and after seeing this Stack Overflow question I thought I’d write up some notes on how to do this with the current plugins. Note that much of this is based on this blog post.

I created a demo application using Grails 2.3.3; it’s available on GitHub. The general steps were:

  • $ grails create-app mongoSpringSecurity
  • add the plugins to BuildConfig.groovy
  • $ grails s2-quickstart auth User Role
  • update DataSource.groovy to use MongoDB
  • create a custom UserDetailsService and register it in resources.groovy
  • create a test role and a user in BootStrap.groovy
  • customize the domain classes to use MongoDB
  • add tags to index.gsp to add a login link if you’re not logged in, and show that you’re logged in if you are

One difference between what I do here and what was done in the original blog post is that the custom UserDetailsService is not a Grails service – it’s in src/groovy and not in grails-app/services. It wasn’t necessary to be a real service then and isn’t now; it’s a coincidence that the Spring Security interface name ends in “Service”. See the plugin documentation for general information about customizing this bean.

You can see the source for the custom bean here. By embedding the authorities in the user domain class, the many-to-many relationship is not needed and the model is a lot simpler, so the class implementation is also – for example there’s no need for a withTransaction block to avoid lazy loading exceptions.

The changes for the User class are fairly minor. You need static mapWith = 'mongo' if you have both the Hibernate and MongoDB plugins; in this case it’s unnecessary but harmless to leave it in. The id field should be an ObjectId, and I retained the other customizations from the earlier blog post (the embedded roles, the addition of the email field, extra constraints, etc.). The Role class changes are similar.

Since we’re using a custom UserDetailsService, we can delete the userLookup.userDomainClassName, userLookup.authorityJoinClassName, and authority.className properties from Config.groovy, and since the roles are embedded in the user class we can delete the generated UserRole class.

You should be able to clone the repo and start the application (assuming you have MongoDB and Grails 2.3.3 already). Click the login link on the start page and after you successfully authenticate, the link should be replaced by a message.

Converting Grails Applications to Plugins and vice versa

Monday, July 22nd, 2013 2:57pm

I was in London last week on vacation with my family and was lucky that there was a London GGUG meetup during my visit. David Dawson discussed modularizing Grails applications by refactoring them into multiple plugins (you can see the video of his talk here). One thing that he mentioned was the idea of plugins that can be run like standalone applications since the structures of Grails applications and plugins are so similar, and I thought it would be interesting to look at the process of converting an application to a plugin or a plugin to an application.

The approaches I’ll discuss here include a lot of bias on my part about how I like to create apps and plugins, so YMMV. I also won’t go into partial conversions since David covered this well in his talk.

So to convert an application to a plugin, the general workflow would be something like

  • Create the plugin descriptor, FooGrailsPlugin.groovy. The easiest way to do this is to run grails create-plugin pluginname and copy the generated file from there
  • delete everything from except the app.grails.version property
  • if you have jars in the lib directory that are available in a Maven repo, delete them and replace with BuildConfig.groovy dependencies
  • change any plugin and jar dependencies that are needed for development and testing but not when the plugin is installed to not be exported, by adding export = false
  • If you need the _Install.groovy, _Uninstall.groovy, or _Upgrade.groovy scripts (you probably don’t) grab those from the dummy plugin from step 1 (but delete any you don’t need, they’re all optional)
  • delete ApplicationResources.groovy if you aren’t using it and don’t depend on resources plugin
  • move code from BootStrap.groovy init() to FooGrailsPlugin.doWithApplicationContext and/or FooGrailsPlugin.doWithDynamicMethods and destroy() to FooGrailsPlugin.onShutdown, and delete BootStrap.groovy
  • add a dependency for the release plugin in BuildConfig.groovy
  • delete everything but the log4j configuration from Config.groovy
  • delete UrlMappings.groovy unless you have exported mappings; only keep the added ones
  • move bean definitions from resources.groovy to FooGrailsPlugin.doWithSpring and delete resources.groovy
  • delete grails-app/i18n message bundle files unless you added messages; only keep the added ones
  • delete everything from grails-app/views that you don’t use (in particular error.gsp, index.gsp, and layouts/main.gsp)
  • delete everything from web-app that you don’t use (including WEB-INF xml and tld files)
  • now would be a great time to write those tests you’ve been meaning to get to
  • create one or more test applications to install the plugin into to ensure that it works as a plugin; consider scripting this
  • write documentation for how to use the plugin; at a minimum a README file, but Grails gdoc files would be much better (run grails doc --init to get started)

Converting a plugin to an application is similar, except for the most part reversed:

  • Create a dummy application with grails create-app appname to copy missing files from
    • Move BootStrap.groovy, Config.groovy, UrlMappings.groovy, and ApplicationResources.groovy into grails-app/conf, merging if needed
    • Move resources.groovy into grails-app/conf/spring
    • Move message bundle files to grails-app/i18n, merging if needed
    • Move missing GSPs to grails-app/views
    • Move static resources from web-app
    • Move xml and tld files from web-app/WEB-INF
  • Move code from FooGrailsPlugin.doWithApplicationContext and FooGrailsPlugin.doWithDynamicMethods to BootStrap.groovy init(), and code from FooGrailsPlugin.onShutdown to destroy()
  • Move bean definitions from FooGrailsPlugin.doWithSpring to resources.groovy
  • Delete the plugin descriptor
  • Restore missing properties in
  • Delete the _Install.groovy, _Uninstall.groovy, and _Upgrade.groovy scripts
  • Remove the dependency for the release plugin from BuildConfig.groovy
  • Now would be a great time to write those tests you’ve been meaning to get to
  • If you make changes in the plugin’s doWithWebDescriptor, run grails install-templates and add them to src/templates/war/web.xml
  • If you add custom artifacts, or were supporting development-environment code or config changes in onChange and/or onConfigChange, these aren’t directly doable in an application. Use the pluginator plugin for these, and also for dynamic web.xml changes that require runtime logic

  • I’ve probably skipped a few steps and definitely omitted a lot of detail, but this should cover most of the process for each type of conversion.

This Week in Grails (2013-20)

Saturday, May 25th, 2013 7:15pm

The big news is that Grails 2.3 M1 was released. 2.3 will be a big update with many fixes, enhancements, and new features. M1 only has a subset of what’s coming and it’s already packed with cool new stuff. Graeme did some writeups on what’s coming, Grails 2.3 M1 and Upcoming M2 and Road to Grails 2.3: RESTful URL Mappings and URL Mapping Reports.

Be sure to check out this cool video on Grails that the folks at Orange & Bronze created.

I released two plugins, standalone-tomcat-memcached and standalone-tomcat-redis. These are like the database-session plugin in that they reconfigure the web server to store session data in a datastore instead of the traditional approach, but these only work with Tomcat since they work directly with the Tomcat APIs instead of intercepting and replacing the real sessions. I’ve been working on reconfiguring how Grails applications deploy to Heroku, changing from using an embedded Jetty instance to using the standalone plugin (either with Tomcat or Jetty). Along the way since Heroku doesn’t support sticky sessions I created these plugins to get things working smoothly with the heroku plugin. More on this later.

If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.

Translations of this post:


There were 7 new plugins released:

  • apidocs version 0.1. Generates REST API documentation
  • criteria-js version 0.3. GORM criteria for JavaScript
  • db-helper-rest version 0.3. Provides methods for dropping, creating and initialization of database schema from the project bootstrap
  • httplogger version 1.0. Logs HTTP traffic
  • required-parameters version 1.0.0. Enables verifying required parameters for controller actions using simple annotations
  • standalone-tomcat-memcached version 0.1. Uses Memcached as the Tomcat session manager
  • standalone-tomcat-redis version 0.1. Uses Redis as the Tomcat session manager

and 26 updated plugins:

  • goodform version 1.0.2. Create extremely usable complex forms with rules based flow that work well in browsers
  • airbrake version 0.9.3. Notifier plugin for integrating apps with Airbrake
  • asynchronous-mail version 1.0-RC5. Send email asynchronously by storing them in the database and sending with a Quartz job
  • aws-sdk version 1.4.3. Use the Amazon Web Services infrastructure services
  • closure-templates-resources version 0.2.3. Supports server-side compilation of .soy template files to JavaScript files
  • easyui version 1.3. Supplies jQuery EasyUI resources and taglibs
  • external-config-reload version 1.3.0. Polls for changes to external configuration files (files added to grails.config.locations), reloads the configuration when a change has occurred, and notifies specified plugins by firing the onConfigChange event in each
  • font-awesome-resources version 3.1. Integrates the Font Awesome icon set
  • google-visualization version 0.6.2. Provides a taglib for the interactive charts of the Google Visualization API
  • grails-melody version 1.44. Integrates the JavaMelody system monitoring tool
  • hibernate version 3.6.10.M3. Provides integration between Grails and Hibernate through GORM
  • i18n-fields version 0.6.4. Provides a declarative way of localizing domain classes’ fields for different languages
  • jrimum-bopepo version 0.3. Allows you to create Boletos Bancarios for Banks of Brazil using the Jrimum Bopepo library
  • neo4j version 1.0.0.RC2. GORM for Neo4j
  • newrelic version 1.0-2.18.0. Adds the NewRelic Real User Monitoring feature to your GSP pages
  • pusher version 0.5. Wrapper for REST api
  • recaptcha version 0.6.5. Integrates ReCaptcha and Mailhide services
  • remote-pagination version 0.4.4. Provides tags for pagination and to sort columns without page refresh using Ajax and loads only the list of objects needed
  • segmentio version 0.2.0. Use to send your analytics data to any service you want, without you having to integrate with each one individually
  • spring-security-mock version 1.0.2. Mock authentication support for Spring Security
  • standalone version 1.2.1. Runs a Grails application as a JAR file with an embedded Tomcat server
  • vaadin version 1.7.5. Adds Vaadin ( integration
  • validate-config version 0.4.2. Adds methods to ConfigObject for validating expected and required properties
  • war-exec version 1.0.3. Makes the war files generated by Grails executable (java -jar myapp.war) by embedding Jetty. Jetty can be configured using properties in Config.groovy
  • webdriver version 0.4.2. Integrates Webdriver with Grails to allow functional testing in both HtmlUnit and real browsers
  • xwiki-rendering version 1.0-RC3. Convert texts using XWiki Rendering Framework

Interesting Tweets


User groups and Conferences

This Week in Grails (2013-17)

Tuesday, May 07th, 2013 1:19pm

We released Grails 2.1.5 and Grails 2.2.2 this week. Grails 2.3.M1 is tentatively planned for next Tuesday will be released soon.

I linked to Peter Ledbrook’s Where next for Grails? post previously and there have been two interesting followup posts, one from David Dawson and one from Graeme.

Ticket sales for GR8Conf EU end soon, so be sure to get yours.

Several new Grails presentations have become available:

Programming Grails is printing, and I got my copy this week. You can get yours at the O’Reilly website and at Amazon, and there is also a sample chapter available. You can save 50% until May 8th.

If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.

Translations of this post:


There were 5 new plugins released:

  • jquery-date-time-picker version 0.1.0. Makes it easy to use jQuery date and time pickers
  • keywords-and-tags version 0.1. Provides a taglib able to highlight keywords/tags on your pages for SEO purposes
  • poly-driver version 0.2. Lets you specify a different preferred browser for each specific Geb specification class in a test suite
  • restrpc version 0.1. RESTRPC is an interceptor api that allows the user to associate more than one method/function per request method while still being compliant with the REST standard thus creating a ONE-TO-MANY pairing
  • scaffolding version 1.0.0. Handles the configuration of dynamic scaffolding

and 25 updated plugins:

  • atmosphere-meteor version 0.4.3. Incorporates the Atmosphere Framework ( and can form the basis for a traditional XMPP server with a browser-based client without the limitations of BOSH
  • aws-sdk version 1.4.2. Use the Amazon Web Services infrastructure services
  • barcode4j version 0.3. Generates barcodes using
  • build-test-data version 2.0.5. Enables the easy creation of test data by automatic inspection of constraints
  • cors version 1.1.0. Installs a servlet filter to set Access-Control-Allow-Origin and other CORS related headers to enable cross site AJAX requests to your Grails application
  • database-migration version 1.3.3. Official Grails plugin for database migrations
  • dojo version Integrates the Dojo javascript toolkit
  • easyui version 1.0. Supplies jQuery EasyUI resources and taglibs
  • filterpane version 2.1.5. Adds filtering capabilities
  • hibernate version 3.6.10.M1. Provides integration between Grails and Hibernate through GORM
  • html5-mobile-scaffolding version 0.6.1. Scaffolds HTML5 mobile application using jQuery mobile in a single page
  • jaxrs version 0.8. Supports the development of RESTful web services based on the Java API for RESTful Web Services (JSR 311: JAX-RS)
  • marshallers version 0.3. Easy registration and usage of custom XML and JSON marshallers supporting hierarchical configurations
  • multi-tenant-single-db version 0.8.3. Multi tenant setup focused on single database mode
  • plastic-criteria version 0.9. Mock Grails Criteria for Unit Tests
  • plugin-config version 0.1.8. Simplifies plugin configuration tasks
  • quartz version 1.0-RC7. Schedules jobs to be executed with a specified interval or cron expression using the Quartz Enterprise Job Scheduler
  • recaptcha version 0.6.4. Integrates ReCaptcha and Mailhide services
  • release version 3.0.0. Publishes Grails plugins either to a public or private repository
  • rendering version 0.4.4. Render GSPs as PDFs, JPEGs, GIFs and PNGs
  • spring-security-facebook version 0.14. Plugin for Facebook Authentication, as extension to Grails Spring Security Core plugin
  • tomcat version 7.0.39. Makes Tomcat 7.0 the default servlet container for Grails at development time
  • vaadin version 1.7.4. Adds Vaadin ( integration
  • validate-config version 0.4.1. Adds methods to ConfigObject for validating expected and required properties
  • zk version 2.2.0. Adds ZK Ajax framework ( support to Grails applications

Interesting Tweets


User groups and Conferences

This Week in Grails (2013-15)

Saturday, April 20th, 2013 8:54pm

The Groovy team released Groovy 2.0.8 and 2.1.3 this week.

Peter Ledbrook wrote up some thoughts about the future of Grails on his blog.

Check out this recent GGUG talk on Grails services, command objects and design approaches.

If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.

Translations of this post:


There were 3 new plugins released:

  • grooscript-vertx version 0.2.5. Convert your Groovy files to Javascript
  • search-fields version 0.1. Auto-generate search query based on DSL in domain classes
  • yui-war-minify version 1.2. Runs yui-compressor on css and javascript resources at WAR creation time

and 11 updated plugins:

  • build-info version 1.2.4. Provides a controller/view that display basic information about the war file
  • coffeescript-resources version 0.3.8. Create coffeescript modules that automatically compiles on every file change with jCoffeeScript
  • cxf version 1.1.1. Expose Grails services as SOAP web services via CXF
  • cxf-client version 1.5.3. Use existing (or new) Apache CXF wsdl2java generated content to invoke SOAP services
  • easyui version 0.9. Supplies jQuery EasyUI resources and taglibs
  • ember-templates-precompiler version 0.4.1. Precompiles EmberJS powered Handlebars templates
  • envers version 2.1.0. Integrates with Hibernate Envers
  • filterpane version 2.1.3. Adds filtering capabilities
  • gson version 1.1.4. Provides alternate JSON (de)serialization using Google’s Gson library
  • paypal version 0.6.9. Adds PayPal integration
  • uploadr version 0.7.3. HTML5 Drag and Drop file uploader

Interesting Tweets

User groups and Conferences

This Week in Grails (2013-14)

Sunday, April 14th, 2013 11:02am

SpringSource has moved from VMware to EMC as part of Pivotal. Check out Adrian Colyer’s blog post for information about how this will affect Grails, Groovy, and Spring and what the future looks like for us.

The Groovy team did an extensive interview with ZeroTurnaround, lots of interesting stuff there.

Happy Birthday to Grails, the 0.1 release was 7 years ago.

I wrote a blog post about a new plugin that integrates Netty with Grails. It will probably take an integration into Grails core to see real benefits, but there should be some opportunities to improve scalability and performance with this plugin.

If you want to keep up with these “This Week in Grails” posts you can access them directly via their category link or in an RSS reader with the feed for just these posts.

Translations of this post:


There were 3 new plugins released:

  • domain-locking version 0.3. Provides an easy way to use optimistic/pessimistic lock
  • nettymvc version 0.1. Adds support for using Netty in Grails
  • typescript version 0.4.1. Helps you manage typescript code in your Grails application

and 16 updated plugins:

  • facebook-sdk version 0.4.10. Allows your application to use the Facebook Platform and develop Facebook apps on or on web sites (with Facebook Connect)
  • file-server version 0.2. Serves files from any directories on disk
  • force-response-download version 0.1.5. Forces the browser to open a dialog for downloading content produced within controller actions
  • geasyui version 0.8. Supplies jQuery EasyUI resources and taglibs
  • geb version 0.9.0. Geb is a library for headless web browsing on the JVM, suitable for automation and functional web testing
  • gorm-interceptors version 0.1.1. Interceptors for GORM methods (excluding find, countBy, addTo, removeFrom methods)
  • gson version 1.1.3. Provides alternate JSON (de)serialization using Google’s Gson library
  • handlebars-resources version 0.3.6. Supports using Handlebars.js templates with the Grails Resources Plugin
  • plastic-criteria version 0.8. Mock Grails Criteria for Unit Tests
  • remote-pagination version 0.4.3. Provides tags for pagination and to sort columns without page refresh using Ajax and loads only the list of objects needed
  • sharding version 1.0. Defines multiple database shards to horizontally scale data
  • slug-generator version 0.3.1. Generates unique slugs for String properties, for example to generate unique ‘nice’ urls for access to domain objects
  • spring-security-twitter version 0.5. Twitter authentication as extension to the Spring Security Core plugin
  • uploadr version 0.7.2. HTML5 Drag and Drop file uploader
  • vaadin version 1.7.3. Adds Vaadin ( integration
  • zkui version 0.5.6. Seamlessly integrates ZK with Grails’ infrastructures; uses the Grails’ infrastructures such as GSP, controllers rather than zk’s zul as in ZKGrails plugin

Interesting Tweets


User groups and Conferences

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.