Spring Boot Repository Wiki

Overview

Spring Boot is a framework that simplifies the creation of production-grade Spring applications. It eliminates boilerplate configuration and provides opinionated defaults while remaining flexible enough to adapt as requirements evolve.

Core Philosophy

Spring Boot's design is built on four primary goals:

1. Rapid Getting Started - Dramatically reduce setup time for new Spring projects
2. Opinionated Yet Flexible - Provide sensible defaults that developers can override when needed
3. Non-Functional Features - Include built-in support for embedded servers, security, metrics, health checks, and externalized configuration
4. Zero Code Generation - Achieve all this without code generation or XML configuration

Key Components

SpringApplication is the entry point for bootstrapping a Spring Boot application. When you call SpringApplication.run(), it performs a series of initialization steps:

• Creates an appropriate ApplicationContext based on the classpath
• Registers command-line arguments as Spring properties
• Refreshes the application context and loads all singleton beans
• Triggers any CommandLineRunner beans

SpringBootConfiguration is a marker annotation that identifies a class as providing Spring Boot application configuration. It serves as an alternative to Spring's standard @Configuration annotation, enabling automatic configuration discovery (particularly useful in tests). Applications should include only one @SpringBootConfiguration, which is typically inherited through @SpringBootApplication.

Architecture Overview

Loading diagram...

Project Structure

The repository is organized into several key directories:

• core/ - Core Spring Boot modules including the main framework, autoconfiguration, and testing utilities
• starter/ - Starter POMs that simplify dependency management for common use cases
• module/ - Integration modules for various technologies (databases, messaging, web frameworks)
• build-plugin/ - Build tool plugins (Maven, Gradle, Ant) for packaging and deployment
• cli/ - Command-line interface for running Spring scripts
• loader/ - JAR loading and repackaging utilities
• documentation/ - Reference documentation and guides

Getting Started Pattern

The typical Spring Boot application follows this minimal pattern:

