#Note 1 - Spring Boot Fundamentals

#Study objective

Build a precise mental model of Spring Boot before studying individual features. The key question is:

What does Spring Boot add to the Spring Framework, and how does an application start, configure itself, and create its components?

#1. Spring Framework and Spring Boot

#Spring Framework

Spring Framework provides the core programming model:

• IoC (Inversion of Control)
• Dependency Injection (DI)
• ApplicationContext
• Bean lifecycle management
• AOP (Aspect-Oriented Programming)
• Web, data, transaction, security, and messaging abstractions

#Spring Boot

Spring Boot is an opinionated layer on top of Spring Framework. It reduces setup and operational work through:

• Auto-configuration
• Starter dependencies
• Embedded servers
• Externalized configuration
• Production features through Actuator
• Executable JAR packaging

Spring Boot does not replace Spring. It assembles and configures Spring components using conventions.

#2. The minimum application

@SpringBootApplication
public class Application {

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

SpringApplication.run(...) creates and starts the Spring ApplicationContext. During startup, Spring Boot:

1. Creates the application context.
2. Loads configuration.
3. Performs component scanning.
4. Applies auto-configuration.
5. Creates and wires beans.
6. Starts the embedded web server when the application is a web application.
7. Publishes application lifecycle events.

#3. @SpringBootApplication

@SpringBootApplication is a composed annotation equivalent to:

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan

#@SpringBootConfiguration

Identifies the class as a Spring Boot configuration class. It is a specialized form of @Configuration.

#@EnableAutoConfiguration

Asks Spring Boot to configure the application based on:

• Classes available on the classpath
• Existing beans
• Application properties
• Conditional rules

Auto-configuration is conditional. It backs off when the application already provides an equivalent configuration.

#@ComponentScan

Scans the package of the application class and its subpackages for components such as:

• @Component
• @Service
• @Repository
• @Controller
• @RestController
• @Configuration

Place the main application class in a root package so that application components are discovered naturally.

#4. IoC, DI, and beans

#Inversion of Control

The application does not manually construct and manage every dependency. The Spring container manages objects called beans.

#Dependency Injection

Prefer constructor injection:

@Service
public class OrderService {

    private final PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

Benefits:

• Dependencies are explicit.
• Fields can be final.
• The class is easier to test.
• Invalid construction is detected early.

#Bean

A bean is an object instantiated, configured, and managed by the Spring container. A class becomes a bean through component scanning or explicit configuration:

@Configuration
public class AppConfig {

    @Bean
    Clock clock() {
        return Clock.systemUTC();
    }
}

#5. Starters

A starter is a curated dependency descriptor. It provides a practical set of dependencies for a capability.

Examples:

• spring-boot-starter-web
• spring-boot-starter-data-jpa
• spring-boot-starter-validation
• spring-boot-starter-test

Starters reduce dependency selection, but they do not remove the need to understand transitive dependencies and version management.

#6. Auto-configuration mental model

Auto-configuration is driven by conditional configuration classes. Typical conditions include:

• A class exists on the classpath.
• A class does not exist on the classpath.
• A bean does or does not already exist.
• A property has a specific value.
• The application runs in a specific environment.

Useful diagnostic command:

java -jar app.jar --debug

The debug report shows matched and unmatched auto-configurations. Use it to explain why a bean exists or why expected configuration was not applied.

#7. Externalized configuration

Configuration should live outside compiled code when it varies by environment.

Common sources:

• application.properties
• application.yml
• Profile-specific files such as application-dev.yml
• Environment variables
• Command-line arguments
• External configuration files

Example:

server:
  port: 8081

app:
  message: hello

Bind related configuration with @ConfigurationProperties rather than scattering @Value expressions throughout the codebase.

#8. Profiles

Profiles separate environment-specific configuration and beans.

spring:
  profiles:
    active: dev

Activate a profile from the command line:

java -jar app.jar --spring.profiles.active=prod

Use @Profile("dev") when a bean should exist only in a specific environment.

#9. Embedded server and packaging

For a web application, Spring Boot can package an embedded server inside an executable JAR. The application can then run without a separately deployed application server:

./mvnw spring-boot:run
./mvnw clean package
java -jar target/app.jar

The embedded server is an implementation detail behind Spring's web abstractions. Application code should depend on those abstractions rather than server-specific APIs unless customization is required.

#10. First experiment

Create a small application that contains:

• One @SpringBootApplication class
• One @RestController
• One service injected through a constructor
• One configuration property bound with @ConfigurationProperties
• One active profile

Record the startup sequence and answer:

1. Which package does component scanning start from?
2. Which auto-configurations matched?
3. Which beans were created?
4. Which configuration source supplied each property?
5. What changes when the profile changes?

#Review checklist

• Explain the relationship between Spring Framework and Spring Boot.
• Expand @SpringBootApplication into its three annotations.
• Explain what the ApplicationContext does.
• Define IoC, DI, and bean.
• Explain how component scanning finds a service.
• Explain why auto-configuration backs off.
• Explain how configuration precedence affects a property.
• Run the auto-configuration report with --debug.
• Build and run an executable JAR.

#Next note

Note 2 - Application Context, Bean Lifecycle, and Dependency Injection

Focus on bean definitions, scopes, lifecycle callbacks, BeanPostProcessor, and constructor injection in more depth.