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 →
GitHub supports Asciidoctor markup.
We can add a document to GitHub with the extension adoc and it is parsed and the resulting HTML is shown when we view the document in our web browser in a GitHub repository.
In March 2016 Dan Allen tweeted about enabling admonition icons on GitHub.
A follow-up tweet by Ted Bergeron mentioned more examples.
In this post we see an example on how to use their suggestions.
Normally we wouldn't see an icon, but we can use document attributes and assign an emoji for each admonition type.
For example a note admonition icon is set with the document attribute note-caption.
We can use a condition check to see if the document is rendered on GitHub and only then use the document attributes.
In the following example we assign icons to the different admonitions:
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 →
Usually in our Ratpack application we use a registry to store components that we want to use in our application code.
The calling code for the registry doesn't need to know how the registry is implemented.
Ratpack support Google Guice for example, but Spring is also supported.
This means we can define the components for our registry using Spring and we only have to tell Ratpack where to look for the Spring configuration files.
Ratpack provides for us the ratpack.spring.Spring class with the static method spring.
This method returns a Ratpack registry implementation we can use in our application.
To enable Spring support we must add the Ratpack spring-boot dependency to our build file:
Continue reading →
Groovy has a lot of nice and useful gems.
One of them is the FileTreeBuilder class.
With this class we can create directories and files using a nice DSL with a builder syntax.
The code already reflects the hierarchy of the directory structure, which makes it so more readable.
We can use an explicit way of referring to methods in the FileTreeBuilder class, but there is also support for a more dynamic version, where Groovy's dynamic nature comes to play.
In the first example we use the explicit method names.
We can use the method dir to create directories and the method file to create a file.
We can specify a name for the file and also contents:
Continue reading →
When we write software it is good practice to also write tests.
Either before writing actual code or after, we still need to write tests.
In Grails we can use the test-app command to execute our tests.
If we specify the extra option -continuous Grails will monitor the file system for changes in class files and automatically compiles the code and executes the tests again.
This way we only have to start this command once and start writing our code with tests.
If we save our files, our code gets compiled and tested automatically. We can see the output in the generated HTML report or on the console.
Suppose we have our Grails interactive shell open and we type the following command:
Continue reading →
Because Grails 3 is based on Spring Boot we can use a lot of the functionality of Spring Boot in our Grails applications.
For example we can start Grails 3 with a random available port number, which is useful in integration testing scenario's.
To use a random port we must set the application property server.port to the value 0.
If we want to use the random port number in our code we can access it via the @Value annotation with the expression ${local.server.port}.
Let's create a very simple controller with a corresponding integration test.
The controller is called Sample:
Continue reading →
Gradle 2.13 added a new method to get a property value: findProperty.
This method will return a property value if the property exists or null if the property cannot be found.
Gradle also has the property method to return a property value, but this method will throw an exception if the property is missing.
With the new findProperty method and the Groovy elvis operator (?:) we can try to get a property value and if not found return a default value.
In the following example we have a task that tries to print the value of the properties sampleOld and sampleNew.
We use the findProperty for sampleNew and the property method for sampleOld:
Continue reading →
Since Grails 3 we use Gradle as the build system.
This means we also use Gradle to define dependencies we need.
The default Gradle build file that is created when we create a new Grails application contains the Gradle dependency management plugin via the Gradle Grails plugin.
With the dependency management plugin we can import a Maven Bill Of Materials (BOM) file.
And that is exactly what Grails does by importing a BOM with Grails dependencies.
A lot of the versions of these dependencies can be overridden via Gradle project properties.
To get the list of version properties we write a simple Gradle task to print out the values:
Continue reading →
