Spring Boot

What it is and why it exists

Spring Boot is an application framework built on the Spring Framework. Spring supplies the container, dependency injection, web stack, transactions, and other programming models; Boot decides how to assemble common combinations from the libraries and settings present in an application. The result is still a Spring application, not a separate replacement for Spring.

The problem it solves is integration setup. A servlet API, JSON mapper, validation provider, server, logging system, and metrics registry each have their own lifecycle and configuration. Boot supplies conditional defaults for known combinations, while leaving application code free to replace specific parts. This is more precise than saying that Boot “requires no configuration.”

Auto-configuration contributes configuration when its conditions match. A servlet web application appears when the required web classes are on the classpath; a default component can back away when the application defines its own Spring bean . The conditions make defaults contextual rather than universal.

A starter dependency is a curated dependency descriptor for one capability, such as Spring MVC or Actuator. It keeps a compatible group of libraries together and lets Boot manage their versions. A starter is not a module switch: classpath contents make configurations eligible, while conditions and properties decide what is actually created.

Boot applications run through an application context , the Spring container that owns bean definitions and instances. Dependency injection connects those instances, normally through constructors. Controllers, services, configuration objects, and infrastructure adapters therefore share one explicit object graph.

Boot also turns configuration into deployment input. Externalized configuration can come from packaged files, profile-specific files, environment variables, system properties, command-line arguments, and other property sources. The application artifact can stay unchanged while ports, endpoints, credentials, and feature choices vary by environment.

You meet Spring Boot in HTTP services, batch jobs, message consumers, command-line applications, and larger modular systems. It is a good fit when Spring integrations reduce more work than the container and startup model add. A tiny function or service that needs no Spring features may have a simpler runtime and test boundary without it.

Spring Security, Spring Data, messaging, containers, and orchestration are separate concerns built on top of this core. Adding every starter to an initial project hides which dependency caused which behavior. Learn the context, conditions, configuration, web boundary, and test boundary first; add an integration only when a requirement names it.

How it works

SpringApplication.run() builds an environment, chooses an application-context type, loads bean definitions, refreshes the context, and starts the selected runtime. In a servlet application, the refresh creates the web infrastructure and embedded server. Startup either produces one coherent context or fails; a half-bound configuration object should not survive into request handling.

@SpringBootApplication is a convenience annotation combining @SpringBootConfiguration, @EnableAutoConfiguration, and @ComponentScan. The first identifies the primary configuration, the second imports Boot’s auto-configuration candidates, and the third discovers application components. Those three jobs are related but have different failure modes.

The package of the application class is the default search root. Placing it in com.example.catalog includes subpackages such as com.example.catalog.web and com.example.catalog.service. Putting it in a feature subpackage can silently omit siblings; putting it in the unnamed default package can make scanning unreasonably broad.

Auto-configuration candidates declare conditions over classes, beans, properties, resources, and application type. Boot evaluates those conditions while building the context. Matching configuration registers bean definitions; a failed condition explains why a configuration did not apply rather than representing an application error.

Defaults that back away

Boot’s defaults are non-invasive at the bean boundary. For example, an auto-configuration guarded by @ConditionalOnMissingBean contributes its default only if the relevant bean is absent. Defining an application bean can therefore replace one part without disabling unrelated web, JSON, or metrics configuration.

Back-off is type- and condition-specific. Adding a bean that looks conceptually similar does not prove that it satisfies the exact condition, and defining two beans of an injectable type may create an ambiguity instead of an override. Read the condition report and the configuration’s documented extension points before adding exclusions.

Run with --debug when startup behavior is surprising. Boot logs a conditions evaluation report that separates positive and negative matches. With Actuator deliberately exposed and secured, the conditions endpoint can provide related runtime evidence; it should not be made public merely for convenience.

Bean ownership and injection

A bean definition tells the context how to obtain an object and what lifecycle rules apply. The default scope is one instance per application context, often called singleton scope. It does not mean one instance across every context, test, or JVM, and it provides no automatic thread safety for mutable state.

Constructor injection makes required dependencies visible and lets the container reject an incomplete graph during startup. A single constructor needs no @Autowired. Field injection hides requirements until reflection fills them, makes ordinary construction awkward, and encourages tests that bypass the same lifecycle production uses.

Component stereotypes such as @RestController, @Service, and @Configuration make classes eligible for specific roles. A @Bean method is useful when construction needs code or the type comes from a third-party library. Neither mechanism should turn the context into a service locator fetched from business methods.

Configuration binding and precedence

Boot considers property sources in a defined order, with later sources able to override earlier ones. Command-line arguments outrank operating-system environment variables, and those outrank packaged configuration data. An override is useful only if operators and tests know which source won, so record the effective non-secret configuration needed to diagnose a deployment.

@ConfigurationProperties binds a related property namespace to a structured object. Relaxed binding maps catalog.page-size to an environment variable such as CATALOG_PAGE_SIZE, while validation annotations can reject missing or out-of-range values at startup. This is safer for a group of settings than scattering string keys and conversions across @Value fields.

Profiles select sets of configuration and beans; they do not create a security boundary. A secret committed to application-prod.properties remains a committed secret. Supply sensitive values through the deployment’s secret mechanism, make required values fail closed, and avoid plausible development defaults for production credentials.

The HTTP path

With the Spring MVC starter present, Boot configures the dispatcher servlet, message converters, validation integration, error handling infrastructure, and an embedded servlet container. A request reaches the server, passes filters, is mapped to a controller method, invokes application services, and has its return value converted into an HTTP response. Each step is a contract boundary, not hidden magic.

Returning a Java record can produce JSON because a compatible JSON mapper and message converter are on the classpath. That does not define authorization, transactionality, status semantics, or a stable public schema. The controller must still validate transport input, call a service with explicit domain rules, and return the statuses and fields promised by the API contract.

