When we define a Ratpack application we can set a server port in the server configuration code. When we do not define the port number in our code and use the default server configuration we can also set the server port with the environment variables PORT or RATPACK_PORT.
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 USER_HOME/.gradle directory.
When we have multiple Options and only want to do something when they’re all set.
In this example we have a property file with multiple configurations for one thing. A host and a port, we only want to use them if they’re both set.
|
1 2 3 4 5 6 |
//The individual properties val stubHost: Option[String] = Some("host") val stubPort: Option[Int] = Some(8090) //The case class I'll turn them into case class StubConfig(host: String, port: Int) |
We can chain them using map and flatMap.
|
1 2 3 4 5 6 7 |
def chainConfigs(stubHost: Option[String], stubPort: Option[Int]): Option[StubConfig] = { stubHost.flatMap { host: String => stubPort.map { port: Int => StubConfig(host, port) } } } |
Then the following statements are all true.
|
1 2 3 4 |
chainConfigs(Some("host"), Some(8090)) == Some(StubConfig("host", 8090)) chainConfigs(Some("host"), None) == None chainConfigs(None, Some(8090)) == None chainConfigs(None, None) == None |
We can even use a for loop to make it more readable.
|
1 2 3 4 5 6 |
def chainConfigs(stubHost: Option[String], stubPort: Option[Int]): Option[StubConfig] = { for { host <- stubHost port <- stubPort } yield StubConfig(host, port) } |
Ratpack applications can be written in Java and Groovy. The Java API is already very clean and on top is a Groovy DSL to work with Ratpack. When we use Groovy we can use the DSL, which allows for more clean code. The Ratpack developers have used the @DelegateTo annotation in the source code for the DSL definition. The annotation can be used to indicate which class or interface is used as delegate to execute the closure that is passed to the method. And this helps us a lot in the code editor of IntelliJ IDEA, because IDEA uses this information to give us code completion when we use the Groovy DSL in Ratpack. And that makes using the DSL very easy, because we rely on the IDE to give us the supported properties and methods and we make less mistakes.
Gradle has an idea and eclipse plugin that we can use to configure IntelliJ IDEA and Eclipse project files. When we apply these plugins to our project we get extra tasks to generate and change project files. Inside our Gradle build file we get new configuration blocks to specify properties or invoke methods that will change the configuration files. One of the nice things to add is to let the IDE download Javadoc files for dependencies in our Java/Groovy projects. By default the sources for a dependency are already downloaded and added to the project, but Javadoc files are not downloaded.
Ratpack is from the ground up build to be performant and asynchronous. Let’s add a logging implementation that matches the asynchronous nature of Ratpack. Ratpack uses the SLF4J API for logging and if we write logging statement in our own code we should use the same API. For Groovy developers it is nothing more than adding the @Slf4j AST annotation to our classes. The Logback library has an asynchronous appender which has a queue to store incoming logging events. Then a worker on a different thread will invoke a classic blocking appender, like a file or console appender, to actually log the messages. But in our example we don’t use the standard async appender from Logback, but use a asynchronous logbook appender from the Reactor project. Now our queue is backed by a very performant reactor ring buffer implementation.
To start our Ratpack application with a random port number we must use the value 0 as port number. The value 0 tells Ratpack to use a random port number (in a safe port range).
In the following example Ratpack application we configure the server port to be random:
|
1 2 3 4 5 6 7 8 9 |
import static ratpack.groovy.Groovy.ratpack ratpack { serverConfig { // Tell Ratpack to use a // random port number. port 0 } } |
Written with Ratpack 1.0.0.
Update: Since Ratpack 1.1.0 the port number is always shown on the console, even if we don’t add a SLF4J API implementation.
When we use all the defaults for a Ratpack application the default port that is used for listening to incoming requests is 5050. This is something to remember, because we don’t see it when we start the application. If we want to show it, for example in the console, we must add a SLF4J Logging API implementation. Ratpack uses SLF4J API for logging and the port number and address that is used for listening to incoming requests are logged at INFO level. We must add a runtime dependency to our project with a SLF4J API implementation. We provide the necessary logging configuration if needed and then when we start our Ratpack application we can see the port number that is used.
Grails 3 introduced the concept of application profiles to Grails. A profile contains the application structure, dependencies, commands and more to configure Grails for a specific type of application. The profiles are stored on the Grails Profile repository on Github. We can go there and see which profiles are available, but it is much easier to use the list-profiles command. With this command we get an overview of all the available profiles we can use to create a new application or plugin.
To start Grails in interactive mode we simply type grails on the command line. This starts Grails and we get an environment to run Grails commands like compile and run-app. Since Grails 3 the underlying build system has changed from Gant to Gradle. We can invoke Gradle tasks in interactive mode with the gradle command. Just like we would use Gradle from the command line we can run the same tasks, but this time when Grails is in interactive mode. Grails will use the Gradle version that belongs to the current Grails version.
We even get TAB completion for Gradle tasks.