Coding

Micronaut Mastery: Use Micronaut Beans In Spring Applications

Posted on by  
Hubert Klein Ikkink

We can add Micronaut beans to the application context of a Spring application. Micronaut has a MicronautBeanProcessor class that we need to register as Spring bean in the Spring application context. We can define which Micronaut bean types need to be added to the Spring application context via the constructor of the MicronautBeanProcessor class. This way we can use Micronaut from inside a Spring application. For example we can use the declarative HTTP client of Micronaut in our Spring applications.

First we need to add dependencies on Micronaut to our Spring application. In this example we will use the Micronaut HTTP client in our Spring application and use Gradle as build tool. We must add the following dependencies:

Continue reading →

Micronaut Mastery: Running Code On Startup

Posted on by  
Hubert Klein Ikkink

When our Micronaut application starts we can listen for the ServiceStartedEvent event and write code that needs to run when the event is fired. We can write a bean that implements the ApplicationEventListener interface with the type ServiceStartedEvent. Or we can use the @EventListener annotation on our method with code we want to run on startup. If the execution of the code can take a while we can also add the @Async annotation to the method, so Micronaut can execute the code on a separate thread.

In our example application we have a reactive repository for a Mongo database and we want to save some data in the database when our Micronaut application starts. First we write a bean that implements the ApplicationEventListener:

Continue reading →

My Move to Kotlin

Posted on by  
Niels Dommerholt

Back in '98 when I started with my CS education Java was the first programming language we were taught. Before I had experimented with QBasic, C and assembly but that was the moment where I started to really grow into being a software engineer. While I made something excursions to other languages; PHP, C#, JavaScript and even ColdFusion, Java always was my 'base' where I returned to. My great love as it were. But now she’s fallen out of fashion and I’m moving on to greener pastures: Kotlin.

You might notice quite a big gap between this post and the previous one. There are multiple reasons for this (a project taking up a lot of my energy is one of them), but a big reason is that in my personal projects I don’t really feel like using Java anymore, but on the other hand Java is the common theme in most of my posts here. This is also reflected in the traffic my blog is getting; the "how to do X" type posts are the most popular.

My definitive move towards Kotlin started in November last year with the (awesome, check them out!) Advent of Code contest of 2017. I use these to challenge myself to learn new things. Back in 2015 I used the challenge to learn Scala and last year I started using Kotlin to solve the 2017 challenges (link if you want to check them out).

While doing the 2017 challenges I was actually having so much fun with Kotlin that I started working on the 2016 challenges as well!

Continue reading →

Spicy Spring: Dockerize Spring Boot Application With Jib

Posted on by  
Hubert Klein Ikkink

Jib is an open-source Java library from Google for creating Docker images for Java applications. Jib can be used as Maven or Gradle plugin in our Spring Boot project. One of the nice feature of Jib is that it adds layers with our classes, resources and dependency libraries for the Docker image. This means that when only class files have changed, the classes layer is rebuild, but the others remain the same. Therefore the creation of a Docker image with our Spring Boot application is also very fast (after the first creation). Also the Maven and Gradle plugins have sensible defaults, like using the project name and version as image name, so we don’t have to configure anything in our build tool. Although Jib provides options to configure other values for the defaults, for example to change the JVM options passed on to the application.

Let’s see Jib in action for a simple Spring Boot application. In our example we use Gradle as build tool with the following Spring Boot application:

Continue reading →

Micronaut Mastery: Change The Default Package For Generated Classes

Posted on by  
Hubert Klein Ikkink

When we use the Micronaut command line commands to generate controllers, beans and more, the classes will have a default package name. We can use a fully qualified package name for the class we want to generate, but when we only define a class name, Micronaut will use a default package name automatically. We can set the default package for an application when we first create an application with the create-app command. But we can also alter the default package name for an existing Micronaut application.

To set the default package name when we create a new application we must include the package name in our application name. For example when we want to use the default package name mrhaki.micronaut for an application that is called book-service we must use the following create-app command:

Continue reading →

Micronaut Mastery: Adding Custom Info To Info Endpoint

Posted on by  
Hubert Klein Ikkink

In a previous post we learned how to add build information to the /info endpoint in our application. We can add custom information to the /info endpoint via our application configuration or via a bean by implementing the InfoSource interface. Remember we need to add the io.micronaut:management dependency to our application for this feature.

Any configuration property that is prefixed with info will be exposed via the /info endpoint. We can define the properties in configuration files, using Java system properties or system environment variables. In the following example configuration file we add the property info.sample.message:

Continue reading →

Micronaut Mastery: Using Specific Configuration Properties For HTTP Client

Posted on by  
Hubert Klein Ikkink

