What is Spring Boot? Auto-Configuration, Starter POMs, Embedded Servers

Before Spring Boot, spinning up a Spring web app meant wrestling with XML configuration files, hunting down compatible library versions by trial and error, and writing boilerplate just to expose a single HTTP endpoint. Here is what that looked like:

<!-- web.xml - half a page of XML just to set up a Servlet -->
<servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextClass</param-name>
        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
    </init-param>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>com.example.AppConfig</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

<!-- Application config - another XML file -->
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" value="org.postgresql.Driver"/>
    <property name="url" value="jdbc:postgresql://localhost:5432/mydb"/>
    <!-- and on and on... -->
</bean>

Spring Boot replaces all of that ceremony with three ideas that work together:

• Auto-configuration figures out what your application needs and sets it up automatically
• Starter POMs pull in the right dependencies at compatible versions in a single line
• Embedded servers let you ship a runnable JAR instead of deploying to an application server

The same application in Spring Boot:

@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

@RestController
class GreetingController {
    @GetMapping("/hello/{name}")
    String hello(@PathVariable String name) {
        return "Hello, " + name + "!";
    }
}

No XML. No version hunting. Run java -jar app.jar and you have a running web server on port 8080.

Introduction to Spring Boot

Spring Boot sits on top of the Spring Framework and applies a convention-over-configuration philosophy. You get a running application without installing an external app server, without tracking down which library versions work together, and without XML wiring. Starter POMs bring in dependencies at locked versions. Health checks, metrics, and externalized configuration ship in without extra libraries.

When you add spring-boot-starter-web, Spring Boot detects Spring MVC on the classpath and spins up an embedded Tomcat, wires a DispatcherServlet, and sets up view resolution — all automatically, all without any XML or Java configuration you would have written before.

graph TB
    subgraph "Spring Boot Layer"
        A[Starter POMs] --> B[Auto-Configuration]
        B --> C[Embedded Servers]
    end
    subgraph "Spring Framework"
        D[Spring Core] --> E[Spring MVC]
        E --> F[Spring Data]
    end
    subgraph "Application"
        G[Your Code] --> B
    end
    B --> D
    B --> E
    B --> F

Spring Boot works with Maven and Gradle. Your build file declares which starters you want, and the Spring Boot Maven plugin packages everything into an executable JAR with all dependencies and a main class that runs immediately.

Auto-Configuration Deep Dive

Auto-configuration is what makes Spring Boot useful. It pokes around your environment and automatically configures beans you would otherwise have to define by hand. This happens through configuration class conditional loading.

How Auto-Configuration Works

When a Spring Boot application starts, the AutoConfigurationImportFilter examines every class on the classpath. This filter reads from META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports (Spring Boot 3.x) or the older spring.factories file (Spring Boot 2.x) to find all available auto-configuration classes.

Each auto-configuration class has conditional annotations that determine whether it should activate. Most conditions check whether a class exists on the classpath, whether a bean of a certain type already exists, or whether a property in application.properties has a particular value.

@Configuration(proxyBeanMethods = false)  // No CGLIB proxy needed for this config
@AutoConfigureAfter(DataSourceConfiguration.class)  // Run after any explicit DataSource config
@ConditionalOnClass({ DataSource.class, JdbcTemplate.class })  // Only activate if these are on the classpath
@ConditionalOnProperty(
    prefix = "spring.datasource",
    name = "enabled",
    havingValue = "true",
    matchIfMissing = true  // Activate by default if property is absent
)
public class DataSourceAutoConfiguration {

    @ConditionalOnMissingBean(type = "javax.sql.DataSource")  // Don't override user-defined beans
    @Bean
    public DataSource dataSource() {
        // Create a DataSource based on detected configuration
        // (auto-configured username, password, URL from application.properties)
    }
}

In this example, DataSourceAutoConfiguration activates only when the classpath has javax.sql.DataSource and JdbcTemplate, when no other DataSource bean exists, and when spring.datasource.enabled is not set to false.

