So, where we start?
Grails have the concept of Plugins. If you’re learning how the framework work it’s really interesting to spend some time understanding this topic. The framework itself has a set o plugins that’s already available for you.
If you’re using GGTS / STS, you can use ctrl + shift + T and type *GrailsPlugin*. Sometimes when I want to know how some aspect of Grails works, I try to find the plugin responsible for that.
Finding the Plugin
In this specific case, we have I18NGrailsPlugin. If you look at the source you can see the declaration of the messageSource bean.
So we can extend PluginAwareResourceBundleMessageSource and declare this as our messageSource and declare the Spring Bean:
But doing that we have a problem: all attributes that I18NGrailsPlugin had setup aren’t configured in our class! Without basenames properly set our class don’t know the existence of the properties files.
There are two options to solve our issue:
#1 – Duplicate code
We can duplicate the I18NGrailsPlugin code, setting up the properties of the ExposedKeysMessageSource class. But this is bad, what if the configuration code changes? We need to always check Grails updates to be up-to-date.
#2 – Hook the messageSource configuration
What if I tell you that we can use the configuration made by the i18n plugin, but using our customized class? Certainly better.
And already exists an example, the Tomcat JDBC Pool Plugin. The aim of this plugin is to change the pool implementation used by Grails to the Tomcat JDBC (ships with Tomcat 7), and all this is made in the doWithSpring closure. So, adapting to us:
Note that we don’t need to re-declare messageSource anymore, since we already changed the original Spring Bean configuration.
But note also that I used a new method called getAllProperties. Here’s the updated code of our MessageSource: