Creating a Custom Starter with Spring Boot

1. Overview

The core Spring Boot developers provide starters for most of the popular open source projects, but we are not limited to these.

We can also write our own custom starters. If we have an internal library for use within our organization, it would be a good practice to also write a starter for it if it’s going to be used in Spring Boot context.

These starters enable developers to avoid lengthy configuration and quickly jumpstart their development. However, with a lot of things happening in the background, it sometimes becomes difficult to understand how an annotation or just including a dependency in the pom.xml enables so many features.

In this article, we’ll demystify the Spring Boot magic to see what’s going on behind the scenes. Then we will use these concepts to create a starter for our own custom library.

2. Demystifying Spring Boot’s Autoconfiguration

2.1. Auto Configuration Classes

Since version 2.7, Spring Boot looks for auto-configuration imports in the file META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports when it starts. We can have a look at the file content from the spring-boot-autoconfigure project as an example:

...
org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration
org.springframework.boot.autoconfigure.data.cassandra.CassandraDataAutoConfiguration
org.springframework.boot.autoconfigure.data.mongo.MongoDataAutoConfiguration
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration
...

As we can see, each line in the file contains the fully qualified name of an auto-configuration class Spring Boot will try to run. So, as per this snippet, Spring Boot will try to run all the configuration classes for RabbitMQ, Cassandra, MongoDB and Hibernate.

Whether or not these classes will actually run will depend on the presence of dependent classes on the classpath. For example, if the classes for MongoDB are found on the classpath, MongoAutoConfiguration will run and all the mongo related beans will be initialized.

This conditional initialization is enabled by the @ConditionalOnClass annotation. Let’s look at the code snippet from MongoAutoConfiguration class to see its usage:

@Configuration
@ConditionalOnClass(MongoClient.class)
@EnableConfigurationProperties(MongoProperties.class)
@ConditionalOnMissingBean(type = "org.springframework.data.mongodb.MongoDbFactory")
public class MongoAutoConfiguration {
    // configuration code
}

Now how – if the MongoClient is available in the classpath – this configuration class will run populating the Spring bean factory with a MongoClient initialized with default config settings.

It’s important to note that if Spring Boot is older than 2.7, it looks for the file META-INF/spring.factories for auto-configuration imports. A similar example can be found in the spring-boot-autoconfigure project, too:

# Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration,\
org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration,\
org.springframework.boot.autoconfigure.mongo.MongoAutoConfiguration,\
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration

We can see the format of this file is a single comma-separate list indicating the auto-configuration classes. As the example above shows, we can use backslash line continuation to make the one-line list easier to read.

2.2. Custom Properties from the application.properties File

Spring Boot initializes the beans using some pre-configured defaults. To override those defaults, we generally declare them in the application.properties file with some specific name. These properties are automatically picked up by the Spring Boot container.

Let’s see how that works.

In the code snippet for MongoAutoConfiguration, @EnableConfigurationProperties annotation is declared with the MongoProperties class which acts as the container for custom properties:

@ConfigurationProperties(prefix = "spring.data.mongodb")
public class MongoProperties {

    private String host;

    // other fields with standard getters and setters
}

The prefix plus the field name make the names of the properties in the application.properties file. So, to set the host for MongoDB, we only need to write the following in the property file:

spring.data.mongodb.host = localhost

Similarly, values for other fields in the class can be set using the property file.

3. Creating a Custom Starter

Based on the concepts in section 2, to create a custom starter we need to write the following components:

1. An auto-configure class for our library along with a properties class for custom configuration.
2. A starter pom to bring in the dependencies of the library and the autoconfigure project.

For demonstration, we have created a simple greeting library that will take in a greeting message for different times of day as configuration parameters and output the greeting message. We will also create a sample Spring Boot application to demonstrate the usage of our autoconfigure and starter modules.

3.1. The Autoconfigure Module

We’ll call our auto configure module greeter-spring-boot-autoconfigure. This module will have two main classes i.e. GreeterProperties which will enable setting custom properties through application.properties file and GreeterAutoConfiguartion which will create the beans for the greeter library.

