(Quick Reference)
4.1 Basic Configuration - Reference Documentation
Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith, Lari Hotari
Version: 2.3.8
4.1 Basic Configuration
For general configuration Grails provides two files:
grails-app/conf/BuildConfig.groovy
grails-app/conf/Config.groovy
Both of them use Groovy's
ConfigSlurper syntax. The first,
BuildConfig.groovy
, is for settings that are used when running Grails commands, such as
compile
,
doc
, etc. The second file,
Config.groovy
, is for settings that are used when your application is running. This means that
Config.groovy
is packaged with your application, but
BuildConfig.groovy
is not. Don't worry if you're not clear on the distinction: the guide will tell you which file to put a particular setting in.
The most basic syntax is similar to that of Java properties files with dot notation on the left-hand side:
Note that the value is a Groovy string literal! Those quotes around 'world' are important. In fact, this highlights one of the advantages of the ConfigSlurper syntax over properties files: the property values can be any valid Groovy type, such as strings, integers, or arbitrary objects!
Things become more interesting when you have multiple settings with the same base. For example, you could have the two settings
foo.bar.hello = "world"
foo.bar.good = "bye"
both of which have the same base:
foo.bar
. The above syntax works but it's quite repetitive and verbose. You can remove some of that verbosity by nesting properties at the dots:
foo {
bar {
hello = "world"
good = "bye"
}
}
or by only partially nesting them:
foo {
bar.hello = "world"
bar.good = "bye"
}
However, you can't nest after using the dot notation. In other words, this
won't work:
// Won't work!
foo.bar {
hello = "world"
good = "bye"
}
Within both
BuildConfig.groovy
and
Config.groovy
you can access several implicit variables from configuration values:
Variable | Description |
---|
userHome | Location of the home directory for the account that is running the Grails application. |
grailsHome | Location of the directory where you installed Grails. If the GRAILS_HOME environment variable is set, it is used. |
appName | The application name as it appears in application.properties. |
appVersion | The application version as it appears in application.properties. |
For example:
my.tmp.dir = "${userHome}/.grails/tmp"
In addition,
BuildConfig.groovy
has
Variable | Description |
---|
grailsVersion | The version of Grails used to build the project. |
grailsSettings | An object containing various build related settings, such as baseDir . It's of type BuildSettings . |
and
Config.groovy
has
Those are the basics of adding settings to the configuration file, but how do you access those settings from your own application? That depends on which config you want to read.
The settings in
BuildConfig.groovy
are only available from
command scripts and can be accessed via the
grailsSettings.config
property like so:
target(default: "Example command") {
def maxIterations = grailsSettings.config.myapp.iterations.max
…
}
If you want to read runtime configuration settings, i.e. those defined in
Config.groovy
, use the
grailsApplication
object, which is available as a variable in controllers and tag libraries:
class MyController {
def hello() {
def recipient = grailsApplication.config.foo.bar.hello render "Hello ${recipient}"
}
}
and can be easily injected into services and other Grails artifacts:
class MyService {
def grailsApplication String greeting() {
def recipient = grailsApplication.config.foo.bar.hello
return "Hello ${recipient}"
}
}
As you can see, when accessing configuration settings you use the same dot notation as when you define them.
4.1.1 Built in options
Grails has a set of core settings that are worth knowing about. Their defaults are suitable for most projects, but it's important to understand what they do because you may need one or more of them later.
Build settings
Let's start with some important build settings. Although Grails requires JDK 6 when developing your applications, it is possible to deploy those applications to JDK 5 containers. Simply set the following in
BuildConfig.groovy
:
grails.project.source.level = "1.5"
grails.project.target.level = "1.5"
Note that source and target levels are different to the standard public version of JDKs, so JDK 5 -> 1.5, JDK 6 -> 1.6, and JDK 7 -> 1.7.
In addition, Grails supports Servlet versions 2.5 and above but defaults to 2.5. If you wish to use newer features of the Servlet API (such as 3.0 async support) you should configure the
grails.servlet.version
setting appropriately:
grails.servlet.version = "3.0"
Runtime settings
On the runtime front, i.e.
Config.groovy
, there are quite a few more core settings:
grails.config.locations
- The location of properties files or addition Grails Config files that should be merged with main configuration. See the section on externalised config.
grails.enable.native2ascii
- Set this to false if you do not require native2ascii conversion of Grails i18n properties files (default: true).
grails.views.default.codec
- Sets the default encoding regime for GSPs - can be one of 'none', 'html', or 'base64' (default: 'none'). To reduce risk of XSS attacks, set this to 'html'.
grails.views.gsp.encoding
- The file encoding used for GSP source files (default: 'utf-8').
grails.mime.file.extensions
- Whether to use the file extension to dictate the mime type in Content Negotiation (default: true).
grails.mime.types
- A map of supported mime types used for Content Negotiation.
grails.serverURL
- A string specifying the server URL portion of absolute links, including server name e.g. grails.serverURL="http://my.yourportal.com". See createLink. Also used by redirects.
grails.views.gsp.sitemesh.preprocess
- Determines whether SiteMesh preprocessing happens. Disabling this slows down page rendering, but if you need SiteMesh to parse the generated HTML from a GSP view then disabling it is the right option. Don't worry if you don't understand this advanced property: leave it set to true.
grails.reload.excludes
and grails.reload.includes
- Configuring these directives determines the reload behavior for project specific source files. Each directive takes a list of strings that are the class names for project source files that should be excluded from reloading behavior or included accordingly when running the application in development with the run-app
command. If the grails.reload.includes
directive is configured, then only the classes in that list will be reloaded.
War generation
grails.project.war.file
- Sets the name and location of the WAR file generated by the war command
grails.war.dependencies
- A closure containing Ant builder syntax or a list of JAR filenames. Lets you customise what libaries are included in the WAR file.
grails.war.copyToWebApp
- A closure containing Ant builder syntax that is legal inside an Ant copy, for example "fileset()". Lets you control what gets included in the WAR file from the "web-app" directory.
grails.war.resources
- A closure containing Ant builder syntax. Allows the application to do any other work before building the final WAR file
For more information on using these options, see the section on
deployment
4.1.2 Logging
The Basics
Grails uses its common configuration mechanism to provide the settings for the underlying
Log4j log system, so all you have to do is add a
log4j
setting to the file
grails-app/conf/Config.groovy
.
So what does this
log4j
setting look like? Here's a basic example:
log4j = {
error 'org.codehaus.groovy.grails.web.servlet', // controllers
'org.codehaus.groovy.grails.web.pages' // GSP warn 'org.apache.catalina'
}
This says that for loggers whose name starts with 'org.codehaus.groovy.grails.web.servlet' or 'org.codehaus.groovy.grails.web.pages', only messages logged at 'error' level and above will be shown. Loggers with names starting with 'org.apache.catalina' logger only show messages at the 'warn' level and above. What does that mean? First of all, you have to understand how levels work.
Logging levels
There are several standard logging levels, which are listed here in order of descending priority:
- off
- fatal
- error
- warn
- info
- debug
- trace
- all
When you log a message, you implicitly give that message a level. For example, the method
log.error(msg)
will log a message at the 'error' level. Likewise,
log.debug(msg)
will log it at 'debug'. Each of the above levels apart from 'off' and 'all' have a corresponding log method of the same name.
The logging system uses that
message level combined with the configuration for the logger (see next section) to determine whether the message gets written out. For example, if you have an 'org.example.domain' logger configured like so:
warn 'org.example.domain'
then messages with a level of 'warn', 'error', or 'fatal' will be written out. Messages at other levels will be ignored.
Before we go on to loggers, a quick note about those 'off' and 'all' levels. These are special in that they can only be used in the configuration; you can't log messages at these levels. So if you configure a logger with a level of 'off', then no messages will be written out. A level of 'all' means that you will see all messages. Simple.
Loggers
Loggers are fundamental to the logging system, but they are a source of some confusion. For a start, what are they? Are they shared? How do you configure them?
A logger is the object you log messages to, so in the call
log.debug(msg)
,
log
is a logger instance (of type
Log). These loggers are cached and uniquely identified by name, so if two separate classes use loggers with the same name, those loggers are actually the same instance.
There are two main ways to get hold of a logger:
- use the
log
instance injected into artifacts such as domain classes, controllers and services;
- use the Commons Logging API directly.
If you use the dynamic
log
property, then the name of the logger is 'grails.app.<type>.<className>', where
type
is the type of the artifact, for example 'controllers' or 'services', and
className
is the fully qualified name of the artifact. For example, if you have this service:
package org.exampleclass MyService {
…
}
then the name of the logger will be 'grails.app.services.org.example.MyService'.
For other classes, the typical approach is to store a logger based on the class name in a constant static field:
package org.otherimport org.apache.commons.logging.LogFactoryclass MyClass {
private static final log = LogFactory.getLog(this)
…
}
This will create a logger with the name 'org.other.MyClass' - note the lack of a 'grails.app.' prefix since the class isn't an artifact. You can also pass a name to the
getLog()
method, such as "myLogger", but this is less common because the logging system treats names with dots ('.') in a special way.
Configuring loggers
You have already seen how to configure loggers in Grails:
log4j = {
error 'org.codehaus.groovy.grails.web.servlet'
}
This example configures loggers with names starting with 'org.codehaus.groovy.grails.web.servlet' to ignore any messages sent to them at a level of 'warn' or lower. But is there a logger with this name in the application? No. So why have a configuration for it? Because the above rule applies to any logger whose name
begins with 'org.codehaus.groovy.grails.web.servlet.' as well. For example, the rule applies to both the
org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet
class and the
org.codehaus.groovy.grails.web.servlet.mvc.GrailsWebRequest
one.
In other words, loggers are hierarchical. This makes configuring them by package much simpler than it would otherwise be.
The most common things that you will want to capture log output from are your controllers, services, and other artifacts. Use the convention mentioned earlier to do that:
grails.app.<artifactType>.<className> . In particular the class name must be fully qualifed, i.e. with the package if there is one:
log4j = {
// Set level for all application artifacts
info "grails.app" // Set for a specific controller in the default package
debug "grails.app.controllers.YourController" // Set for a specific domain class
debug "grails.app.domain.org.example.Book" // Set for all taglibs
info "grails.app.taglib"
}
The standard artifact names used in the logging configuration are:
conf
- For anything under grails-app/conf
such as BootStrap.groovy
(but excluding filters)
filters
- For filters
taglib
- For tag libraries
services
- For service classes
controllers
- For controllers
domain
- For domain entities
Grails itself generates plenty of logging information and it can sometimes be helpful to see that. Here are some useful loggers from Grails internals that you can use, especially when tracking down problems with your application:
org.codehaus.groovy.grails.commons
- Core artifact information such as class loading etc.
org.codehaus.groovy.grails.web
- Grails web request processing
org.codehaus.groovy.grails.web.mapping
- URL mapping debugging
org.codehaus.groovy.grails.plugins
- Log plugin activity
grails.spring
- See what Spring beans Grails and plugins are defining
org.springframework
- See what Spring is doing
org.hibernate
- See what Hibernate is doing
So far, we've only looked at explicit configuration of loggers. But what about all those loggers that
don't have an explicit configuration? Are they simply ignored? The answer lies with the root logger.
The Root Logger
All logger objects inherit their configuration from the root logger, so if no explicit configuration is provided for a given logger, then any messages that go to that logger are subject to the rules defined for the root logger. In other words, the root logger provides the default configuration for the logging system.
Grails automatically configures the root logger to only handle messages at 'error' level and above, and all the messages are directed to the console (stdout for those with a C background). You can customise this behaviour by specifying a 'root' section in your logging configuration like so:
log4j = {
root {
info()
}
…
}
The above example configures the root logger to log messages at 'info' level and above to the default console appender. You can also configure the root logger to log to one or more named appenders (which we'll talk more about shortly):
log4j = {
appenders {
file name:'file', file:'/var/logs/mylog.log'
}
root {
debug 'stdout', 'file'
}
}
In the above example, the root logger will log to two appenders - the default 'stdout' (console) appender and a custom 'file' appender.
For power users there is an alternative syntax for configuring the root logger: the root
org.apache.log4j.Logger
instance is passed as an argument to the log4j closure. This lets you work with the logger directly:
log4j = { root ->
root.level = org.apache.log4j.Level.DEBUG
…
}
For more information on what you can do with this
Logger
instance, refer to the Log4j API documentation.
Those are the basics of logging pretty well covered and they are sufficient if you're happy to only send log messages to the console. But what if you want to send them to a file? How do you make sure that messages from a particular logger go to a file but not the console? These questions and more will be answered as we look into appenders.
Appenders
Loggers are a useful mechanism for filtering messages, but they don't physically write the messages anywhere. That's the job of the appender, of which there are various types. For example, there is the default one that writes messages to the console, another that writes them to a file, and several others. You can even create your own appender implementations!
This diagram shows how they fit into the logging pipeline:

As you can see, a single logger may have several appenders attached to it. In a standard Grails configuration, the console appender named 'stdout' is attached to all loggers through the default root logger configuration. But that's the only one. Adding more appenders can be done within an 'appenders' block:
log4j = {
appenders {
rollingFile name: "myAppender",
maxFileSize: 1024,
file: "/tmp/logs/myApp.log"
}
}
The following appenders are available by default:
Each named argument passed to an appender maps to a property of the underlying
Appender implementation. So the previous example sets the
name
,
maxFileSize
and
file
properties of the
RollingFileAppender
instance.
You can have as many appenders as you like - just make sure that they all have unique names. You can even have multiple instances of the same appender type, for example several file appenders that log to different files.
If you prefer to create the appender programmatically or if you want to use an appender implementation that's not available in the above syntax, simply declare an
appender
entry with an instance of the appender you want:
import org.apache.log4j.*log4j = {
appenders {
appender new RollingFileAppender(
name: "myAppender",
maxFileSize: 1024,
file: "/tmp/logs/myApp.log")
}
}
This approach can be used to configure
JMSAppender
,
SocketAppender
,
SMTPAppender
, and more.
Once you have declared your extra appenders, you can attach them to specific loggers by passing the name as a key to one of the log level methods from the previous section:
error myAppender: "grails.app.controllers.BookController"
This will ensure that the 'grails.app.controllers.BookController' logger sends log messages to 'myAppender' as well as any appenders configured for the root logger. To add more than one appender to the logger, then add them to the same level declaration:
error myAppender: "grails.app.controllers.BookController",
myFileAppender: ["grails.app.controllers.BookController",
"grails.app.services.BookService"],
rollingFile: "grails.app.controllers.BookController"
The above example also shows how you can configure more than one logger at a time for a given appender (
myFileAppender
) by using a list.
Be aware that you can only configure a single level for a logger, so if you tried this code:
error myAppender: "grails.app.controllers.BookController"
debug myFileAppender: "grails.app.controllers.BookController"
fatal rollingFile: "grails.app.controllers.BookController"
you'd find that only 'fatal' level messages get logged for 'grails.app.controllers.BookController'. That's because the last level declared for a given logger wins. What you probably want to do is limit what level of messages an appender writes.
An appender that is attached to a logger configured with the 'all' level will generate a lot of logging information. That may be fine in a file, but it makes working at the console difficult. So we configure the console appender to only write out messages at 'info' level or above:
log4j = {
appenders {
console name: "stdout", threshold: org.apache.log4j.Level.INFO
}
}
The key here is the
threshold
argument which determines the cut-off for log messages. This argument is available for all appenders, but do note that you currently have to specify a
Level
instance - a string such as "info" will not work.
Custom Layouts
By default the Log4j DSL assumes that you want to use a
PatternLayout. However, there are other layouts available including:
xml
- Create an XML log file
html
- Creates an HTML log file
simple
- A simple textual log
pattern
- A Pattern layout
You can specify custom patterns to an appender using the
layout
setting:
log4j = {
appenders {
console name: "customAppender",
layout: pattern(conversionPattern: "%c{2} %m%n")
}
}
This also works for the built-in appender "stdout", which logs to the console:
log4j = {
appenders {
console name: "stdout",
layout: pattern(conversionPattern: "%c{2} %m%n")
}
}
Environment-specific configuration
Since the logging configuration is inside
Config.groovy
, you can put it inside an environment-specific block. However, there is a problem with this approach: you have to provide the full logging configuration each time you define the
log4j
setting. In other words, you cannot selectively override parts of the configuration - it's all or nothing.
To get around this, the logging DSL provides its own environment blocks that you can put anywhere in the configuration:
log4j = {
appenders {
console name: "stdout",
layout: pattern(conversionPattern: "%c{2} %m%n") environments {
production {
rollingFile name: "myAppender", maxFileSize: 1024,
file: "/tmp/logs/myApp.log"
}
}
} root {
//…
} // other shared config
info "grails.app.controller" environments {
production {
// Override previous setting for 'grails.app.controller'
error "grails.app.controllers"
}
}
}
The one place you can't put an environment block is
inside the
root
definition, but you can put the
root
definition inside an environment block.
Full stacktraces
When exceptions occur, there can be an awful lot of noise in the stacktrace from Java and Groovy internals. Grails filters these typically irrelevant details and restricts traces to non-core Grails/Groovy class packages.
When this happens, the full trace is always logged to the
StackTrace
logger, which by default writes its output to a file called
stacktrace.log
. As with other loggers though, you can change its behaviour in the configuration. For example if you prefer full stack traces to go to the console, add this entry:
error stdout: "StackTrace"
This won't stop Grails from attempting to create the stacktrace.log file - it just redirects where stack traces are written to. An alternative approach is to change the location of the 'stacktrace' appender's file:
log4j = {
appenders {
rollingFile name: "stacktrace", maxFileSize: 1024,
file: "/var/tmp/logs/myApp-stacktrace.log"
}
}
or, if you don't want to the 'stacktrace' appender at all, configure it as a 'null' appender:
log4j = {
appenders {
'null' name: "stacktrace"
}
}
You can of course combine this with attaching the 'stdout' appender to the 'StackTrace' logger if you want all the output in the console.
Finally, you can completely disable stacktrace filtering by setting the
grails.full.stacktrace
VM property to
true
:
grails -Dgrails.full.stacktrace=true run-app
Masking Request Parameters From Stacktrace Logs
When Grails logs a stacktrace, the log message may include the names and values of all of the request parameters for the current request. To mask out the values of secure request parameters, specify the parameter names in the
grails.exceptionresolver.params.exclude
config property:
grails.exceptionresolver.params.exclude = ['password', 'creditCard']
Request parameter logging may be turned off altogether by setting the
grails.exceptionresolver.logRequestParameters
config property to
false
. The default value is
true
when the application is running in DEVELOPMENT mode and
false
for all other modes.
grails.exceptionresolver.logRequestParameters=false
Logger inheritance
Earlier, we mentioned that all loggers inherit from the root logger and that loggers are hierarchical based on '.'-separated terms. What this means is that unless you override a parent setting, a logger retains the level and the appenders configured for that parent. So with this configuration:
log4j = {
appenders {
file name:'file', file:'/var/logs/mylog.log'
}
root {
debug 'stdout', 'file'
}
}
all loggers in the application will have a level of 'debug' and will log to both the 'stdout' and 'file' appenders. What if you only want to log to 'stdout' for a particular logger? Change the 'additivity' for a logger in that case.
Additivity simply determines whether a logger inherits the configuration from its parent. If additivity is false, then its not inherited. The default for all loggers is true, i.e. they inherit the configuration. So how do you change this setting? Here's an example:
log4j = {
appenders {
…
}
root {
…
} info additivity: false
stdout: ["grails.app.controllers.BookController",
"grails.app.services.BookService"]
}
So when you specify a log level, add an 'additivity' named argument. Note that you when you specify the additivity, you must configure the loggers for a named appender. The following syntax will
not work:
info additivity: false, ["grails.app.controllers.BookController",
"grails.app.services.BookService"]
Customizing stack trace printing and filtering
Stacktraces in general and those generated when using Groovy in particular are quite verbose and contain many stack frames that aren't interesting when diagnosing problems. So Grails uses a implementation of the
org.codehaus.groovy.grails.exceptions.StackTraceFilterer
interface to filter out irrelevant stack frames. To customize the approach used for filtering, implement that interface in a class in src/groovy or src/java and register it in
Config.groovy
:
grails.logging.stackTraceFiltererClass =
'com.yourcompany.yourapp.MyStackTraceFilterer'
In addition, Grails customizes the display of the filtered stacktrace to make the information more readable. To customize this, implement the
org.codehaus.groovy.grails.exceptions.StackTracePrinter
interface in a class in src/groovy or src/java and register it in
Config.groovy
:
grails.logging.stackTracePrinterClass =
'com.yourcompany.yourapp.MyStackTracePrinter'
Finally, to render error information in the error GSP, an HTML-generating printer implementation is needed. The default implementation is
org.codehaus.groovy.grails.web.errors.ErrorsViewStackTracePrinter
and it's registered as a Spring bean. To use your own implementation, either implement the
org.codehaus.groovy.grails.exceptions.StackTraceFilterer
directly or subclass
ErrorsViewStackTracePrinter
and register it in
grails-app/conf/spring/resources.groovy
as:
import com.yourcompany.yourapp.MyErrorsViewStackTracePrinterbeans = { errorsViewStackTracePrinter(MyErrorsViewStackTracePrinter,
ref('grailsResourceLocator'))
}
Alternative logging libraries
By default, Grails uses Log4J to do its logging. For most people this is absolutely fine, and many users don't even care what logging library is used. But if you're not one of those and want to use an alternative, such as the
JDK logging package or
logback, you can do so by simply excluding a couple of dependencies from the global set and adding your own:
grails.project.dependency.resolution = {
inherits("global") {
excludes "grails-plugin-logging", "log4j"
}
…
dependencies {
runtime "ch.qos.logback:logback-core:0.9.29"
…
}
…
}
If you do this, you will get unfiltered, standard Java stacktraces in your log files and you won't be able to use the logging configuration DSL that's just been described. Instead, you will have to use the standard configuration mechanism for the library you choose.
4.1.3 GORM
Grails provides the following GORM configuration options:
grails.gorm.failOnError
- If set to true
, causes the save()
method on domain classes to throw a grails.validation.ValidationException
if validation fails during a save. This option may also be assigned a list of Strings representing package names. If the value is a list of Strings then the failOnError behavior will only be applied to domain classes in those packages (including sub-packages). See the save method docs for more information.
For example, to enable failOnError for all domain classes:
grails.gorm.failOnError=true
and to enable failOnError for domain classes by package:
grails.gorm.failOnError = ['com.companyname.somepackage',
'com.companyname.someotherpackage']
grails.gorm.autoFlush
= If set to true
, causes the merge, save and delete methods to flush the session, replacing the need to explicitly flush using save(flush: true)
.