Key Conditional Annotations

Knowing these annotations helps you debug configuration problems and turn off what you do not need:

The matchIfMissing = true attribute on @ConditionalOnProperty makes the configuration activate even when the property is absent. That is how defaults work without forcing you to set every possible option.

Disabling Auto-Configuration

When auto-configuration conflicts with what you need, you can disable specific configurations without losing the rest. The most direct way uses the exclude attribute on @SpringBootApplication:

@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })
public class MyApplication {
    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

You can also disable configurations in application.properties:

spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

This fine-grained control means you get auto-configuration for everything except the specific technologies where you need custom setup.

Starter POMs

Starter POMs solve the version compatibility problem between libraries. Each starter bundles a set of transitive dependencies at compatible versions, so you stop chasing compatibility matrices.

How Starter POMs Work

A starter POM has no code. It only declares dependencies. When you put spring-boot-starter-web in your pom.xml, you get Spring MVC, Spring Boot’s web auto-configuration, Tomcat as the default embedded server, and Jackson for JSON serialization, all at versions that have been tested to work together.

Naming follows a pattern:

• spring-boot-starter-* — Application starters for common use cases
• spring-boot-starter-test — Testing with JUnit, Mockito, AssertJ
• spring-boot-autoconfigure-* — Auto-configuration modules (usually pulled in transitively)
• spring-boot-* — Spring Boot’s own modules (actuator, devtools)

Essential Starters

Most Spring Boot projects end up using the same starters:

Core Starters:

<!-- The one that makes it Spring Boot -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
</dependency>

<!-- Web applications (includes Tomcat) -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<!-- Reactive web applications -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

<!-- Bean validation -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-validation</artifactId>
</dependency>

Data Starters:

<!-- JPA with Hibernate -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

<!-- MongoDB -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency>

<!-- Redis -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

Security and Ops:

<!-- Authentication and authorization -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

<!-- Production-ready monitoring -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Choosing the Right Starter

When you are not sure which starter to add, work backwards from what your application should do:

1. Need HTTP endpoints? → spring-boot-starter-web (or spring-boot-starter-webflux for reactive)
2. Need to store data in a relational database? → spring-boot-starter-data-jpa plus a driver (spring-boot-starter-data-jpa brings Hibernate, you add postgresql or mysql driver)
3. Need to secure those endpoints? → Stack spring-boot-starter-security on top
4. Need to validate input data? → Add spring-boot-starter-validation
5. Need visibility into what is happening at runtime? → Add spring-boot-starter-actuator

spring-boot-starter alone gives you auto-configuration, property support, and the Spring Boot CLI. Build from there.

Embedded Servers

Before embedded servers, deploying a Java web app meant installing an application server (Tomcat, Jetty, WildFly), configuring it through XML, and dropping a WAR file into it. Spring Boot changed that by bundling the servlet container inside your application JAR.

How Embedded Servers Work

When you include spring-boot-starter-web, Spring Boot’s auto-configuration detects an embedded servlet container and creates the beans needed to start it. The EmbeddedServletContainerAutoConfiguration class activates based on which server is on the classpath, and each server (Tomcat, Jetty, Undertow) has its own auto-configuration class.

Your code still uses the standard Servlet API without changes. What changes is that the server lifecycle (start, stop, port binding) is managed by Spring Boot instead of an external container.

graph LR
    A[Application JAR] --> B[Main Method]
    B --> C[Spring Boot Auto-configuration]
    C --> D[Embedded Server]
    D --> E[Servlet Container]
    E --> F[DispatcherServlet]
    F --> G[Your Controllers]

Tomcat, Jetty, and Undertow Comparison

Each embedded server has its own character. Tomcat is the default because it needs no extra native dependencies and works everywhere, but the other two make sense in specific situations.

To swap Tomcat for Jetty, exclude Tomcat and add Jetty in your pom.xml:

<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-jetty</artifactId>
</dependency>

For Undertow, use spring-boot-starter-undertow instead.

Server Configuration

All three servers share common configuration properties. Put these in application.properties:

# Port (default: 8080)
server.port=8080

# Context path (default: /)
server.servlet.context-path=/api

# Compression
server.compression.enabled=true
server.compression.mime-types=text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json

# Connection timeout (milliseconds)
server.connection-timeout=20000

# Max threads
server.tomcat.threads.max=200
server.tomcat.threads.min-spare=10

Tomcat-specific tuning:

server.tomcat.max-connections=10000
server.tomcat.accept-count=100
server.tomcat.max-keep-alive-requests=100

When to Use Spring Boot

Spring Boot works well when you need to ship working software fast without giving up production-readiness. It pays off most for services that will stick around and need maintenance over years, not throwaway prototypes.

Strong Fit:

• RESTful API services, especially with multiple endpoints needing consistent error handling
• Microservices where each service deploys and scales independently
• Applications persisting data to relational databases with JPA or Spring Data
• Services that need authentication and authorization
• Any project where you want production-ready observability without extra setup

Weaker Fit:

• Batch jobs on a schedule with no HTTP interface — look at Spring Batch instead
• Applications with extreme memory constraints where even 15MB is too much — consider something leaner or the raw Servlet API
• Teams already invested in a different ecosystem where Java is not already in the stack

Common Pitfalls

Spring Boot reduces complexity but brings its own traps for developers who have not seen it before.

Over-relying on auto-configuration. It is a useful default, but it hides what is actually happening. When something breaks, developers who do not understand the underlying Spring concepts struggle to figure out why.

Ignoring the classpath. Starters pull in so many transitive dependencies that it is easy to end up with conflicting libraries. If you see strange NoSuchMethodError or ClassNotFoundException at runtime, run mvn dependency:tree to see exactly which versions landed on the classpath.

Forgetting to externalize configuration. Hardcoded values work in development and break in production. Use application.properties, environment variables, or a configuration server. Spring Boot’s relaxed binding maps environment variables like DATABASE_HOST to properties like spring.datasource.host.

Using default datasource settings in production. The embedded H2 database is convenient for development but has no business in production. Always configure an external database and tune your connection pool settings (HikariCP is the default) for your expected load.

Not disabling security in tests. Once you add spring-boot-starter-security, every endpoint requires authentication by default. Use @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) with @AutoConfigureMockMvc or explicitly configure security for tests.

