Database Reference
In-Depth Information
The ConfigSlurper is configured to load some settings as default values and other
settings from the “dev” section of the config file. We would only need to change 'dev' to
'prod' when setting up the slurper to load the other settings instead.
When a setting, such as server, is provided both through the config file and the com-
mand line, the command line setting takes precedence. We implement this feature
using the ?: operator, also known as the “Elvis” operator (tilt your head to the left). This
operator is often used to provide default values. If the expression on the left has meaning
and could be useful, then it will evaluate to a groovy true value (see Section 9.4.11) and
be used, otherwise, it must be something like a null or an empty string, so the value on
the right is used instead. In our case, when the option is not provided on the command
line, its value is a null, so the config file setting is used.
9.5.12 Log ging
We have written our scripts in this chapter to blast through their jobs without leaving
much of a trace. When we put code into production, we will want to add logging capa-
bilities. There are many logging methods available. This recipe demonstrates logging
with the java.util.logging package. This package is powerful enough to set up a network
of different Logger objects. Loggers are automatically placed in parent/child relation-
ships determined by their dot-separated names. Logging calls of different severity levels
are made against these objects. Each logger has a severity threshold, and if the log event's
level matches (or exceeds) this value, the logger passes the event on to its collection
of one or more handler objects. handlers check their own severity thresholds, apply
formatting to log messages, and forward them to various targets, such as files, sockets,
consoles, and memory buffers. Thus, a single log event can be sent to multiple places in
multiple formats.
import java.util.logging.*
log = Logger.getLogger("")
log.handlers.each{ println "${it.class}: ${it.level}"}
log.level = Level.ALL
fh = new FileHandler("essScripts.log")
fh.level = Level.FINE
fh.formatter = new SimpleFormatter()
log.addHandler(fh)
fh2 = new FileHandler("everything.log", true)
fh2.level = Level.ALL
log.addHandler(fh2)
log.finest("Could I _BE_ any more fine?!")
log.finer("I'm the judge here, and I say that's gonna cost ya.")
log.fine("I'm a logging event, and I'm fine with that.")
log.config("I am configuring this application.")
log.info("Pardon me, user, here's a little FYI.")
log.warning("Something happened you might want to know about.")
log.severe("Captain, there's a problem with the warp core!")
This code is simple enough to use the nameless “root logger” instead of making a
child logger. We demonstrate that the root logger automatically has an associated
Consolehandler with a severity threshold of InFo. We set up the first file handler with
a different Formatter than the default xmLFormatter and have it overwrite its target file
if it already exists. The second file handler gets a different threshold, keeps the default
