Grails - override message bundle property at runtime

Question

Is there a way to override at runtime the value of a property defined in a message bundle?

My grails application contains a property in the messages.properties file:

page1.para1.text=Some text to display to the user

My Config.groovy defines the following config location:

grails.config.locations = [ "file:${userHome}/.myApp/myApp-config.properties" ]

I currently use this approach to override Config.groovy properties (like db connections, etc), but it doesn't seen to apply to message bundle properties.

I was hoping/expecting to just make sure that the myApp-config.properties file contains my new property value, restart the Tomcat server where my app is deployed and it would get picked up and displayed on my page:

page1.para1.text=Some DIFFERENT text to display to the user

Grails docs on Internalization/Message bundles grails i18n doesn't suggest if this is possible or not.

Obviously, I'm trying to achieve this change without the need to recompile and redeliver my Grails application.

Any ideas?

Thanks in advance.

Answer 1

When you are already live and don't want to create a new .war file:

I'm not sure, but the .war file can be found unzipped on the server. You might try to replace the message files directly on the server, but a restart of the app might be necessary. But I wouldn't advice doing so.

If you need to often change the message bundles at runtime, I guess it would make sense to store them in the database. But that means that you have to change your code a little bit and redeploy it once. There is a blog entry which describes how to do it: http://graemerocher.blogspot.de/2010/04/reading-i18n-messages-from-database.html Another SO question handles the case that you want to store changes to the messages in a DB but fall back to the files: Grails i18n From Database but Default Back To File

hth

Answer 2

In theory you should be able to replace the messageSource bean with a ReloadableResourceBundleMessageSource inside Resources.groovy. This way you can not only point it to a new location but also declare how often they should be invalidated as cached values.