Grails leverages the “Convention Over Configuration” design paradigm, which functions to decrease the number of decisions that a developer using the framework is required to make without losing flexibility. This is one of the ways Grails significantly increases developer productivity!
While Grails applications often involve considerably less configuration than similar applications built with other frameworks, some configuration may still be necessary. This post will detail a number of mechanisms that make it easy for Grails developers gain access to those configuration values at runtime.
The default configuration file for Grails 3 applications is
grails-app/conf/application.yml. In this file, YAML
syntax is supported.
That file defines 3 configuration properties.
This article will not go into detail about YAML syntax. For that see the main YAML site. Instead, this article will focus on Grails 3 specific features related to accessing those configuration values.
The Config Property In GrailsApplication
interface defines the getConfig
method which returns a Config
object. In the Spring application context is a bean named
which is an instance of a class which implements the
interface. Retrieving the config object from this bean is one way to gain
access to config values.
config.getProperty('max.line.numbers') is preferred over something like
config.max.line.numbers. The latter can result in unexpected behavior when
retrieving values that do not exist and also is less performant.
There is an overloaded version of the
getProperty method that accepts a type.
This overloaded method will convert the corresponding config value to the
There is another overloaded version of the ‘getProperty’ method which accepts both a type and a default value.
For required properties you could write application code that reacts however is appropriate if the property doesn’t exist. You could also use the getRequiredProperty method which will throw an exception if a requested property does not exist.
Config Dependency Injection
For config values that are needed during request processing an application may want to retrieve the value only once instead of retrieving it repeatedly during each request that requires access to the config value. For example, the following is not ideal because the application is paying the performance price of retrieving the config value every time the controller action is invoked.
Config Injection Using GrailsConfigurationAware
An alternative is to retrieve the config value only once and then hold on to it so that it may be used later as many times as necessary. One way to do this is to have the config injected into any bean by implementing the GrailsConfigurationAware interface. There is a bean post processor that will discover all beans that implementat that interface and that post processor will invoke the setConfiguration method on those beans, passing the config object as an argument.
Config Injection Using @Value
Another option for injecting config values is to use the @Value annotation.
In the example above an exception will be thrown if the
value does not exist. In order to provide a default value with the
annotation, provide the default value after a
: in the expression supplied
to the annotation.
The examples above detail several approaches for retrieving config values at runtime. Grails intentionally provides several options, each with their own strengths and flexibility. Knowing where and when config values need to be accessible will help dictate which approach makes the most sense for a particular use case.