Creating a Custom Starter With Spring Boot 3

Starters are an integral part of the Spring Boot application. In addition to dependency versioning, they provide the ability to describe the configuration for a particular functionality. They gained their popularity due to the development of microservice architecture. When we have dozens or hundreds of services within one application, some of the functionality is not duplicated. For example, we need to connect the cache, database, logging etc. In order not to duplicate the same configuration every time, we simply add the starter as a dependency to our microservice, and Spring recognizes all our configurations.

We will try to create our own simple starter on Spring Boot 3. There have been some changes in it compared to the second version. Our starter will have the simplest functionality, namely to output a message to the console when our application starts. We create a project through spring initializer, which we will call according to the custom-spring-boot-starter convention

We connect it as a module in our application. In real projects, of course, it will be connected as an external dependency, but it is more convenient for us to do this in one project so that all the code lies in one place.

Plug in the module in the settings. gradle file

In order for our application to send a message to the console, you can create a Listener that, when updating the context, will output the line “Our spring boot starter is working!”. We also need to implement the onApplicationEvent method, where we will send the message.

import org.springframework.context.ApplicationListener;
import org.springframework.context.event.ContextRefreshedEvent;

public class CustomListener implements ApplicationListener<ContextRefreshedEvent> {
    
  @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        System.out.println("Our spring boot starter is working!");
    }
}

Add Listener to the configuration

import org.springframework.boot.autoconfigure.AutoConfiguration;
import org.springframework.context.annotation.Bean;

@AutoConfiguration
public class CustomConfiguration {
  
    @Bean
    public CustomListener customListener() {
        return new CustomListener();
    }
}

In order for this configuration to be pulled into our main application, we need to add the META-INF/org. spring framework. boot. autoconfigure file.AutoConfiguration.imports, where the path for the configuration file will be specified. In the Spring 2 version, this file was called Spring. factories and was described in a slightly different way. Thus, we get an inversion of control, since we do not need to connect our starters in the code.

We add all our configurations to the file from a new line

We add our starter depending on the build file. Gradle

We launched the application and it seems that the message was displayed at startup. Our starter has worked successfully.

How does it work? We have an annotation @SpringBootApplication that includes @EnableAutoConfiguration. When scanning packages, it finds all the imported files and connects the configurations that are described there.

If you want to migrate the starters from SB 2. x to SB 3, you should consider a few additional points.

• You have to use Java 17+
• Replace java import.* on Jakarta.*
• For declared autoconfiguration, change @Configuration to @AutoConfiguration.
• Trailing slash in controllers was removed by default
• The mapping of properties has changed from spring. Redis to spring. data.redist
• Spring-cloud-sleuth is absorbed by the micrometre project. Now the tracking of requests in the actuator is automatically enabled (that is, health checks, samples, etc. begin to be included in the trace).
• Prometheus. The properties for enabling the metrics endpoint have changed.

Was management: metrics: export: prometheus: enabled: true 

Become management: prometheus: metrics: export: enabled: true