With @ConfigurationProperties
in Spring Boot we can bind configuration properties to Java classes. The class annotated with @ConfigurationProperties
can be injected into other classes and used in our code. We can use the type Duration
to configure properties that express a duration. When we set the value of the property we can use:
-
a long
value with the unit to express milliseconds,
-
a value following the ISO-8601 duration format,
-
a special format supported by Spring Boot with the value and unit.
Continue reading →
With @ConfigurationProperties
in Spring Boot we can bind configuration properties to Java classes. The class annotated with @ConfigurationProperties
can be injected into other classes and used in our code. We can use the type DataSize
to configure properties that express a size in bytes. When we set the value of the property we can use a long
value. The size is then in bytes as that is the default unit. We can also add a unit to the value. Valid units are B
for bytes, KB
for kilobytes, MB
for megabytes, GB
for gigabytes and TB
for terabytes.
We can also use the @DataSizeUnit
annotation to specify the unit of the property in our class annotated with @ConfigurationProperties
. In that case a the value without a unit assigned to the property is already in the specified unit.
Continue reading →
Spring Boot 3 requires at least Java 17, but that also means the Java version used by Gradle must also be at least 17. Otherwise we will get the following error message when we build our Spring Boot project in IntelliJ using Gradle:
The issue is that the Spring Boot Gradle plugin 3.1.5 requires Java 17, but our project is using Java 11. We can fix this by explicitly setting the Java version that Gradle uses in IntelliJ. Go to Settings > Build, Execution, Deployment > Build Tools > Gradle and change the JVM used for Gradle to a JDK version of at least version 17.
Continue reading →
WireMock is a stub framework that helps you create stubs for outgoing HTTP traffic during your tests.
Most people use WireMock in their test suite during build time of the application.
Spin up the WireMock server, configure some stub rules, run the application tests, and tear everything down.
This is a good way of testing your HTTP clients, using real traffic towards an external server.
Continue reading →
Continue reading →
A Spring Boot application typically consists of several components handling the business functionality and probably some configuration to configure all these components.
This configuration consists of defining some properties, setting up some beans with the right conditions and dependencies and wrapping it all together into a class structure.
Nevertheless, the configuration of our Spring Boot application is also code.
Let’s threat is as code.
In this blog we will se how we can improve our Spring Boot Configuration by splitting up the configuration from the properties and how this effects the design principles.
Continue reading →
WebFlux is the reactive web framework for Spring.
The programming model is easy but using it could be cumbersome if you don’t know the consequences when used incorrectly.
This post will show what the consequences are when the reactive-stack is not used correctly.
It will answer the question: why is my (health) endpoint sometimes so slow?
TL DR; Don’t block the event loop
Continue reading →
Spring offers several frameworks to implement server side rendered web pages and REST APIS.
In this blog I compare three options:
-
traditional, servlet based (spring-web),
-
reactive, Netty based (spring-webflux) and
-
DSL, reactive, Netty based (spring-jafu)
Continue reading →
When creating a Spring Boot Rest service, you can configure Spring to convert a LocalDateTime to display as a ISO-8601 date string when returning a JSON response.
To get this working you have to do a few things.
Firstly, you need the following dependency: com.fasterxml.jackson.datatype:jackson-datatype-jsr310
This dependency has all the JSON serialisers and deserialisers for the Java 8 time API, and when you use Spring Boot with auto configuration, it should load all the correct serialisers.
Secondly, you need to add the following to your application properties:
Continue reading →
In a previous post we learned that configuration property values can be passed via environment variables. With Spring Boot we can also pass the values using Java system properties. So if we have a property sample.message
then we can use -Dsample.message=value
to pass a value when we run the application. If we use the Spring Boot Gradle plugin we must reconfigure the bootRun
task to pass Java system properties from the command-line.
Let's reuse our sample application from the previous blog post:
Continue reading →
Spring Boot has many options for externalising the configuration of our application. One of the options it to use OS environment variables. We need to follow certain rules to name the environment variable and then Spring Boot will use the value of variable to set a configuration property. The property name must be in uppercase and any dots need to be replaced with underscores. For example the configuration property sample.message
is set with the environment variable SAMPLE_MESSAGE
. This feature can be useful in a continuous integration environment where we can set environment variables or just when developing locally. The nice thing is that this also works when we use the Spring Boot Gradle plugin. The environment variables are passed on to the Java process that the bootRun
task starts.
The following source file is a simple Spring Boot command-line application. The sample.message
property can be configured as by Spring. If there is no value set the default value "default"
is used.
Continue reading →
The auto-configuration feature in Spring Boot adds beans to our application context based on conditions. For example based on the availability of a class on the class path or a environment property beans are enabled or disabled. We must apply the @EnableAutoConfiguration
or @SpringBootApplicaiton
in our Spring Boot application to make this work. To get an overview of all the configurations that had positive and negative conditional matches in our application we can use the --debug
command-line option. This will print out a report to System.out with a complete overview. We can check why a configuration is applied or not.
In the following Gradle build file we add the option --debug
to the args
property of the bootRun
task:
Continue reading →