To define endpoints in our Ratpack application we can use optional path tokens. This means that a part of the request can have a value or not, but we can a have single path definition that will match. Normally we define a variable path token with a colon (
:) followed by a variable name. To make this token optional we follow it with a question mark (
?). This tells Ratpack that the token can have a value or not. In our handler we now need to take into account that the path token is optional as well.
Ratpack has very useful methods to apply application configuration in our application. We can read configuration properties from files in different formats, like JSON, YAML and Java properties, and the files can be read from different locations, like class path or file system. We can also set configuration properties via Java system properties on the command line or use environment variables.
We use the
ratpack.config.ConfigData class with the static
of method to add configuration properties to our application. We provide a lambda expression or Groovy closure to the
of method to build our configuration. Here we specify external files, locations and other configuration options we want to include for our application. If the same configuration property is defined in multiple configuration sources Ratpack will apply the value that is last discovered. This way we can for example provide default values and allow them to be overridden with environment variables if we apply the environment variables last.
To use the values that are gathered we use the
get method of the
ConfigData instance. We can apply the configuration properties to the properties of a configuration class that is then automatically instantiated. We add this to the registry so we can use the configuration properties further down in our application.
To define project properties outside the Gradle build file, we can define them in a file
gradle.properties in our project directory. If we want to define property values that are used by all Gradle builds we can create a file
gradle.properties in the
GRADLE_USER_HOME directory. By default this is in the
In this blog post we see how to update the Grails version of our application for a Grails 3 application. In previous Grails versions there was a special command to upgrade, but with Grails 3 it is much simpler. To update an application to a newer version in the Grails 3.0.x range we only have to change the value of the property
grailsVersion in the file
After we have changed the value we run the
compile tasks so all dependencies are up-to-date.
Written with Grails 3.0.8.
Since Grails 3 the logging configuration is in a separate file. Before Grails 3 we could specify the logging configuration in
grails-app/conf/Config.groovy, since Grails 3 it is in the file
grails-app/conf/logback.groovy. We also notice that since Grails 3 the default logging framework implementation is Logback. We can define a different Logback configuration file with the environment configuration property
logging.config. We can set this property in
grails-app/conf/application.yml, as Java system property (
-Dlogging.config=<location>) or environment variable (
LOGGING_CONFIG). Actually all rules for external configuration of Spring Boot apply for the configuration property
With Grails 3 we get the Spring Boot mechanism for loading external configuration files. The default base name for configuration files is
application. Grails creates for example the file
grails-app/conf/application.yml to store configuration values if we use the
create-app command. To change the base name from
application to something else we must specify a value for the Java system property
A Grails 3 application uses the same mechanism to load external configuration files as a Spring Boot application. This means the default locations are the root directory or
config/ directory in the class path and on the file system. If we want to specify a new directory to search for configuration files or specify the configuration files explicitly we can use the Java system property
In Grails we can use the
list-plugins command to get a list of all available plugins. The list returns only the plugins that are available for the Grails version we are using. So if we invoke this command in Grails 3 we get a different list than a Grails 2.x version. To get more detailed information, like website, source code URL and dependency definition we use the
Creating and working with mocks and stubs in Spock is easy. If we want to interact with our mocks and stubs we have several options to return values. One of the options is the triple right shift operator
>>>. With this operator we can define different return values for multiple invocations of the stubbed or mocked method. For example we can use the
>>> operator followed by a list of return values
['abc', 'def', 'ghi']. On the first invocation
abc is return, the second invocation returns
def and the third (and following) invocation(s) return
A very useful feature in Groovy is the use of named arguments. Instead of a list of arguments for a method or constructor we can use a
Map argument. If the argument is the first in the list of arguments then Groovy allows use to use named arguments when we invoke the method or constructor. This means all key/value arguments are gathered together and assigned to the
Map argument. Inside our method or constructor we can then access the
Map argument and get the values for the keys. This leads to better readable code and that is very useful. IntelliJ IDEA has a Groovy intention to turn method parameters into a
Map parameter for named arguments with a few mouse clicks.