One of the (many) great features of Micronaut is the HTTP client. We use the @Client annotation to inject a low-level HTTP client. Or we define a declarative HTTP client based on an interface, for which Micronaut will generate an implementation. The @Client annotation supports the configuration parameter to reference a configuration class with configuration properties for the HTTP client. The configuration class extends HttpClientConfiguration to support for example the configuration of timeouts and connection pooling. We can add our own configuration properties as well and use them in our application.

In the following example we want to access the OpenWeatherMap API using a declarative HTTP client. First we write a class that extends HttpClientConfiguration. This gives us HTTP client configuration properties and we also add some properties to define the OpenWeatherMap URI, path and access key we need to invoke the REST API. Finally we add configuration properties for a @Retryable annotation we want to use for our HTTP client.

Continue reading →

Micronaut Mastery: Using Stubs For Testing

Posted on by  
Hubert Klein Ikkink

Writing tests is always a good idea when developing an application. Micronaut makes it very easy to write tests. Using the @Client annotation we can generate a client for our REST resources that uses HTTP. Starting up a Micronaut application is so fast we can run our actual application in our tests. And using dependency injection we can replace components from the production application with stubs in our tests.

Let’s show how we can use stub in our tests for an example application. In the example application we have controller ConferenceController that returns Conference objects. These objects are fetched from a simple data repository ConferenceDataRepository. When we write a test we want to replace the ConferenceDataRepository with a stub, so we can return the appropriate Conference objects for our tests.

Continue reading →

Micronaut Mastery: Return Response Based On HTTP Accept Header

Posted on by  
Hubert Klein Ikkink

Suppose we want our controller methods to return a JSON response when the HTTP Accept header is set to application/json and XML when the Accept header is set to application/xml. We can access the values of HTTP headers in our controller methods by adding an argument of type HttpHeaders to our method definition and Micronaut will add all HTTP headers with their values as HttpHeaders object when we run the application. In our method we can check the value of the Accept header and return a different value based on the header value.

In the following example controller we have a sample method with an argument of type HttpHeaders. We check the value of the Accept header using the method accept and return either XML or JSON as response.

Continue reading →

Micronaut Mastery: Add Custom Health Indicator

Posted on by  
Hubert Klein Ikkink

When we add the io.micronaut:management dependency to our Micronaut application we get, among other things, a /health endpoint. We must enable it in our application configuration where we can also configure how much information is shown and if we want to secure the endpoint. Micronaut has some built-in health indicators, some of which are only available based on certain conditions. For example there is a disk space health indicator that will return a status of DOWN when the free disk space is less than a (configurable) threshold. If we would have one or more DataSource beans for database access in our application context a health indicator is added as well to show if the database(s) are available or not.

We can also add our own health indicator that will show up in the /health endpoint. We must write a class that implements the HealthIndicator interface and add it to the application context. We could add some conditions to make sure the bean is loaded when needed. Micronaut also has the abstract AbstractHealthIndicator class that can be used as base class for writing custom health indicators.

Continue reading →

Micronaut Mastery: Add Build Info To Info Endpoint

Posted on by  
Hubert Klein Ikkink

Micronaut has some built-in management endpoints to get information, a list of beans, health checks and more. To enable the endpoints we must add the dependency io.micronaut:management to our application. Then we can add configuration properties to enable the different endpoints. The /info endpoint gathers information from several sources with properties. If we want to add build information we must create a file build-info.properties with information and Micronaut will automatically add the properties from the file to the /info endpoint.

We can choose how we want to create the build-info.properties file. The location is configurable via Micronaut application configuration properties, but the default location is on the classpath at META-INF/build-info.properties. To make life easy for us we reuse the BuildInfo Gradle task from the Spring Boot Gradle plugin to create the build-info.properties file.

Continue reading →

Micronaut Mastery: Decode JSON Using Custom Constructor Without Jackson Annotations

Posted on by  
Hubert Klein Ikkink

Micronaut uses Jackson to encode objects to JSON and decode JSON to objects. Micronaut adds a Jackson ObjectMapper bean to the application context with all configuration to work properly. Jackson can by default populate an object with values from JSON as the class has a no argument constructor and the properties can be accessed. But if our class doesn’t have a no argument constructor we need to use the @JsonCreator and @JsonProperty annotations to help Jackson. We can use these annotation on the constructor with arguments that is used to create an object.

But we can even make it work without the extra annotations, so our classes are easier to read and better reusable. We need to add the Jackson ParameterNamesModule as module to the ObjectMapper instance in our application. And we need to compile our sources with the -parameter argument, so the argument names are preserved in the compiled code. Luckily the -parameter option is already added to our Gradle build when we create a Micronaut application. All we have to do is to add the ParameterNamesModule in our application.

Continue reading →

shadow-left