We know Grails 3 is based on Spring Boot. This means we can use Spring Boot features in our Grails application. For example a default Grails application has a dependency on Spring Boot Actuator, which means we have a /info endpoint when we start the application. We add the Git commit id and branch to the /info endpoint so we can see which Git commit was used to create the running application.

First we must add the Gradle Git properties plugin to our build.gradle file. This plugin create a git.properties file that is picked up by Spring Boot Actuator so it can be shown to the user:

Continue reading →

Ratpack has a very useful class: TestHttpClient. This is a blocking HTTP client that we normally use for testing our Ratpack applications. For example we use MainClassApplicationUnderTest or GroovyRatpackMainApplicationUnderTest in a test and invoke the getHttpClient method to get an instance of TestHttpClient. The class has a lot of useful methods to make HTTP requests with a nice DSL. TestHttpClient is also very useful as a standalone HTTP client in other applications.

Suppose we have a piece of code that needs to access MapQuest Open Platform Web Services to get location details for a given combination of longitude and latitude values. In the constructor we create an instance of the interface ApplicationUnderTest. We then can use the getHttpClient method of ApplicationUnderTest to get a TestHttpClient instance:

Continue reading →

When we write code with a lot of method chaining that involves closures and the use the Reformat code feature of IntelliJ IDEA things might get screwed up. Luckily we can changes some Groovy formatting rules in IntelliJ IDEA to prevent the reformatting.

In the following screenshot we see the original piece of code in the IntelliJ IDEA editor:

Continue reading →

Suppose we have a piece of code that uses an external HTTP service. If we write a test for this code we can invoke the real HTTP service each time we execute the tests. But it might be there is a request limit for the service or the service is not always available when we run the test. With Ratpack it is very, very easy to write a HTTP service that mimics the API of the external HTTP service. The Ratpack server is started locally in the context of the test and we can write extensive tests for our code that uses the HTTP service. We achieve this using the Ratpack EmbeddedApp or GroovyEmbeddedApp class. With very little code we configure a server that can be started and respond to HTTP requests.

In our example project we have a class GeocodeService that uses the external service MapQuest Open Platform Web Services. We use the HTTP Requests library to make a HTTP request and transform the response to an object:

Continue reading →

When we define our Ratpack application using the Groovy DSL in a file ratpack.groovy, we can split up the definition in multiple files. With the include method inside the ratpack configuration closure we can use the file name of the file we want to include. The file that we include also contains a ratpack configuration closure. We can use the same bindings, handlers and serverConfig sections. The bindings configuration is appended to the parent configuration. The handlers and serverConfig configuration is merged with the parent configuration.

In an example project we have the following ratpack.groovy, that includes two extra files: course.groovy and loghandler.groovy:

Continue reading →

In Spring we use the @EnableAutoConfiguration each time when we use the @SpringBootApplication annotation. If we look at the @SpringBootApplication we can see that this automatically enables the @EnableAutoConfiguration. This last mentioned annotation triggers all the auto-configuration enabled configurations on the classpath. We can write an auto-configuration enabled @Configuration ourself in only two steps.

package com.jdriven.example;

import org.springframework.context.annotation.Configuration;

@Configuration
public class MyOwnAutoConfiguration {

    //You can define your own beans here and
    //further setup this Configuration as you normally would do

}

Continue reading →

In Spring MVC we get some method argument types resolved by default and injected in Spring MVC controller methods. Some examples are Model, Locale and OutputStream. What if we want to inject a custom argument in Spring MVC controller methods? In this example we extract the X-Application-Version HTTP header from the request and inject that as a method argument called version. Our controller class will look like the following:

@RestController
public class MyController {

    @RequestMapping("/persons")
    //I want the version to be automatically injected
    public List getPersons(String version) {
        .....
        return someList;
    }
} 

Continue reading →

In a previous post we learned how to add an extra DataSource to our Ratpack application. At that time on the Ratpack Slack channel there was a discussion on this topic and Danny Hyun mentioned an idea by Dan Woods to use a Map with DataSource objects. So it easier to add more DataSource and Sql objects to the Ratpack registry. In this post we are going to take a look at a solution to achieve this.

We are going to use the HikariDataSource, because it is fast and low on resources, in our example code. First we create a new class to hold the configuration for multiple datasources. The configuration is a Map where the key is the name of the database and the value an HikariConfig object. The key, the name of the database, is also used for creating the HikariDataSource and Sql objects. And the good thing is that Ratpack uses a Jackson ObjectMapper to construct a configuration object and it understands Map structures as well. In the ratpack.groovy file at the end of this blog post we see how we can have a very clean configuration this way.

Continue reading →

Recently on our project where we use Ratpack we had to get data from different databases in our Ratpack application. We already used the HikariModule to get a DataSource to connect to one database. Then with the SqlModule we use this DataSource to create a Groovy Sql instance in the registry. In our code we use the Sql object to query for data. To use the second database we used the Guice feature binding annotations to annotate a second DataSource and Sql object. In this post we see how we can achieve this.

Interestingly while I was writing this post there was a question on the Ratpack Slack channel on how to use multiple datasources. The solution in this post involves still a lot of code to have a second DataSource. In the channel Danny Hyun mentioned a more generic solution involving a Map with multiple datasources. In a follow-up blog post I will write an implementation like that, so we have a more generic solution, with hopefully less code to write. BTW the Ratpack Slack channel is also a great resource to learn more about Ratpack.

Continue reading →

To start a new project based on Spring or Spring Boot we can use the website start.spring.io. We can easily create a project templates based on Maven or Gradle and define all needed dependencies by clicking on checkboxes in the UI. In a previous post we also learned how to create a project using a URL using the same start.spring.io website. The start.spring.io website is actually a Spring Boot application and we can easily host our own server. With our own server we can for example limit the number of dependencies, force Gradle as the only build tool and set default values for project name, packages and much more.

To get started we must first clone the GitHub project. We need to build the project with Maven to install the libraries in our local Maven repository. After that is done we are reading to use it in our own Spring Boot application that is our customised Spring Initializr server. The easiest way to run the server is to have the Spring CLI tool installed. The easiest way to install it is using SDKMAN!. We type on the command line $ sdk install springboot.

Continue reading →

If we have a Gradle task of type Test we can use a filter on the command line when we invoke the task. We define a filter using the --tests option. If for example we want to run all tests from a single package we must define the package name as value for the --tests option. It is good to define the filter between quotes, so it is interpreted as is, without any shell interference.

If we configure the test task to output the test class name we can see that which tests are executed. In the following snippet we reconfigure the test task:

Continue reading →

If we want to see how productive we are with IntelliJ IDEA we must open Help | Productivity Guide. IntelliJ IDEA opens a dialog window with a very detailed overview of smart stuff we have been using. And how much typing we have saved.

Continue reading →