SDKMAN! is as powerful tool to install and manage software development kits (SDKs) and tools, like Java, Groovy, Gradle, Maven, Spring Boot and Quarkus. If you want to see if a new version of a SDK or tool is available, you can use the sdk upgrade
command. This command will list all outdated SDKs and tools. The installed version and the latest version are shown for each SDK and tool. To see if a single SDK or tool is outdated, you can use the name of the SDK or tool as argument to the sdk upgrade
command.
Continue reading →
When you enable the /observe
endpoints you can configure them to be served on a different port than the application. By default the endpoints are available on the same port as the application. But you can define an extra named socket with another port number in the configuration of the WebServer
instance. And in the configuration of the ObserveFeature
instance you can define the socket name that should be used for the observe endpoints.
Continue reading →
In a previous post you learned how to add information to the /observe/info
endpoint. You can also add Git information to the endpoint. For example you can add the Git commit id so you can see check, when the application is running in a production environment, which Git commit for the code was deployed. In order to achieve this you must first generate a properties file with all Git information. The next step is to process this file in your Helidon SE application and add the properties to the /observe/info
endpoint.
Continue reading →
It is possible to add an endpoint to Helidon SE that can show information about the application. You can add custom information to this endpoint. In order to enable the endpoint you need to add the dependency io.helidon.webserver.observe:helidon-webserver-observe-info
to your pom.xml
file. This will add the endpoint /observe/info
to your application. You can add key-value pairs to your configuration or code that will be exposed in the endpoint.
Continue reading →
You can configure a memory health check in Helidon SE. A memory health check will return a status of UP
if the memory usage is below a certain threshold percentage and DOWN
if the memory usage is above the threshold percentage. The default threshold percentage is 98%
. To add the memory health check you need to add the dependency io.helidon.health:helidon-health-checks
to your pom.xml
file. This dependency contains three health checks: disk space usage, memory usage and dead lock detection.
To configure the memory health check you need to set the configuration property server.features.observe.observers.health.helidon.health.memory.thresholdPercent
to the threshold percentage. Alternatively you can set the threshold percentage in your application code.
Continue reading →
Suppose you want to return a response based on the Accept
header of the request. If the Accept
header is application/json
you want to return a JSON response and if the Accept
header is application/xml
you want to return an XML response. You can use the isAccepted(MediaType)
of the ServerRequestHeaders
class to check if the value of the request header Accept
is equal to the specified media type. The method returns true
if the media type is defined for the request header Accept
and false
if not.
In order to convert an object to XML you need to add the dependency com.fasterxml.jackson.dataformat:jackson-dataformat-xml
to your pom.xml
file:
Continue reading →
You can write an implementation of the interface EnvironmentPostProcessor
to customize the Environment
of a Spring Boot application. For example you can read an external configuration file and add its properties to the Environment
. If you want to add some logging statement to the class then you need to make sure you pass a DeferredLogFactory
to the constructor of the class. From this factory you can use the getLogger
method to get a Log
instance. This is needed, because the implementation of the interface EnvironmentPostProcessor
is created before the logging system is initialized. By using the Log
instances created from DeferredLogFactory
Spring Boot will make sure the log messages are written when the logging system is initialized.
Continue reading →
In Helidon SE you can enable a health check for the disk space usage. If the disk space usage is above a certain threshold then the health check will fail. To enable the disk space health check you need to add the dependency io.helidon.health:helidon-health-checks
to your pom.xml
file. The dependency contains three health checks: disk space usage, memory usage and dead lock detection.
To configure the disk space health check you need to set the configuration property server.features.observe.observers.health.helidon.health.diskSpace.thresholdPercent
to the threshold percentage. Or programmatically set the value in your application code. The default value is 99.999
, which means that in real life the health check will not fail. You need to set a lower percentage in order to see the health check fail. For example when you set the value to 95.0
then the health check will fail when the disk space usage is above 95% or less than 5% of the disk space is available. You can also configure the path to check for disk space usage. The default path is the current working directory, but it can be set to another path. You need to set the configuration property server.features.observe.observers.health.helidon.health.diskSpace.path
to change the path.
Continue reading →
With Helidon SE you can add a health endpoint to your application by simply adding a dependency. In your pom.xml
you have to add the dependency io.helidon.webserver.observe:helidon-webserver-observe-health
. This adds a new endpoint /health
to your application. When your application is up and running the /health
endpoint will return the HTTP status code 204 with an empty body. If your application is not healthy then the HTTP status code 503 is returned. In case of an error an HTTP status code 500 is sent to the client.
If you want to see a response with details then you need to set the configuration property server.features.observe.observers.health.details
to the value true
. Instead of the HTTP status code 204 the status code 200 is returned when our application is healthy. The response contains a JSON object with a status
field with the value UP
for a healthy response. The response also contains the field checks
with an array of detailed information from health checks that are available in our application.
Continue reading →
When Maven needs to download artifacts from a remote repository, it logs the progress of the download. This can lead to a lot of noise in the output. Luckily, we can suppress the logging of the download progress. Since Maven 3.6.1. we can use the command-line option --no-transfer-progress
to disable the logging of the download progress. There is also a short version of the option: -ntp
.
Continue reading →
In a previous blog post we learned about the default input sources that are used by Helidon SE. The list of input sources is different based on which artifacts are on the classpath of our application. When we write tests for code in our application that uses the default configuration created by Config.create()
we must take into account that different input sources are used. Also here it is based on the artifacts that are on the classpath. That means that different files with configuration data are loaded, eg. a file application-test.conf
when we have the artifact helidon-config-hocon
and a file application-test.yml
if the artifact helidon-config-yaml
is on the classpath.
Continue reading →
When we use Helidon SE we can use the Config
class to pass configuration properties to our application. The static method create()
creates a default configuration. The Config
class is then configured to support different input sources. This configuration reads configuration properties from the following sources in order:
-
Java system properties,
-
system environment variables,
-
a file on the classpath that has the name application.properties
(based on default config parser that is part of the artifact helidon-config
).
The last input source behaves differently based on which classes that can parse a configuration file are on the classpath of our application. If we use the helidon-config
artifact on the classpath then the configuration file read is application.properties
. To read a JSON formatted configuration file we must add the helidon-config-hocon
artifact to the classpath. The file that is read is application.json
. With the same artifact we can read a HOCON formatted configuration file that is named application.conf
. Finally if we add the helidon-config-yaml
artifact to the classpath we can read a YAML formatted configuration file that is named application.yaml
or application.yml
. Helidon SE will only read one configuration file from the classpath with the following order of preference:
Continue reading →