We
can introduce Groovy into our projects at grassroots level. In this post we
learn how to use Groovy configuration scripts instead of Java properties files
to configure our application. Groovy has the ConfigSlurper class.
We use a ConfigSlurper
object
to read in a Groovy script. This scripts contains a tree of objects with
different values. These values can be Java types, which is not possible in a
plain properties file. We can even add code to the script file.
The ConfigSlurper
is
capable of supporting different environments. We pass the environment to the
constructor. This way we can set a default value for a property and override it
for a specific environment in the same configuration file.
We start with a simple Java application to read in a Groovy configuration script:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27 |
package
com.mrhaki.sample.config; import
java.net.*; import
java.util.*; import
groovy.util.*; public
class
JavaConfig
{ public
static
void
main(String[]
args) throws
MalformedURLException
{ //
Read in 'config.groovy' for the development environment. ConfigObject
conf = new
ConfigSlurper( "development" ).parse( new
File( "config.groovy" ).toURI().toURL()); //
Read in 'mail.groovy'. final
ConfigObject
mailConf = new
ConfigSlurper().parse( new
File( "mail.groovy" ).toURI().toURL()); //
Merge both configurations into one. conf
= (ConfigObject) conf.merge(mailConf); //
Flatten configuration for easy access keys with dotted
notation. final
Map
config = conf.flatten(); assert
"1.0" .equals(config.get( "app.version" )); assert
new
Integer( 20 ).equals(config.get( "app.setting2" )); assert
new
Date().after((Date)
config.get( "app.date" )); assert
config.get( "app.active" ); assert
"http://localhost" .equals(config.get( "server.URL" )); assert
"smtpservername" .equals(config.get( "mail.smtp.host" )); } } |
It
is not difficult to invoke the ConfigSlurper
from
our Java code. We must make sure the Groovy libraries are in the classpath when
we run the application ($GROOVY_HOME/embeddable/groovy-all-<version>.jar
).
Next we make the configuration script config.groovy
:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33 |
//
We can group settings. //
The following settings are created: //
app.version, app.setting1, app.setting2, app.setting3, app.date,
app.active app
{ version
= "1.0" //
We can write code to set up settings. [ 1 , 2 , 3 ]. each
{ this. "setting${it}"
=
it * 10 } //
We can use Java objects date
= new
Date() active
= true } server.URL
= 'http://default' //
Environment specific settings override settings with the //
same name. environments
{ development
{ server.URL
= 'http://localhost' } test
{ server.URL
= 'http://test:9080' } integrationtest
{ server.URL
= 'http://integrationtest/url' } production
{ server.URL
= 'http://prod/url' } } |
And
we make the configuration script mail.groovy
which
is merged together with config.groovy
:
1
2
3 |
//
Classic way of specifying properties without grouping, //
but we can use Java objects instead of only strings. mail.smtp.host
= "smtpservername" mail.smtp.ssl
= true |
We
are ready to run our Java application - $
java -ea com.mrhaki.sample.config.JavaConfig
- and all
works fine. We shouldn't get any assertion errors. In a real world application
we can make a class to read in the Groovy configuration files. Other classes use
this class to get the values of the settings. All in plain old Java, but we
create the settings and their values in a Groovy way.