Let’s look at the code for both the classes:

@ConfigurationProperties(prefix = "baeldung.greeter")
public class GreeterProperties {

    private String userName;
    private String morningMessage;
    private String afternoonMessage;
    private String eveningMessage;
    private String nightMessage;

    // standard getters and setters

}

@Configuration
@ConditionalOnClass(Greeter.class)
@EnableConfigurationProperties(GreeterProperties.class)
public class GreeterAutoConfiguration {

    @Autowired
    private GreeterProperties greeterProperties;

    @Bean
    @ConditionalOnMissingBean
    public GreetingConfig greeterConfig() {

        String userName = greeterProperties.getUserName() == null
          ? System.getProperty("user.name") 
          : greeterProperties.getUserName();
        
        // ..

        GreetingConfig greetingConfig = new GreetingConfig();
        greetingConfig.put(USER_NAME, userName);
        // ...
        return greetingConfig;
    }

    @Bean
    @ConditionalOnMissingBean
    public Greeter greeter(GreetingConfig greetingConfig) {
        return new Greeter(greetingConfig);
    }
}

We also need to add GreeterAutoConfiguartion’s qualified class name to src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports:

com.baeldung.greeter.autoconfigure.GreeterAutoConfiguration

Of course, if we work with an older (<2.7) version Spring Boot, we must create the src/main/resources/META-INF/spring.factories file with this content:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  com.baeldung.greeter.autoconfigure.GreeterAutoConfiguration

On application startup, the GreeterAutoConfiguration class will run if the class Greeter is present in the classpath. If run successfully, it will populate the Spring application context with GreeterConfig and Greeter beans by reading the properties via GreeterProperties class.

The @ConditionalOnMissingBean annotation will ensure that these beans will only be created if they don’t already exist. This enables developers to completely override the auto-configured beans by defining their own in one of the @Configuration classes.

3.2. Creating pom.xml

Now let’s create the starter pom which will bring in the dependencies for the auto-configure module and the greeter library.

As per the naming convention, all the starters that are not managed by the core Spring Boot team should start with the library name followed by the suffix -spring-boot-starter. So we will call our starter greeter-spring-boot-starter:

<project ...>
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.baeldung</groupId>
    <artifactId>greeter-spring-boot-starter</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter</artifactId>
            <version>${spring-boot.version}</version>
        </dependency>

        <dependency>
            <groupId>com.baeldung</groupId>
            <artifactId>greeter-spring-boot-autoconfigure</artifactId>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>com.baeldung</groupId>
            <artifactId>greeter</artifactId>
            <version>${greeter.version}</version>
        </dependency>

    </dependencies>

    <properties>
        <greeter.version>0.0.1-SNAPSHOT</greeter.version>
    </properties>
</project>

3.3. Using the Starter

Let’s create greeter-spring-boot-sample-app which will use the starter. In the pom.xml we need to add it as a dependency:

<dependency>
    <groupId>com.baeldung</groupId>
    <artifactId>greeter-spring-boot-starter</artifactId>
    <version>${greeter-starter.version}</version>
</dependency>

Spring Boot will automatically configure everything and we will have a Greeter bean ready to be injected and used.

Let’s also change some of the default values of the GreeterProperties by defining them in the application.properties file with the baeldung.greeter prefix:

baeldung.greeter.userName=Baeldung
baeldung.greeter.afternoonMessage=Woha\ Afternoon

Finally, let’s use the Greeter bean in our application:

@SpringBootApplication
public class GreeterSampleApplication implements CommandLineRunner {

    @Autowired
    private Greeter greeter;

    public static void main(String[] args) {
        SpringApplication.run(GreeterSampleApplication.class, args);
    }

    @Override
    public void run(String... args) throws Exception {
        String message = greeter.greet();
        System.out.println(message);
    }
}

4. Conclusion

In this quick tutorial, we focused on rolling out a custom Spring Boot starter and how these starters, together with the autoconfigure mechanism, work in the background to eliminate a lot of manual configuration.