4.1 Basic Configuration 3.3.2

(Quick Reference) # 4.1 Basic Configuration Version: 3.3.2 ## Table of Contents ## 4.1 Basic Configuration Configuration in Grails is generally split across 2 areas: build configuration and runtime configuration. Build configuration is generally done via Gradle and the `build.gradle` file. Runtime configuration is by default specified in YAML in the `grails-app/conf/application.yml` file. If you prefer to use Grails 2.0-style Groovy configuration then you can create an additional `grails-app/conf/application.groovy` file to specify configuration using Groovy’s ConfigSlurper syntax. For Groovy configuration the following variables are available to the configuration script:
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 build.gradle.
appVersion | The application version as it appears in build.gradle.
For example:
    my.tmp.dir = "${userHome}/.grails/tmp"
If you want to read runtime configuration settings, i.e. those defined in `application.yml`, use the grailsApplication object, which is available as a variable in controllers and tag libraries:
    class MyController {
        def hello() {
            def recipient = grailsApplication.config.getProperty('foo.bar.hello')

            render "Hello ${recipient}"
        }
    }
The `config` property of the `grailsApplication` object is an instance of the Config interface and provides a number of useful methods to read the configuration of the application. In particular, the `getProperty` method (seen above) is useful for efficiently retrieving configuration properties, while specifying the property type (the default type is String) and/or providing a default fallback value.
    class MyController {

        def hello(Recipient recipient) {
            //Retrieve Integer property 'foo.bar.max.hellos', otherwise use value of 5
            def max = grailsApplication.config.getProperty('foo.bar.max.hellos', Integer, 5)

            //Retrieve property 'foo.bar.greeting' without specifying type (default is String), otherwise use value "Hello"
            def greeting = grailsApplication.config.getProperty('foo.bar.greeting', "Hello")

            def message = (recipient.receivedHelloCount >= max) ?
              "Sorry, you've been greeted the max number of times" :  "${greeting}, ${recipient}"
            }

            render message
        }
    }
Notice that the `Config` instance is a merged configuration based on Spring’s PropertySource concept and reads configuration from the environment, system properties and the local application configuration merging them into a single object. `GrailsApplication` can be easily injected into services and other Grails artifacts:
    import grails.core.*

    class MyService {
        GrailsApplication grailsApplication

        String greeting() {
            def recipient = grailsApplication.config.getProperty('foo.bar.hello')
            return "Hello ${recipient}"
        }
    }
Finally, you can also use Spring’s Value annotation to inject configuration values:
    import org.springframework.beans.factory.annotation.*

    class MyController {
        @Value('${foo.bar.hello}')
        String recipient

        def hello() {
            render "Hello ${recipient}"
        }
    }
| In Groovy code you must use single quotes around the string for the value of the `Value` annotation otherwise it is interpreted as a GString not a Spring expression.
As you can see, when accessing configuration settings you use the same dot notation as when you define them. ## 4.1.1 Options for the YML format Config `application.yml` was introduced in Grails 3.0 for an alternative format for the configuration tasks. ### Using system properties / command line arguments Suppose you are using the `JDBC_CONNECTION_STRING` command line argument and you want to access the same in the yml file then it can be done in the following manner:
    production:
        dataSource:
            url: '${JDBC_CONNECTION_STRING}'
Similarly system arguments can be accessed. You will need to have this in `build.gradle` to modify the `bootRun` target if `grails run-app` is used to start the application
    bootRun {
        systemProperties = System.properties
    }
For testing the following will need to change the `test` task as follows
    test {
        systemProperties = System.properties
    }
## 4.1.2 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. ### Runtime settings On the runtime front, i.e. `grails-app/conf/application.yml`, there are quite a few more core settings: `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. ## 4.1.3 Logging By default logging in Grails 3.0 is handled by the Logback logging framework and can be configured with the `grails-app/conf/logback.groovy` file.
| If you prefer XML you can replace the `logback.groovy` file with a `logback.xml` file instead.
For more information on configuring logging refer to the Logback documentation on the subject. ## 4.1.3.1 Logger Names Grails artifacts (controllers, services …​) get injected a `log` property automatically. Prior to Grails 3.3.0, the name of the logger for Grails Artifact followed the convention `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. Grails 3.3.x simplifies logger names as illustrated in the next table:
Class Name | Package Name | Location | Annotated with `@Slf4j` | Logger Name (Grails 3.3.x or higher) | Logger Name (Grails 3.2.x or lower)
`BookController.groovy` | `com.company` | `grails-app/controllers/com/company` | NO | `com.company.BookController` | `grails.app.controllers.com.company.BookController`
`BookController.groovy` | `com.company` | `grails-app/controllers/com/company` | YES | `com.company.BookController` | `com.company.BookController`
`BookService.groovy` | `com.company` | `grails-app/services/com/company` | NO | `com.company.BookService` | `grails.app.services.com.company.BookService`
`BookService.groovy` | `com.company` | `grails-app/services/com/company` | YES | `com.company.BookService` | `com.company.BookService`
`BookDetail.groovy` | `com.company` | `src/main/groovy/com/company` | YES | `com.company.BookDetail` | `com.company.BookDetail`
## 4.1.3.2 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-app/conf/application.yaml
    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 environments. grails-app/conf/application.yaml
    grails:
        exceptionresolver:
            logRequestParameters: false
## 4.1.3.3 External Configuration File If you set the configuration property `logging.config`, you can instruct `Logback` to use an external configuration file. grails-app/conf/application.yml
    logging:
        config: /Users/me/config/logback.groovy
Alternatively, you can supply the configuration file location with a system property: `$ ./gradlew -Dlogging.config=/Users/me/config/logback.groovy bootRun` Or, you could use an environment variable:
    $ export LOGGING_CONFIG=/Users/me/config/logback.groovy
    $ ./gradlew bootRun
## 4.1.4 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)`. ## 4.1.5 Configuring an HTTP proxy To setup Grails to use an HTTP proxy there are two steps. Firstly you need to configure the `grails` CLI to be aware of the proxy if you wish to use it to create applications and so on. This can be done using the `GRAILS_OPTS` environment variable, for example on Unix systems:
    export GRAILS_OPTS="-Dhttps.proxyHost=127.0.0.1 -Dhttps.proxyPort=3128 -Dhttp.proxyUser=test -Dhttp.proxyPassword=test"
| The default profile repository is resolved over HTTPS so `https.proxyPort` and `https.proxyUser` are used, however the username and password are specified with `http.proxyUser` and `http.proxyPassword`
For Windows systems the environment variable can be configured under `My Computer/Advanced/Environment Variables`. With this configuration in place the `grails` command can connect and authenticate via a proxy. Secondly, since Grails uses Gradle as the build system, you need to configure Gradle to authenticate via the proxy. For instructions on how to do this see the Gradle user guide section on the topic. | Quick Reference (hide)