@RestController
@SpringBootApplication
public class MyApplication {
    @RequestMapping("/")
    String home() {
        return "Hello World!";
    }
    
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

The @SpringBootApplication annotation combines three key annotations: @Configuration, @EnableAutoConfiguration, and @ComponentScan, providing a complete configuration setup in a single declaration.

Architecture & Core Components

Spring Boot's architecture centers on three core pillars: SpringApplication for bootstrapping, Auto-Configuration for intelligent bean provisioning, and Conditional Configuration for classpath-aware setup.

SpringApplication: The Bootstrap Engine

SpringApplication is the entry point for launching Spring Boot applications. It orchestrates a multi-stage startup process:

1. Initialization - Detects the main application class, loads bootstrap registry initializers, and discovers application listeners via SpringFactoriesLoader
2. Environment Preparation - Binds configuration properties, command-line arguments, and system properties
3. Context Creation - Instantiates the appropriate ApplicationContext (servlet-based or reactive)
4. Context Preparation - Applies initializers, registers the banner printer, and loads bean definitions
5. Refresh - Triggers Spring's context refresh, which processes all bean definitions and instantiates singletons
6. Post-Refresh - Executes CommandLineRunner and ApplicationRunner beans

public ConfigurableApplicationContext run(String... args) {
    DefaultBootstrapContext bootstrapContext = createBootstrapContext();
    ConfigurableEnvironment environment = prepareEnvironment(listeners, bootstrapContext, args);
    ConfigurableApplicationContext context = createApplicationContext();
    prepareContext(bootstrapContext, context, environment, listeners, args, banner);
    refreshContext(context);
    callRunners(context, args);
    return context;
}

Auto-Configuration: Intelligent Bean Discovery

Auto-configuration is Spring Boot's mechanism for automatically configuring beans based on classpath dependencies and explicit configuration. The system uses three key components:

EnableAutoConfiguration - The annotation that triggers auto-configuration. It imports AutoConfigurationImportSelector, which discovers and loads auto-configuration classes from META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports.

AutoConfiguration - The annotation marking classes as auto-configurable. These are regular @Configuration classes with proxyBeanMethods = false, typically conditional on classpath presence or missing beans.

AutoConfigurationImportSelector - A DeferredImportSelector that:

• Loads candidate configurations from classpath metadata
• Applies exclusions (via @EnableAutoConfiguration(exclude=...) or spring.autoconfigure.exclude property)
• Filters configurations using AutoConfigurationImportFilter implementations
• Sorts configurations based on @AutoConfigureBefore and @AutoConfigureAfter ordering

Loading diagram...

Conditional Configuration

Auto-configuration classes use conditional annotations to activate only when appropriate:

• @ConditionalOnClass - Activates if specified classes are on the classpath
• @ConditionalOnMissingBean - Activates if no bean of the type exists
• @ConditionalOnProperty - Activates based on configuration properties
• @ConditionalOnBean - Activates if a specific bean is already registered

This allows Spring Boot to provide sensible defaults while respecting user-defined beans. Auto-configuration always runs after user-defined beans, ensuring user configuration takes precedence.

Configuration Metadata

Spring Boot uses META-INF/spring/ directory to store:

• .imports files listing auto-configuration class names
• .replacements files for auto-configuration class substitutions
• Metadata for ordering and filtering configurations

This approach enables fast startup by avoiding classpath scanning and leveraging compile-time metadata generation via the annotation processor.

Starters & Dependency Management

Overview

Spring Boot Starters are convenient dependency descriptors that simplify project setup by bundling related dependencies together. Instead of manually hunting through documentation and copy-pasting multiple dependency declarations, developers include a single starter POM and get a curated, tested set of compatible libraries. For example, adding spring-boot-starter-data-jpa automatically includes Spring Data JPA, Hibernate, and related dependencies.

Starter Architecture

Starters follow a consistent pattern:

1. Starter POM - A lightweight POM that declares dependencies using api() configurations
2. Dependency Aggregation - Starters compose other starters and modules to provide complete functionality
3. Transitive Dependencies - All transitive dependencies are automatically resolved through the dependency management platform

plugins {
    id "org.springframework.boot.starter"
}

dependencies {
    api(project(":starter:spring-boot-starter"))
    api(project(":starter:spring-boot-starter-jdbc"))
    api(project(":module:spring-boot-data-jpa"))
    api(project(":module:spring-boot-jdbc"))
}

The StarterPlugin

The StarterPlugin (applied via id "org.springframework.boot.starter") provides:

• Metadata Generation - Generates starter-metadata.properties containing starter name, description, and resolved dependencies
• Classpath Validation - Runs three checks during build:
  • CheckClasspathForConflicts - Detects conflicting dependency versions
  • CheckClasspathForUnnecessaryExclusions - Identifies unused exclusions
  • CheckClasspathForUnconstrainedDirectDependencies - Ensures all direct dependencies are version-constrained
• JAR Manifest - Marks starter JARs with Spring-Boot-Jar-Type: dependencies-starter attribute

Dependency Management Platform

The spring-boot-dependencies BOM (Bill of Materials) provides centralized version management:

• Defines versions for 200+ third-party libraries (ActiveMQ, Hibernate, Jackson, etc.)
• Organized by library with module lists and documentation links
• Supports upgrade policies (e.g., same-minor-version) for automated dependency updates
• Enables consistent versions across all starters and modules

Starter Composition Patterns

Core Starter - Foundation for all applications:

dependencies {
    api(project(":starter:spring-boot-starter-logging"))
    api(project(":core:spring-boot-autoconfigure"))
    api("jakarta.annotation:jakarta.annotation-api")
    api("org.yaml:snakeyaml")
}

Web Starter - Composes multiple starters:

dependencies {
    api(project(":starter:spring-boot-starter-jackson"))
    api(project(":starter:spring-boot-starter-tomcat"))
    api(project(":module:spring-boot-http-converter"))
    api(project(":module:spring-boot-webmvc"))
}

Starter Categories

• Core - spring-boot-starter (logging, YAML, autoconfiguration)
• Web - spring-boot-starter-web, spring-boot-starter-webflux, spring-boot-starter-websocket
• Data - spring-boot-starter-data-jpa, spring-boot-starter-data-mongodb, spring-boot-starter-data-redis
• Messaging - spring-boot-starter-amqp, spring-boot-starter-kafka, spring-boot-starter-jms
• Testing - spring-boot-starter-test (JUnit, Mockito, AssertJ, etc.)
• Observability - spring-boot-starter-actuator, spring-boot-starter-micrometer-metrics

Over 100 starters are available, each following the same composition pattern for consistency and maintainability.

Executable JAR Packaging & Loader

Spring Boot executable JARs enable self-contained applications that can be launched with java -jar without unpacking. This is achieved through a custom bootstrap loader and a specialized JAR structure.

JAR Structure

An executable JAR follows a specific layout:

example.jar
 ├─ META-INF/
 │  └─ MANIFEST.MF
 ├─ org/springframework/boot/loader/
 │  └─ <Spring Boot loader classes>
 └─ BOOT-INF/
    ├─ classes/
    │  └─ <application classes>
    └─ lib/
       └─ <dependency JARs>

Application classes go in BOOT-INF/classes/, while all dependencies are nested in BOOT-INF/lib/. The loader classes are embedded at the root to enable bootstrapping.

The Launcher System

The Launcher base class is the entry point for executable archives. It:

1. Registers custom protocol handlers for reading nested JARs without unpacking
2. Constructs a custom ClassLoader with URLs pointing to nested dependencies
3. Invokes the application's main method with the configured classpath

JarLauncher is the standard implementation for JAR files, looking for dependencies in BOOT-INF/lib/ and application classes in BOOT-INF/classes/. Alternative launchers include WarLauncher (for WAR files) and PropertiesLauncher (for dynamic classpath configuration).

Manifest Configuration

The manifest contains critical metadata:

Main-Class: org.springframework.boot.loader.launch.JarLauncher
Start-Class: com.mycompany.project.MyApplication
Spring-Boot-Version: 3.x.x
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Spring-Boot-Classpath-Index: BOOT-INF/classpath.idx
Spring-Boot-Layers-Index: BOOT-INF/layers.idx

The Main-Class points to the loader, while Start-Class specifies the actual application entry point. The Spring-Boot-* attributes guide the loader in locating resources and optimizing startup.

Build-Time Packaging

The BootJar Gradle task orchestrates packaging:

• Configures the manifest via BootArchiveSupport.configureManifest()
• Organizes dependencies into BOOT-INF/lib/ with compression settings
• Generates index files (classpath.idx, layers.idx) for faster startup
• Embeds the loader from spring-boot-loader as a resource

Libraries are stored uncompressed (STORED) to enable direct reading from the JAR without extraction. Application classes and other files use standard compression (DEFLATED).

Nested JAR Loading

The loader uses a custom Archive abstraction to read nested JARs:

• JarFileArchive handles JAR-based archives with nested dependencies
• ExplodedArchive handles exploded directory layouts (for development)
• Custom URL handlers (jar:file: protocol) enable direct access to nested entries

Nested JARs are read by mapping entry offsets within the outer JAR, avoiding the need to extract files to disk.

Classpath Index Optimization

For faster startup, Spring Boot generates classpath.idx containing an ordered list of classpath entries. The loader uses this index to:

• Skip directory scanning
• Establish a deterministic classpath order
• Reduce I/O operations during initialization

This is especially beneficial for applications with many dependencies.

Build Plugins & Tooling

Spring Boot provides build plugins for both Gradle and Maven to streamline packaging, running, and deploying applications. These plugins integrate deeply with their respective build systems to provide Spring Boot-specific functionality.

Gradle Plugin Architecture

The Spring Boot Gradle Plugin (org.springframework.boot) uses a plugin action pattern to conditionally apply functionality based on which other plugins are present in the project. The main entry point is SpringBootPlugin, which:

1. Verifies Gradle version compatibility (requires 8.14 or later)
2. Creates a springBoot extension for configuration
3. Registers a set of PluginApplicationAction implementations that react to other plugins

The plugin actions include:

• JavaPluginAction - Configures bootJar, bootRun, and bootTestRun tasks; manages classpath configurations
• WarPluginAction - Configures bootWar task for WAR packaging
• DependencyManagementPluginAction - Imports the spring-boot-dependencies BOM
• ApplicationPluginAction - Integrates with Gradle's application plugin for distribution scripts
• KotlinPluginAction - Aligns Kotlin plugin versions and configures AOT compilation
• NativeImagePluginAction - Enables GraalVM native image support
• CyclonedxPluginAction - Generates software bill of materials (SBOM)

Each action is triggered only when its corresponding plugin is applied, enabling lazy configuration and avoiding unnecessary overhead.

Maven Plugin Architecture

The Spring Boot Maven Plugin uses a Mojo-based architecture where each goal is a separate class extending AbstractMojo. Key Mojos include:

• RepackageMojo - Transforms standard JAR/WAR archives into executable archives with nested dependencies
• RunMojo - Runs the application in place with optimized launch settings
• StartMojo - Starts the application asynchronously and waits for it to be ready
• BuildImageMojo - Packages applications as OCI images using buildpacks

The plugin hierarchy is:

AbstractMojo
├── AbstractDependencyFilterMojo (handles dependency filtering)
│   ├── AbstractPackagerMojo (base for packaging operations)
│   │   ├── RepackageMojo
│   │   └── BuildImageMojo
│   └── AbstractRunMojo (base for execution)
│       ├── RunMojo
│       └── StartMojo

Key Features

Executable Archives: Both plugins can create self-contained JAR/WAR files with all dependencies nested in BOOT-INF/lib/, executable via java -jar.

Classpath Management: The Gradle plugin creates specialized configurations (productionRuntimeClasspath, developmentOnly) to exclude devtools and test dependencies from production builds.

Main Class Resolution: Both plugins automatically detect the main class or allow explicit configuration via mainClass parameter.

Image Building: Both plugins support building OCI-compliant container images using Cloud Native Buildpacks, with configurable builders and runtime images.

Spring Boot CLI

The CLI (spring-boot-cli) is built as a self-contained distribution with embedded loader and dependencies. The build process creates:

• fullJar - Complete JAR with all dependencies
• tar.gz and zip archives - Distributable packages with shell scripts
• Homebrew formula - For macOS installation

Loading diagram...

Actuator & Production Monitoring

Spring Boot Actuator provides production-ready monitoring and management capabilities through a flexible endpoint framework. It enables HTTP and JMX exposure of application metrics, health checks, and operational data.

Core Architecture

The actuator is built on a technology-agnostic endpoint model that automatically adapts to different exposure mechanisms. The @Endpoint annotation marks classes as actuator endpoints, which declare operations using @ReadOperation, @WriteOperation, and @DeleteOperation annotations. These operations are automatically adapted to HTTP (Spring MVC/WebFlux) and JMX technologies.

Loading diagram...

Endpoint Types

Spring Boot provides specialized endpoint annotations for different exposure strategies:

• @Endpoint - Base annotation for endpoints exposed over multiple technologies (HTTP and JMX)
• @WebEndpoint - HTTP-only endpoints using @ReadOperation semantics
• @JmxEndpoint - JMX-only endpoints
• @RestControllerEndpoint - Spring MVC/WebFlux endpoints with full framework integration (uses @GetMapping, @PostMapping, etc.)
• @ControllerEndpoint - Similar to @RestControllerEndpoint but for non-REST endpoints

Health Monitoring

The health endpoint aggregates health information from registered HealthContributor instances. Health contributors can be either HealthIndicator (blocking) or ReactiveHealthIndicator (non-blocking).

Health status is aggregated using a StatusAggregator that applies a priority order (default: DOWN > OUT_OF_SERVICE > UP > UNKNOWN). The HealthEndpointGroups feature allows organizing health checks into logical groups with custom aggregation rules and HTTP status mappings.

@Endpoint(id = "health")
public class HealthEndpoint {
    @ReadOperation
    public HealthDescriptor health() { ... }
}

Metrics Integration

Actuator integrates with Micrometer, a dimensional metrics facade supporting multiple backends (Prometheus, Grafana, Datadog, etc.). The MetricsEndpoint exposes registered meters through /actuator/metrics.

Key features:

• Automatic instrumentation - JVM metrics, HTTP requests, and database connections are collected automatically
• Custom metrics - Applications can register custom meters via MeterRegistry
• Meter filters - Control which metrics are collected and exported
• Observations - Micrometer observations bridge metrics and tracing

Endpoint Exposure

Endpoints are exposed through configuration properties:

• management.endpoints.web.exposure.include - HTTP endpoints to expose (default: health)
• management.endpoints.web.exposure.exclude - HTTP endpoints to hide
• management.endpoints.jmx.exposure.include - JMX endpoints to expose (default: health)
• management.endpoints.jmx.exposure.exclude - JMX endpoints to hide

The EndpointExposure enum defines which technologies can expose endpoints, and IncludeExcludeEndpointFilter applies include/exclude patterns.

Built-in Endpoints

Common endpoints include:

• /actuator/health - Application health status
• /actuator/metrics - Available metrics and their values
• /actuator/startup - Application startup timeline
• /actuator/env - Environment properties
• /actuator/loggers - Logger configuration
• /actuator/threaddump - Thread information
• /actuator/heapdump - Heap dump for memory analysis

Custom Endpoints

Create custom endpoints by annotating a class with @Endpoint and declaring operation methods:

@Endpoint(id = "custom")
public class CustomEndpoint {
    @ReadOperation
    public Map<String, String> getData() {
        return Map.of("status", "active");
    }
}

The endpoint is automatically discovered, configured, and exposed based on management properties.

Testing Framework & Test Utilities

Core Testing Annotations

Spring Boot provides specialized testing annotations that extend Spring's TestContext Framework. The @SpringBootTest annotation is the foundation, enabling full application context loading with features like custom environment properties, application arguments, and configurable web environments (mock, embedded, or none).

Key capabilities:

• Automatic detection of @SpringBootConfiguration classes
• Support for webEnvironment modes: MOCK, RANDOM_PORT, DEFINED_PORT, NONE
• Custom properties via the properties() attribute
• Application arguments via the args() attribute

Test Context Bootstrapping

The SpringBootTestContextBootstrapper orchestrates test context creation. It extends Spring's DefaultTestContextBootstrapper and uses SpringBootContextLoader to load the application context via SpringApplication. This ensures tests run with the same initialization logic as production code.

The bootstrapper handles:

• Web environment detection and servlet listener activation
• Automatic configuration search when no explicit classes are specified
• Environment property customization
• AOT (Ahead-of-Time) compilation support for GraalVM

Sliced Testing

Sliced tests focus on specific application layers, loading only relevant auto-configurations and components. This reduces startup time and isolates functionality. Common slices include:

• @WebMvcTest – Spring MVC controllers, filters, and converters
• @DataJpaTest – JPA repositories and entities (transactional, in-memory database)
• @JsonTest – JSON serialization with JacksonTester, GsonTester, JsonbTester
• @RestClientTest – REST client beans
• @DataMongoTest – MongoDB repositories

Each slice uses @OverrideAutoConfiguration(enabled = false) to disable standard auto-configuration, then selectively imports only necessary configurations via @ImportAutoConfiguration.

Test Utilities

Spring Boot provides helper classes for common testing scenarios:

• JacksonTester, GsonTester, JsonbTester – JSON serialization/deserialization assertions
• MockMvc – HTTP request testing (auto-configured with @WebMvcTest or @AutoConfigureMockMvc)
• TestRestTemplate – Integration testing with embedded servers
• @MockitoBean – Mockito bean injection into test contexts

Context Customization

The framework uses ContextCustomizerFactory implementations to customize test contexts. Key customizers include:

• ImportsContextCustomizerFactory – Processes @Import and @ImportAutoConfiguration
• PropertyMappingContextCustomizerFactory – Handles property mapping annotations
• OverrideAutoConfigurationContextCustomizerFactory – Manages auto-configuration override behavior
• OnFailureConditionReportContextCustomizerFactory – Prints condition evaluation reports on failures

@SpringBootTest
class ApplicationTests {
    @Autowired
    private ApplicationContext context;

