🚀 Spring Boot Learning Series — Episode 3 | Spring Boot

Episode 3 | Spring Boot | Auto-Configuration, Starters & How the Application Starts

Episode 1 covered why Spring exists — avoiding tight coupling. Episode 2 covered how Spring manages your app: Component Scanning finds your classes, the Spring Container creates Beans from them, and Dependency Injection wires those Beans together.

That's all Spring. Now comes the question that actually kicked off this whole series:

If Spring already does all of this, what does Spring Boot actually add on top?

That's what this episode is about — not new concepts, but the layer that makes the Episode 2 machinery easier to switch on.

🔑 Keywords → 🧠 Understand → 💡 Why? → 💻 Practice → 🎯 Interview Questions → 🛠️ Project

---

🔑 Keywords for This Episode

1. Starter Dependencies
2. Auto-configuration
3. Embedded Server (Tomcat)
4. @SpringBootApplication
5. SpringApplication.run()

---

1️⃣ Starter Dependencies

Say you're building a REST API. To do that, you actually need several separate libraries working together — one to handle incoming HTTP requests, one for REST controllers, one for converting Java objects to JSON, one to run an embedded server, and Spring's own MVC library to tie it together.

Without Spring Boot, you'd have to know each of these libraries by name, add them one by one to your build file, and make sure their versions are compatible with each other. That's easy to get wrong, and honestly, most developers building a web app need the same set of libraries every time.

Spring Boot solves this with a starter — a single dependency that pulls in a whole bundle of commonly-needed libraries for a specific type of application:

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

Add this one line, and you get Spring MVC, JSON support, and embedded server support all at once, with versions Spring Boot has already verified work together.

spring-boot-starter-web
        ↓
   Spring MVC + JSON support + embedded server support

The exact list of libraries inside a starter can change slightly between Spring Boot versions — so don't try to memorize it. Just remember the idea:

A starter is a pre-packaged, version-matched bundle of dependencies for a specific type of application, so you don't have to assemble it yourself.

---

2️⃣ Auto-Configuration

Once you've added spring-boot-starter-web, Spring Boot can see you have web-related libraries on your classpath. But having the libraries available isn't the same as having them configured — normally you'd still need to set up things like how incoming requests get routed, how JSON gets converted, and so on.

This is where auto-configuration comes in. Spring Boot looks at:

• which dependencies you've added,
• what you've already configured yourself,

and then automatically sets up the common pieces of infrastructure for you, using sensible default settings.

Add starter-web
      ↓
Spring Boot sees web-related dependencies on the classpath
      ↓
Auto-configuration kicks in
      ↓
Common web infrastructure is configured with sane defaults

Important beginner clarification: this does not mean Spring Boot configures absolutely everything for you with no say in the matter. It means Spring Boot gives you a reasonable starting point automatically — and if your application needs something different, you can still override any of it yourself. Auto-configuration is a head start, not a lock-in.

---

3️⃣ Embedded Server: Tomcat

Any web application needs something listening for incoming HTTP requests — a server. Traditionally, that server is installed and configured separately from your application code, and then your finished application is deployed onto that server.

So what actually is Tomcat? Tomcat is a Java web server and servlet container — a piece of software written to do one job: receive HTTP requests, hand them off to the right part of your Java application to process, and send the response back. It's been the default, most widely-used server for Java web apps for years, which is why Spring Boot picked it as its default embedded option (though it's not the only one — Jetty and Undertow are alternatives).

Spring Boot simplifies working with Tomcat by packaging the server inside your application itself. This is called an embedded server — instead of installing Tomcat separately and deploying your app to it, Tomcat comes bundled with your app and starts automatically when your app starts.

You run your Spring Boot app
            ↓
Spring Boot application starts
            ↓
Embedded Tomcat starts along with it
            ↓
Tomcat is now listening for HTTP requests
            ↓
Your application is reachable, usually at localhost:8080

That's why, the first time you run a Spring Boot web app, you'll see it become available on a port immediately — no separate server setup was needed. (That port number is configurable if you don't want 8080.)

One distinction that comes up often in interviews:

Spring Boot is not Tomcat. Spring Boot is the framework/tooling that simplifies building and running your application. Tomcat is just the specific embedded server it happens to bundle in for you — you could swap it for a different one (like Jetty) if you needed to.

---

4️⃣ @SpringBootApplication

Now let's look at something you'll see on literally every Spring Boot application's main class:

@SpringBootApplication
public class SupportApplication {
}

It's easy to treat this as "magic" and move on — but it's worth knowing it's not actually one single mechanism. It's really three separate Spring annotations bundled together into one:

Annotation	What it actually does
@Configuration	Marks this class as a source of Spring configuration — Spring knows to look here for setup instructions
@EnableAutoConfiguration	Switches on the auto-configuration behavior described in section 2
@ComponentScan	Tells Spring to scan your packages for classes annotated with @Component, @Service, @Repository, @Controller, @RestController, etc.

That third one, @ComponentScan, is the direct link back to Episode 2. Remember: Component Scanning is what finds your classes so the Spring Container can turn them into Beans. So @SpringBootApplication isn't introducing some new discovery mechanism — it's flipping the switch on the exact Component Scanning process from Episode 2, plus turning on auto-configuration at the same time.

In short: @SpringBootApplication = "treat this as configuration" + "auto-configure what you can" + "go find my components." One annotation, three jobs.

---

5️⃣ SpringApplication.run()

The other line you'll find in every Spring Boot app:

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

This is a completely ordinary Java main() method — the actual entry point when you run the program. Inside it, this one call is what starts your entire Spring Boot application.

Here's what happens, step by step, when it runs:

SpringApplication.run() is called
            ↓
Spring Boot starts up
            ↓
The ApplicationContext (Spring Container) is created
            ↓
Auto-configuration is applied
            ↓
Component Scanning runs and finds your classes
            ↓
Beans are created from those classes
            ↓
Dependencies are resolved and injected into each Bean
            ↓
The embedded Tomcat server starts
            ↓
Your application is fully up and ready to handle requests

This is genuinely useful to walk through slowly at least once, because it's the moment where everything from Episodes 2 and 3 actually happens — the Container, the Beans, the Dependency Injection, and the embedded server all get set in motion by this single line.

---

🧠 How Episodes 2 and 3 Connect

• Episode 2 (Spring Core) explained the underlying machinery: IoC → Spring Container → Beans → Dependency Injection.
• Episode 3 (Spring Boot) explains how that machinery gets switched on with minimal effort: Starters give you the right dependencies → Auto-configuration sets up sensible defaults → @SpringBootApplication turns on Component Scanning and auto-config → SpringApplication.run() fires off the whole startup sequence, including the embedded server.

So Spring Boot isn't a separate framework layered awkwardly on top of Spring — it's automation for the exact concepts from Episode 2.

---

🎯 Interview Check

• What problem do starter dependencies solve, and why not just add libraries individually?
• What does auto-configuration actually do — and importantly, what does it not do?
• Why is an embedded server useful for a Spring Boot app? Is Tomcat the same thing as Spring Boot?
• What are the three annotations that make up @SpringBootApplication, and which one connects back to Component Scanning?
• Walk through, step by step, what happens when SpringApplication.run() is called.

---

🛠️ Applying This to the Project

For the Employee Support / Service Request app, this episode's concepts translate directly into:

• Adding spring-boot-starter-web as a dependency
• Annotating TicketController, TicketService, and TicketRepository so Component Scanning can find them
• Letting @SpringBootApplication and SpringApplication.run() handle scanning, Bean creation, dependency injection, and starting the embedded server — with no manual wiring required from me

---