Security Notes

Security in Spring Boot comes through spring-boot-starter-security, which sets up a baseline that protects all endpoints except /actuator/health. The default uses HTTP Basic authentication with a generated password printed to the console on startup.

Hardening steps for any Spring Boot application:

Change the default user and password in application.properties:

spring.security.user.name=admin
spring.security.user.password=<use-a-strong-password-manager>

Or skip the default user entirely and use a real user details service:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public UserDetailsManager userDetailsManager(DataSource dataSource) {
        return new JdbcUserDetailsManager(dataSource);
    }
}

For production, use OAuth2 or JWT instead of session-based auth. The spring-boot-starter-oauth2-resource-server starter makes the configuration straightforward:

spring.security.oauth2.resourceserver.jwt.issuer-uri=https://your-issuer.com

Dependency scanning should run in your CI pipeline. The OWASP Dependency Check Maven plugin looks for known vulnerabilities in your dependencies:

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>9.0.0</version>
</plugin>

Spring Boot’s release train means the team maintains security patches for older versions, but that does not cover vulnerabilities in third-party libraries.

Implementation Snippets

Minimal Project Structure

A Spring Boot project needs very little to get going. After the Maven pom.xml, you only need the application class and an optional application.properties.

src/
  main/
    java/
      com/
        example/
          demo/
            DemoApplication.java      # Main class with @SpringBootApplication
    resources/
      application.properties         # Configuration
  test/
    java/
      com/
        example/
          demo/
            DemoApplicationTests.java # Basic test
