Skip to main content

1.2 Spring Boot Architecture & Starters

← Back to Chapter 1: Spring & Spring Boot Fundamentals

Prior to Spring Boot, creating a production-grade enterprise Spring application required hundreds of lines of boilerplate XML/Java configuration, intricate dependency version compatibility matrices, and external servlet container deployment (WAR files inside Tomcat or JBoss). Spring Boot transformed this paradigm into a rapid, opinionated, and container-friendly workflow.

What is Auto-Configuration?​

Spring Boot tries to automatically configure your application based on:

Dependencies present in the classpath
Application configuration
Existing Beans

For example, if you add:

spring-boot-starter-web

Spring Boot detects web-related dependencies and configures the application for web development.

If you add:

spring-boot-starter-data-jpa

and configure a database, Spring Boot can automatically configure much of the JPA/database infrastructure.

Simple example

You add:

spring-boot-starter-web

Spring Boot essentially says:

This application appears to be a web application, so I'll configure the required web infrastructure.

That's auto-configuration.

1. Spring Boot additional feature​

Spring Boot does not replace the Spring Framework; rather, it is an opinionated layer built on top of Spring Framework that embraces Convention over Configuration:

  • Auto-Configuration: Automatically configures sensible defaults based on jars detected on the application classpath.
  • Embedded Containers: Packages runtime containers (Tomcat, Jetty, Undertow) directly inside executable JARs, removing external servlet container installations.
  • Curated Starter Dependencies: Aggregates verified, mutually compatible dependency sets into unified coordinates.
  • Production Metrics Out of the Box: Native support for health checks, telemetry, metrics, and externalized environment profiles.

2. Different types of Starter Dependency​

Starters are descriptor POMs that encapsulate a complete bundle of transitively compatible libraries required for a specific capability.

  • spring-boot-starter-web: Pulls Spring MVC, Jackson (JSON serialization), Hibernate Validator, and embedded Apache Tomcat.
  • spring-boot-starter-data-jpa: Pulls Hibernate ORM, Spring Data JPA abstractions, HikariCP connection pool, and JDBC support.
  • spring-boot-starter-security: Pulls Spring Security Core, Web filter chains, and cryptographic password encoders.
  • spring-boot-starter-actuator: Pulls health monitoring, JVM metrics, and management HTTP endpoints.
  • spring-boot-starter-test: Pulls JUnit 5 Jupiter, Mockito, AssertJ, Hamcrest, and Spring Test context runners.
<!-- Example: Single web starter replaces 15+ individual library coordinates -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Naming Rule: Official Spring Boot starters always use the pattern spring-boot-starter-*. Third-party community starters must use the pattern *-spring-boot-starter (e.g., mybatis-spring-boot-starter).

3. Embedded Web Servers​

Traditional Java Web applications produced .war archives deployed to standalone app server clusters. Spring Boot flips the model by embedding the servlet container directly into the .jar:

Traditional:   [ Standalone Tomcat Server ] ──loads──> [ your-app.war ]
Spring Boot:   [ your-app.jar (contains Embedded Tomcat + Java Code) ] ──runs──> java -jar

Switching Embedded Servers​

By default, spring-boot-starter-web uses Apache Tomcat. You can swap to Undertow or Jetty by excluding Tomcat:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>