For the latest stable version, please use Spring Modulith 1.4.4!

Spring Modulith Runtime Support

The functionality described in previous chapters have all used the application module arrangement in either testing scenarios for verification and documentation purposes or were general support functionality that help to loosely couple modules but did not work with the application module structure directly. In this section we are going to describe Spring Modulith’s support for module initialization at application runtime.

If you are applying customizations to the application module detection described here, you need to move those into your production sources, unless already present there, to make sure that those are considered by the features described here.

Setting up Runtime Support for Application Modules

To enable the runtime support for Spring Modulith, make sure you include the spring-modulith-runtime JAR in your project.

Maven
Gradle

<dependency>
  <groupId>org.springframework.modulith</groupId>
  <artifactId>spring-modulith-runtime</artifactId>
  <scope>runtime</scope>
</dependency>

dependencies {
  runtimeOnly 'org.springframework.modulith:spring-modulith-runtime'
}

It’s worth noting that using the runtime support of Spring Modulith will mean that you include both ArchUnit and the JGraphT (required to topologically sort application modules) library in your application.

Adding this JAR will cause Spring Boot auto-configuration to run that registers the following components in your application:

An ApplicationModulesRuntime that allows to access the ApplicationModules.
A SpringBootApplicationRuntime to back the former bean to detect the main application class.
An event listener for ApplicationStartedEvents that will invoke ApplicationModuleInitializer beans defined in the application context.

Application Module Initializers

When working with application modules, it is pretty common to need to execute some code specific to an individual module on application startup. This means that the execution order of that code needs to follow the dependency structure of the application modules. If a module B depends on module A, the initialization code of A has to run before the one for B, even if the initializers do not directly depend on another.

While developers could of course define the execution order via Spring’s standard @Order annotation or Ordered interface, Spring Modulith provides an ApplicationModuleInitializer interface for beans to be run on application startup. The execution order of those beans will automatically follow the application module dependency structure.

Java
Kotlin

@Component
class MyInitializer implements ApplicationModuleInitializer {

  @Override
  public void initialize() {
    // Initialization code goes here
  }
}

@Component
class MyInitializer : ApplicationModuleInitializer {


  override fun initialize() {
    // Initialization code goes here
  }
}

Note that the ApplicationModuleInitializer beans will only be invoked if the spring-modulith-runtime JAR is on the classpath (see Setting up Runtime Support for Application Modules) as that pulls in the dependencies that are needed to topologically sort the initializers according to the application module structure.