pom.xml

Minimal pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.3.0</version>
    </parent>

    <groupId>com.example</groupId>
    <artifactId>demo</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <properties>
        <java.version>17</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

Main Application Class

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

@SpringBootApplication is a composite annotation that combines @Configuration, @EnableAutoConfiguration, and @ComponentScan. You almost never need to write these separately.

A Simple REST Controller

package com.example.demo;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class GreetingController {

    @GetMapping("/hello/{name}")
    public String hello(@PathVariable String name) {
        return "Hello, " + name + "!";
    }
}

Component scanning registers this controller automatically. No web.xml, no extra configuration needed. Run the app and curl localhost:8080/hello/World gives you Hello, World!.

Observability Checklist

Spring Boot Actuator gives you production-ready monitoring out of the box. Add the starter and you get health endpoints, metrics, and environment information out of the box.

Add the actuator starter:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Configure what Actuator exposes:

# Health endpoint details (default: never)
management.endpoint.health.show-details=when_authorized

# Enable specific endpoints
management.endpoints.web.exposure.include=health,info,metrics,env,beans

# Health check customizations
management.health.livenessState.enabled=true
management.health.readinessState.enabled=true

# Metrics export (Prometheus format)
management.prometheus.metrics.export.enabled=true

What to monitor in production:

• GET /actuator/health — Overall application health, pair with Kubernetes liveness/readiness probes
• GET /actuator/metrics/http.server.requests — HTTP request timing, error rates
• GET /actuator/metrics/jvm.memory.used — Memory pressure early warning
• GET /actuator/info — Build information including git commit SHA for traceability
• GET /actuator/beans — All Spring beans (useful in development, restrict in production)

Correlation IDs link logs across service calls. Add a filter that extracts or generates a correlation ID and puts it in the MDC:

@Component
public class CorrelationIdFilter extends OncePerRequestFilter {

    private static final String CORRELATION_ID_HEADER = "X-Correlation-ID";

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain filterChain)
            throws ServletException, IOException {
        String correlationId = request.getHeader(CORRELATION_ID_HEADER);
        if (correlationId == null) {
            correlationId = UUID.randomUUID().toString();
        }
        MDC.put("correlationId", correlationId);
        response.setHeader(CORRELATION_ID_HEADER, correlationId);
        filterChain.doFilter(request, response);
    }
}

Trade-off Table

Auto-Configuration Pros and Cons

Embedded Server Comparison

Failure Scenarios

Application starts but returns 404 on all endpoints. Usually a missing @RestController or @RequestMapping. Check that your controller has the annotations and lives in a package Spring Boot’s component scan covers (by default, the main class’s package and everything under it).

Bean creation fails with “required a bean of type X not found.” Auto-configuration did not activate for whatever provides X. Verify the right starter is on the classpath, its conditions are met, and you have not accidentally excluded its auto-configuration class.

OutOfMemoryError: PermGen space or Metaspace. Shows up with Spring Boot 1.x on HotSpot JVM. Spring Boot 2+ uses Metaspace by default. Fix by setting -XX:MaxMetaspaceSize=256m (tune as needed) and make sure you are not leaking classloaders through dynamic classloading.

Embedded server fails to start on port 8080. Port conflicts happen often in shared dev environments. Set server.port=0 to let Spring Boot pick an available port, or use the SERVER_PORT environment variable.

App works locally but fails in production with DataSource errors. Production typically uses a different database than H2. Verify spring.datasource.url is set correctly for production, credentials are externalized and not in source control, and the database driver JAR is in the packaged app.

ClassNotFoundException at runtime with AOT compilation. Spring Boot 3.x with GraalVM native image compilation has limits. Not all Spring features work in AOT mode. Test your native image build in CI before betting on it.

Interview Questions

logging.level.org.springframework.boot.autoconfigure=DEBUG

@ConditionalOnBean(type = "DataSource.class")
// Activates ONLY if a DataSource bean already exists

