[[runtime]]
= 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.

[[setup]]
== 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.
[tabs]
======
Maven::
+
[source, xml, role="primary"]
----
<dependency>
  <groupId>org.springframework.modulith</groupId>
  <artifactId>spring-modulith-runtime</artifactId>
  <scope>runtime</scope>
</dependency>
----

Gradle::
+
[source, xml, role="secondary"]
----
dependencies {
  runtimeOnly 'org.springframework.modulith:spring-modulith-runtime'
}
----
======

IMPORTANT: It's worth noting that using the runtime support of Spring Modulith will mean that you include both https://www.archunit.org/[ArchUnit] and the https://jgrapht.org/[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 https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#features.spring-application.application-events-and-listeners[`ApplicationStartedEvent`]s that will invoke xref:runtime.adoc#application-module-initializer[`ApplicationModuleInitializer`] beans defined in the application context.

[[application-module-initializer]]
== 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.

[plantuml, format='svg']
....
hide empty members

package org.springframework.modulith {
interface ApplicationModuleInitializer
}

package com.acme.moduleA {
  class InitializerA implements ApplicationModuleInitializer

  class ComponentA
}

package com.acme.moduleB {

  class ComponentB

  class InitializerB implements ApplicationModuleInitializer
}

ComponentB --> ComponentA

....

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.

[tabs]
======
Java::
+
[source, java, role="primary"]
----
@Component
class MyInitializer implements ApplicationModuleInitializer {

  @Override
  public void initialize() {
    // Initialization code goes here
  }
}
----
Kotlin::
+
[source, kotlin, role="secondary"]
----
@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 xref:runtime.adoc#setup[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.