Examples

These three examples form one small catalog project generated by Spring Initializr with Maven, Java, Spring Boot 4.1.1, Spring Web MVC, Validation, and Actuator. They were compiled and executed with the generated Maven wrapper and local OpenJDK 21.0.12; the source uses APIs and language features valid for the target Java 25 LTS. The displayed output is from those runs.

Starting a JSON endpoint

The application class supplies the configuration root and executable entry point. The adjacent controller is discovered by component scanning, and Boot configures the server and JSON conversion because the Spring MVC starter is present.

The response proves routing and conversion for one happy path. It does not prove that the SKU exists, that the caller may see it, or that priceInCents is the intended public representation. Those rules belong in a service and the API contract rather than in assumptions attached to auto-configuration.

The server started on the default port because no override was supplied. A real deployment should set the port and proxy behavior explicitly where they differ, then test through the deployed ingress. An embedded server removes the external WAR deployment step; it does not remove the network boundary.

Binding validated settings

The next file registers a typed configuration object and prints its effective values after the context starts. @Validated applies Jakarta Validation constraints during binding, so invalid configuration stops startup before the runner or an HTTP handler can use it.

package com.codewiki.catalog;

import jakarta.validation.constraints.Max;
import jakarta.validation.constraints.Min;
import jakarta.validation.constraints.NotBlank;
import org.springframework.boot.ApplicationRunner;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.validation.annotation.Validated;

@ConfigurationProperties("catalog")
@Validated
record CatalogSettings(
        @NotBlank String currency,
        @Min(1) @Max(100) int pageSize) {}

@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties(CatalogSettings.class)
class CatalogConfiguration {
    @Bean
    ApplicationRunner showSettings(CatalogSettings settings) {
        return args -> System.out.printf(
                "catalog currency=%s pageSize=%d%n",
                settings.currency(), settings.pageSize());
    }
}

catalog currency=EUR pageSize=24

The run set CATALOG_CURRENCY=EUR and CATALOG_PAGE_SIZE=24, then selected a non-web application so it could exit after the runner. The environment variable names demonstrate relaxed binding. Packaged defaults of catalog.currency=USD and catalog.page-size=20 were overridden by the environment.

Printing selected non-secret settings can make precedence diagnosable. Never dump the entire environment or configuration-property endpoint into logs: it may contain passwords, tokens, internal hosts, and personal data. Treat redaction and endpoint access as part of the operational contract.

Testing the configured web boundary

This test starts the Boot context without a listening server and attaches MockMvc to the configured Spring MVC stack. It asserts status, compatible media type, and one field before printing the response. The Boot 4 import path for AutoConfigureMockMvc is intentionally shown.

package com.codewiki.catalog;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.webmvc.test.autoconfigure.AutoConfigureMockMvc;
import org.springframework.test.web.servlet.MockMvc;

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

@SpringBootTest
@AutoConfigureMockMvc
class CatalogApplicationTests {
    @Autowired
    MockMvc mvc;

    @Test
    void returnsAProduct() throws Exception {
        var response = mvc.perform(get("/products/KB-1"))
                .andExpect(status().isOk())
                .andExpect(content().contentTypeCompatibleWith("application/json"))
                .andExpect(jsonPath("$.sku").value("KB-1"))
                .andReturn().getResponse();

        System.out.println(response.getStatus() + " " + response.getContentAsString());
    }
}

200 {"sku":"KB-1","name":"Mechanical keyboard","priceInCents":12900}

MockMvc covers controller mapping, configured filters, argument resolution, and message conversion without a socket. It does not prove servlet-container behavior, TLS, proxy headers, or the packaged artifact. Add a random-port test or a deployed smoke test when those layers are part of the risk.

The full context makes this a useful wiring test but loads more than a focused web slice. Use a slice when its omitted collaborators are replaced deliberately and another test proves complete startup. Choose the smallest test that answers the question without pretending omitted layers were exercised.

Pitfalls

Scanning the wrong package tree

Fix: put the application class in a named root package above application components, or declare scan packages explicitly when the module layout requires it. Keep a context test that resolves a representative controller and service, and treat scan-boundary changes as behavioral changes.

Treating starters as harmless conveniences

Fix: add one capability for one requirement and inspect the dependency graph. After each starter, check the condition report, startup logs, exposed ports, and endpoints. Remove direct versions for artifacts managed by the selected Boot release unless a documented compatibility need justifies them.

Fighting auto-configuration blindly

Fix: identify the exact condition and documented replacement type first. Define the narrow application bean or property that triggers back-off, then rerun the context and condition report. Reserve exclusions for cases where the whole auto-configuration is intentionally inapplicable.

Accepting malformed configuration

Fix: group related settings under @ConfigurationProperties, use domain types such as Duration, apply validation constraints, and test valid, missing, and boundary values. Do not give secrets or dangerous production settings plausible fallbacks merely to make local startup green.

Exposing Actuator as an afterthought

Fix: expose only named endpoints, separate exposure from access control, and enforce the boundary with Spring Security, a management network, or both. Verify anonymous and operator access through the real proxy. Keep health details minimal unless the caller is authorized to see dependencies.

Confusing one test style with complete evidence

Fix: map risks to layers. Keep plain unit tests for business logic, a focused slice for transport behavior, a full context test for wiring, and a small random-port or deployed suite for the real network edge. Assert failures and stored side effects, not only a successful status.

Further reading

• Spring Boot system requirements
• Spring Boot auto-configuration
• Spring Boot externalized configuration
• Spring Boot servlet web applications
• Spring Boot testing
• Spring Boot Actuator endpoints