    @Test
    void contextLoads() {
        assertThat(context).isNotNull();
    }
}

@WebMvcTest(UserController.class)
class UserControllerTests {
    @Autowired
    private MockMvc mockMvc;

    @Test
    void getUserReturnsUser() throws Exception {
        mockMvc.perform(get("/users/1"))
            .andExpect(status().isOk());
    }
}

@JsonTest
class VehicleJsonTests {
    @Autowired
    private JacksonTester<Vehicle> json;

    @Test
    void serialize() throws Exception {
        Vehicle vehicle = new Vehicle("Honda", "Civic");
        assertThat(json.write(vehicle))
            .isEqualToJson("expected.json");
    }
}

Web & Data Access Modules

Web Frameworks

Spring Boot provides two complementary web frameworks for building HTTP applications:

Spring MVC (Servlet-based) handles traditional synchronous request-response patterns using the servlet API. It's configured through WebMvcAutoConfiguration and provides automatic setup of the DispatcherServlet, resource handlers, and view resolvers. The module depends on spring-webmvc, spring-web, and spring-boot-servlet.

Spring WebFlux (Reactive) enables fully asynchronous, non-blocking web applications using Project Reactor. It's configured through WebFluxAutoConfiguration and supports both annotation-based and functional routing styles. The module depends on spring-webflux and spring-boot-http-codec.

Both frameworks integrate with actuator endpoints, metrics, and observation for monitoring. Note: if both starters are present, Spring Boot defaults to MVC unless explicitly configured otherwise.

Data Access Modules

Spring Boot provides integrated support for multiple data access patterns:

JDBC (spring-boot-jdbc) offers low-level database access through JdbcTemplate and JdbcClient. It auto-configures connection pooling (HikariCP, Tomcat, DBCP2, Oracle UCP) and supports multiple databases including H2, PostgreSQL, MySQL, Oracle, and SQL Server.

Data JPA (spring-boot-data-jpa) builds on JDBC with ORM capabilities through Hibernate and Spring Data JPA. It auto-configures repository scanning, entity management, and transaction handling. Optionally supports Envers for audit trails.

Data MongoDB (spring-boot-data-mongodb) provides document-oriented data access through Spring Data MongoDB. It auto-configures MongoTemplate and GridFsTemplate for both synchronous and reactive operations.

All data modules follow a consistent pattern: auto-configuration discovers repositories, configures connection details, and enables transaction management.

Loading diagram...

Integration & Messaging Support

Spring Boot provides comprehensive support for multiple messaging and integration frameworks, enabling seamless communication between distributed systems. Each messaging technology is auto-configured with sensible defaults while remaining highly customizable.

Kafka Support

Kafka integration is provided through the spring-boot-kafka module, which wraps Spring Kafka with auto-configuration. The KafkaAutoConfiguration class automatically configures:

• KafkaTemplate for synchronous message production
• ConsumerFactory and ProducerFactory for managing Kafka clients
• Listener containers for consuming messages with @KafkaListener annotations
• Kafka Streams support for stream processing topologies

Key configuration properties are exposed via KafkaProperties under the spring.kafka namespace, including bootstrap servers, consumer/producer settings, listener configuration, and retry policies. The module supports multiple Kafka distributions (Apache Kafka, Confluent, Redpanda) through testcontainer integration.

AMQP & RabbitMQ

The spring-boot-amqp module provides auto-configuration for RabbitMQ messaging. RabbitAutoConfiguration sets up:

• RabbitTemplate for message publishing and RPC operations
• CachingConnectionFactory for connection pooling
• RabbitListenerContainerFactory for message consumption with @RabbitListener
• AmqpAdmin for dynamic queue/exchange creation

Configuration is managed through RabbitProperties (namespace: spring.rabbitmq). The module supports multiple listener container types (Simple, Direct, Stream) and integrates with health checks via RabbitHealthIndicator.

JMS Integration

JMS support is provided through the spring-boot-jms module, which auto-configures:

• JmsTemplate for message operations
• DefaultJmsListenerContainerFactory for listener configuration
• JmsMessagingTemplate for Spring Messaging integration
• Support for both queues and topics (pub/sub)

The module works with multiple JMS brokers through broker-specific auto-configurations: ActiveMQAutoConfiguration and ArtemisAutoConfiguration. Configuration uses JmsProperties (namespace: spring.jms).

Spring Integration

The spring-boot-integration module enables enterprise integration patterns through Spring Integration. IntegrationAutoConfiguration provides:

• Channel auto-creation and configuration
• Poller metadata for scheduled message processing
• RSocket support for reactive messaging
• Integration management with observability and logging
• JDBC message store for persistent message handling

Configuration is exposed via IntegrationProperties (namespace: spring.integration). The framework supports declarative integration flows using @Bean methods or DSL-based IntegrationFlow definitions.

Architecture Overview

Loading diagram...

Connection Details & Testcontainers

All messaging modules support Spring Boot's connection details abstraction, enabling automatic configuration from Docker Compose or Testcontainers. This allows seamless local development without manual broker setup. Each module provides factory classes for container-based connection discovery.

Health Indicators

RabbitMQ includes a built-in health indicator that reports broker version and connectivity status. JMS and Kafka health checks are available through optional dependencies, providing visibility into messaging infrastructure health.