@ConditionalOnMissingBean(type = "DataSource.class")
// Activates ONLY if NO DataSource bean exists

// Spring MVC — blocking
@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    return userRepository.findById(id);  // thread blocks here
}

// WebFlux — non-blocking
@GetMapping("/users/{id}")
public Mono<User> getUser(@PathVariable Long id) {
    return userRepository.findById(id);  // returns immediately, data comes async
}

spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=admin

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/mydb
    username: admin

spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=admin
spring.datasource.password=secret
spring.datasource.driver-class-name=org.postgresql.Driver

spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.connection-timeout=30000

@Configuration
public class DataSourceConfig {
    @Bean
    public DataSource dataSource() {
        return new HikariDataSource(myCustomConfig());
    }
}

{
  "timestamp": "2024-11-15T14:30:00Z",
  "status": 500,
  "error": "Internal Server Error",
  "message": "Division by zero",
  "path": "/api/calculate"
}

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleNotFound(ResourceNotFoundException ex) {
        return ResponseEntity
            .status(HttpStatus.NOT_FOUND)
            .body(new ErrorResponse("NOT_FOUND", ex.getMessage()));
    }
}

@SpringBootApplication(exclude = {
    DataSourceAutoConfiguration.class,
    SecurityAutoConfiguration.class
})
public class MyApplication { ... }

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
</dependency>

management.endpoints.web.exposure.include=health,info,metrics,beans,env
management.endpoint.health.show-details=when_authorized

@Component  // Generic component — use for utilities, helpers, anything not fitting the others
public class StringUtils { ... }

@Service   // Business logic layer — marks a class as holding business rules
public class OrderService { ... }

@Repository  // Data access layer — marks a class as interacting with a database
public class UserRepository { ... }

# 1. application.properties inside the JAR (defaults — never change this)
# 2. application-{profile}.properties on the classpath (e.g., application-prod.properties)
# 3. application-{profile}.yml on the classpath
# 4. OS environment variables
# 5. command-line arguments

java -jar app.jar --spring.profiles.active=prod
# or
SPRING_PROFILES_ACTIVE=prod java -jar app.jar

spring.datasource.password=${DB_PASSWORD}
spring.security.oauth2.resourceserver.jwt.issuer-uri=${AUTH_ISSUER_URI}

@ConditionalOnMissingBean(DataSource.class)  // Gate: only register if no existing bean
@Bean
public DataSource dataSource() {
    return new HikariDataSource(...);  // This BeanDefinition goes into the factory
}

@Configuration
public class AppConfig {
    @Bean
    public DataSource dataSource() {
        return new HikariDataSource();  // Returns the SAME bean from the factory
    }

    @Bean
    public JdbcTemplate jdbcTemplate(DataSource ds) {
        // Spring intercepts this and passes the registered DataSource bean, not a new one
        return new JdbcTemplate(ds);
    }
}

Further Reading

• RESTful API Design — designing clean REST interfaces that work well with Spring Boot controllers
• Spring Framework Core — understanding @Component, @Bean, and the container Spring Boot builds on
• REST Controller and Request Mapping — hands-on endpoint mapping with Spring Boot
• Spring Security Fundamentals — authentication and authorization patterns
• Spring Boot Documentation — official reference documentation
• Auto-Configuration in Depth — how the conditional loading system actually works
• Spring Boot Actuator — production-ready monitoring and health endpoints
• Containerizing Spring Boot with Docker — packaging applications as Docker images

Conclusion

Spring Boot came about because setting up a Spring project used to take days — XML configs everywhere, version conflicts, hunting for which library versions actually worked together. Starters, auto-configuration, and embedded servers fixed those three problems specifically. The defaults cover most of what you need in production, so you only configure what is different about your project.

From here, the fastest path forward is spring-boot-starter-web plus one of the linked tutorials. If you want more depth, auto-configuration conditions or the actuator endpoints are worth running to ground in a real project.