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 →
When we start a Spring Boot application and pass arguments to the application, Spring Boot will capture those arguments and creates a Spring bean of type ApplicationArguments and puts it in the application context.
We can use this Spring bean to access the arguments passed to the application.
We could for example auto wire the bean in another bean and use the provided argument values.
The ApplicationArguments interface has methods to get arguments values that are options and plain argument values.
An option argument is prefixed with --, for example --format=xml is a valid option argument.
If the argument value is not prefixed with -- it is a plain argument.
In the following example application we have a Spring Boot application with a Spring bean that implements CommandLineRunner.
When we define the CommandLineRunner implementation we use the ApplicationArguments bean that is filled by Spring Boot:
Continue reading →
When we write a Spring Boot application a lot of things are done for us.
For example when an exception in the application occurs when we start our application, Spring Boot will exit the application with exit code 1.
If everything goes well and the we stop the application the exit code is 0.
When we use the run method of SpringApplication and an exception is not handled by our code, Spring Boot will catch it and will check if the exception implements the ExitCodeGenerator interface.
The ExitCodeGenerator interface has one method getExitCode() which must return a exit code value.
This value is used as input argument for the method System.exit() that is invoke by Spring Boot to stop the application.
In the following example application we write a Spring Boot command line application that can throw an exception on startup.
The exception class implements the ExitCodeGenerator interface:
Continue reading →
With Spring Boot Actuator we get some endpoints that display information about our application.
One of the endpoints is the /info endpoint.
If our project uses Git we can add information about Git to the /info endpoint.
By default Spring Boot will look for a file git.properties in the classpath of our application.
The file is a Java properties file with keys that start with git. and have values like the branch name, commit identifier and commit message.
Spring Boot uses this information and when we request the /info endpoint we get a response with the information.
This can be very useful to check the Git information that was used to build the application.
To create the git.properties file we can use a Gradle (or Maven) plugin that will do the work for us.
In the following example we use the Gradle plugin to generate the git.properties file for our project.
The Gradle Git properties plugin is added in the plugins configuration block.
The plugin adds a Gradle extension gitProperties that can be used to customize the output in git.properties.
We could even change the location, but we keep it to the default location which is build/resources/main/git.properties.
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 →
Sometimes we are working on an application where we have no control over specific Spring bean implementations. Nevertheless we want to check for the existence (or duplication) of these bean implementations during start-up of the application server. Since Spring version 3.0 it is possible to use Spring's ApplicationListener. This interface is based on the EventListener and uses the standard Observer design pattern. In 3 steps we can easily check for the existence of a specific Spring bean.
We create an ApplicationListener<ContextRefreshedEvent> implementation. The method onApplicationEvent will be called when a refresh of the ApplicationContext occurs.
package com.jdriven.blog.applicationlistener;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationListener;
import org.springframework.context.event.ContextRefreshedEvent;
public class BeanContextStartupListener
implements ApplicationListener<ContextRefreshedEvent>
{
public void onApplicationEvent( ContextRefreshedEvent event )
{
...
}
}
We need to register the BeanContextStartupListener as a Spring Component. In this sample we just simply enable component scanning in the spring xml configuration as follows.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">
<context:component-scan base-package="com.jdriven.blog.applicationlistener" />
</beans>
We also add the @Component to the class definition:
import org.springframework.stereotype.Component;
@Component
public class BeanContextStartupListener
implements ApplicationListener<ContextRefreshedEvent>
We implement the onApplicationEvent method of the BeanContextStartupListener and throw an Exception when no bean exists within the current ApplicationContext.
public void onApplicationEvent( ContextRefreshedEvent event )
{
Map serviceImplementations = event.getApplicationContext().getBeansOfType( JDrivenService.class );
if ( serviceImplementations.isEmpty() ) {
throw new IllegalStateException("JDrivenService was not instantiated during startup.");
}
}
Continue reading →
