DEV Community: Shreya Karka

🚀 Spring Boot Learning Series — Episode 3 | Spring Boot

Shreya Karka — Fri, 28 Aug 2026 19:14:18 +0000

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

Starter Dependencies
Auto-configuration
Embedded Server (Tomcat)
@SpringBootApplication
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

🌱 Spring Boot Learning Series — Episode 2 | Spring Core

Shreya Karka — Fri, 28 Aug 2026 18:36:10 +0000

Episode 2 | Spring Core | Understanding IoC, Dependency Injection & Beans

In Episode 1, I covered the WHY behind Spring — tight coupling, and how Spring takes over creating and providing objects (IoC + DI) instead of classes creating their own dependencies.

This episode picks up from there with the parts I hadn't covered yet: how Spring actually does that under the hood — Beans, the Spring Container, and Component Scanning.

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

🔑 Keywords for This Episode

IoC & Dependency Injection (quick recap)
Spring Bean
Spring Container / ApplicationContext
Component Scanning

1️⃣ Quick Recap: IoC & Dependency Injection

From Episode 1: instead of a class creating its own dependency —

public class TicketService {
    private TicketRepository repository;

    public TicketService() {
        repository = new TicketRepository();
    }
}

— Spring creates the dependency and hands it to the class. That's Inversion of Control (IoC).

In code, this usually looks like a constructor parameter:

public class TicketService {
    private final TicketRepository repository;

    public TicketService(TicketRepository repository) {
        this.repository = repository;
    }
}

TicketService no longer says "let me create a TicketRepository." It says "I need a TicketRepository" — and Spring supplies one. That act of supplying it is Dependency Injection (DI).

IoC = who's in control of creating/managing objects → Spring.
DI = how a class actually receives what it needs → passed in, not self-created.

That's the recap. Now — where do these objects Spring creates actually come from, and where do they live?

2️⃣ Spring Bean — what Spring actually manages

When Spring creates and manages an object for you, that object is called a Bean. This is the vocabulary you'll see everywhere in Spring code and docs, so it's worth being precise about it.

@Service
public class TicketService {
}

The @Service annotation is a signal to Spring: "this class should be managed by you." When Spring creates an object from this class, that specific object — the one Spring created and is tracking — is a Bean.

Compare that to doing it yourself:

TicketService service = new TicketService();

This service object is a completely ordinary Java object. Spring has no idea it exists. It's not a Bean — Spring can't inject it anywhere, manage its lifecycle, or wire its dependencies, because Spring never created it and doesn't know about it.

So the distinguishing line is simple:

A Spring Bean isn't a special kind of class — it's an object that Spring itself created and is managing. The exact same class can produce a Bean (if Spring creates it) or a plain object (if you create it with new).

This matters because dependency injection only works on Beans. If TicketRepository isn't a Bean, Spring has nothing to inject into TicketService.

3️⃣ Spring Container (a.k.a. ApplicationContext)

So Beans need to be created and tracked somewhere. That "somewhere" is the Spring Container — in practice, you'll most often see it called the ApplicationContext, which is Spring's concrete implementation of the container.

Concretely, the Container is responsible for:

Creating Bean instances (calling the constructor, essentially)
Storing references to every Bean it creates, so it can find them again
Figuring out each Bean's dependencies — e.g. it sees TicketService needs a TicketRepository
Injecting those dependencies — passing the right Bean into the right constructor
Managing the Bean's lifecycle — when it's created, and when it's cleaned up when the app shuts down

Here's the flow when your app starts:

App starts
     ↓
Spring Container starts up
     ↓
Container creates TicketRepository Bean
     ↓
Container creates TicketService Bean
     ↓
Container sees TicketService needs a TicketRepository
     ↓
Container injects the TicketRepository Bean into TicketService

You never call new TicketService(new TicketRepository()) yourself — the Container does this wiring for the entire application, for every Bean, automatically.

Spring Container / ApplicationContext = the running system inside your app that creates every Bean, keeps track of them, and wires their dependencies together.

4️⃣ Component Scanning — how the Container finds classes to manage

This raises an obvious question: the Container can't manage a class it doesn't know exists. So how does it discover TicketService in the first place?

That's Component Scanning. When your Spring app starts, Spring scans your project's packages looking for classes marked with specific annotations:

@Component   — generic, "let Spring manage this"
@Service     — for service/business-logic classes
@Repository  — for data-access classes
@Controller / @RestController — for web-layer classes

These are all technically variations of @Component — Spring treats them the same way for scanning purposes, they just also carry extra meaning (e.g. @Repository also tells Spring to translate database exceptions).

Concretely, the process looks like this:

Spring app starts
        ↓
Component Scanning runs
        ↓
Scans your packages for @Component-annotated classes
        ↓
Finds @Service TicketService
        ↓
Registers it as a component Spring should manage
        ↓
Spring Container creates a Bean from it

Without Component Scanning finding the class first, none of the rest happens — the Container can only create and inject Beans for classes it has actually discovered and registered.

Component Scanning finds the classes. The Container creates and wires the Beans. Two separate jobs, both needed.

🧠 Putting It All Together

Component Scanning finds @Component classes
              ↓
Spring Container creates a Bean for each one
              ↓
Container figures out each Bean's dependencies
              ↓
Container injects those dependencies (DI)
              ↓
Your classes never had to create anything themselves (IoC)

That's the full picture: IoC is the principle (Spring is in control), DI is how a class receives what it needs, Beans are what gets created and managed, the Container is where that happens, and Component Scanning is how the Container finds what to manage.

🎯 Interview Check

What is a Spring Bean, and how is it different from a plain Java object created with new?
What is the Spring Container (ApplicationContext) actually responsible for?
How does Spring discover which classes should become Beans?
If a class isn't found by Component Scanning, can it still be injected as a dependency? Why not?
What's the relationship between @Component, @Service, @Repository, and @Controller?

🛠️ Applying This to the Project

Time to take this out of theory. In the Employee Support / Service Request app, I'll annotate the classes:

@RestController TicketController
@Service TicketService
@Repository TicketRepository

and let Component Scanning + the Container find them, create their Beans, and wire the dependencies — instead of me creating any of it manually.

📌 Next Episode — Spring Boot

With the Spring Core foundation in place, next I'll move into the Spring Boot side:

Auto-configuration
Starter Dependencies
Embedded Server / Tomcat
@SpringBootApplication
SpringApplication.run()

Understand → Practice → Interview → Build.
One concept at a time. One project throughout the journey.

🚀 Spring Boot Learning Series — Episode 1

Shreya Karka — Fri, 28 Aug 2026 06:24:15 +0000

Episode 1 | Spring vs Spring Boot — The Foundation

I'm starting a Spring Boot learning series where I'll follow this approach:
🔑 Keywords → 🧠 Understand → 💡 Why? → 💻 Practice → 🎯 Interview Questions → 🛠️ Project

For Episode 1, I started with the most basic question:

👉 What is Spring, and why do we need Spring Boot?

🔑 Keywords for This Episode

Spring Framework
Spring Boot
Tight Coupling
Loose Coupling
Dependency
IoC — Inversion of Control
Dependency Injection
Bean

1️⃣ What Is Spring Framework?

Spring Framework is a Java framework used to build applications, especially backend and enterprise applications.
But simply saying "Spring is a Java framework" doesn't really explain why we use it.
The better question is:

👉 Why do we need Spring?
Let's take a simple example from the application I'll be building while learning Spring Boot: an Employee Support / Service Request application.

A simplified structure might look like:

\TicketController ↓ TicketService ↓ TicketRepository ↓ Database \\

Here, TicketService needs TicketRepository to perform its job.
In plain Java, we could create that object ourselves:

\java TicketRepository repository = new TicketRepository(); \\

This works perfectly fine for a small application.
But as an application grows, we can have hundreds of classes, and many classes may depend on other classes.
If every class is responsible for creating the objects it needs, the classes become strongly connected to their dependencies.
This is called:

🔴 Tight Coupling

2️⃣ What Is Tight Coupling?

Consider:

\TicketService ↓ creates ↓ TicketRepository \\

TicketService is directly responsible for creating TicketRepository.
Now imagine we want to:

Change the implementation
Replace the dependency
Use a mock repository for testing Because TicketService directly creates it, making those changes becomes harder. This is where: ### 🟢 Loose Coupling becomes important. We want a class to focus on: > "What do I need?" rather than: > "How do I create everything I need?"

3️⃣ How Does Spring Help?

Spring helps us manage objects and their dependencies.
Instead of:

\TicketService ↓ creates ↓ TicketRepository \\

we can have:

\Spring ↓ creates & manages ↓ TicketRepository ↓ provides it to ↓ TicketService \\

This leads us to two important Spring concepts:

🔹 IoC — Inversion of Control
🔹 Dependency Injection IoC means the responsibility for creating and managing objects is moved from our classes to Spring. Dependency Injection is how Spring provides the dependencies that a class needs. So the basic idea is:

\Our classes need objects ↓ Spring manages those objects ↓ Spring provides them where needed ↓ Classes become more loosely coupled \\

I'll dive deeper into these concepts in the next episode.

🫘 What Is a Spring Bean?

A Bean is simply an object that is created and managed by the Spring Container.
For example, if Spring creates and manages a TicketService object, that object is a Spring Bean.
Think of it like this:

\TicketService class ↓ Spring creates an object ↓ Spring manages that object ↓ Spring Bean \\

4️⃣ Then What Is Spring Boot?

Once I understood Spring, I had another question:

"If Spring already helps us build applications, why do we need Spring Boot?"
Spring applications can require configuration and setup.
Spring Boot was created to make building and running Spring applications easier.
The important thing to remember:

❌ Spring Boot does NOT replace Spring.

✅ Spring Boot is built ON TOP OF the Spring Framework. Think of it like this:

\Spring Framework ↓ Core Spring functionality ↓ Spring Boot ↓ Easier setup & development \\

Spring provides the foundation.
Spring Boot reduces the amount of configuration and setup we need.

5️⃣ Spring vs Spring Boot

🔵 Spring Framework

Spring provides the core functionality for building applications, including:

IoC
Dependency Injection
Bean management
Managing application objects and dependencies

🟢 Spring Boot

Spring Boot builds on Spring and simplifies application development through:

Auto-configuration
Starter dependencies
Embedded servers
Sensible defaults
Less manual configuration The simplest way I remember it: > SPRING = FOUNDATION > SPRING BOOT = SIMPLIFIED WAY TO BUILD & RUN SPRING APPLICATIONS

6️⃣ Why Is Spring Boot Easier?

Imagine we want to build a web application.
There can be a lot of configuration and dependency setup involved. Spring Boot simplifies this.
For example, we can use starter dependencies for common application requirements. Spring Boot can also automatically configure many things based on our application's dependencies and configuration.
And for web applications, Spring Boot can provide an embedded server such as Tomcat.
So instead of spending a lot of time setting up the infrastructure, we can focus more on building the actual application.
I'll explore:

Auto-configuration
Starter Dependencies
Embedded Server
Tomcat in the Spring Boot episode.

7️⃣ The Big Picture

The biggest thing I learned in Episode 1:
Spring and Spring Boot aren't two completely separate technologies. They are connected.

\Spring Framework ↓ Core Spring functionality ↓ IoC + Dependency Injection ↓ Object & dependency management ↓ Spring Boot ↓ Simplifies configuration & setup ↓ Easier Spring application development \\

Before learning individual annotations, I wanted to understand the WHY behind Spring Boot.

📌 NEXT 2 EPISODES

This episode was just the foundation.
I intentionally introduced some keywords without going deep into them because I want to learn each concept separately.

🌱 Episode 2 — Spring Core

We'll break down:

IoC — Inversion of Control
Dependency
Dependency Injection
Spring Container
Bean
ApplicationContext
Component Scanning

🚀 Episode 3 — Spring Boot

We'll break down:

Auto-configuration
Starter Dependencies
Embedded Server
Tomcat
@SpringBootApplication
SpringApplication.run()

So if you saw some of these keywords in Episode 1 and thought,

"What does that mean?"
That's exactly what the next two episodes are for.
One concept at a time. One project throughout the journey.

Hey, I'm new here! Documenting my Java, Spring Boot & Applied AI learning journey 👋

Shreya Karka — Mon, 24 Aug 2026 20:13:41 +0000

Hi everyone! I'm excited to join the DEV community.

What I'm doing: I'm learning Java and Spring Boot, and also picking up AI/Machine Learning fundamentals. Instead of keeping notes to myself, I'm posting them here as a series — brief, beginner-friendly notes on each topic as I learn it, so anyone starting from scratch can follow along and learn with me.

No dense definitions, just clear, simple takeaways from what I actually learned that day. I'll be running two ongoing series: Spring Boot Journey and AI Learning Log.

If you're learning Java, Spring Boot, or AI too — follow along, share your own notes, or just say hi. Let's learn together!

#java #springboot #ai #beginners

DEV Community: Shreya Karka

🚀 Spring Boot Learning Series — Episode 3 | Spring Boot

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

🔑 Keywords for This Episode

1️⃣ Starter Dependencies

2️⃣ Auto-Configuration

3️⃣ Embedded Server: Tomcat

4️⃣ @SpringBootApplication

5️⃣ SpringApplication.run()

🧠 How Episodes 2 and 3 Connect

🎯 Interview Check

🛠️ Applying This to the Project

🌱 Spring Boot Learning Series — Episode 2 | Spring Core

Episode 2 | Spring Core | Understanding IoC, Dependency Injection & Beans

🔑 Keywords for This Episode

1️⃣ Quick Recap: IoC & Dependency Injection

2️⃣ Spring Bean — what Spring actually manages

3️⃣ Spring Container (a.k.a. ApplicationContext)

4️⃣ Component Scanning — how the Container finds classes to manage

🧠 Putting It All Together

🎯 Interview Check

🛠️ Applying This to the Project

📌 Next Episode — Spring Boot

🚀 Spring Boot Learning Series — Episode 1

Episode 1 | Spring vs Spring Boot — The Foundation

👉 What is Spring, and why do we need Spring Boot?

🔑 Keywords for This Episode

1️⃣ What Is Spring Framework?

🔴 Tight Coupling

2️⃣ What Is Tight Coupling?

3️⃣ How Does Spring Help?

🫘 What Is a Spring Bean?

4️⃣ Then What Is Spring Boot?

5️⃣ Spring vs Spring Boot

🔵 Spring Framework

🟢 Spring Boot

6️⃣ Why Is Spring Boot Easier?

7️⃣ The Big Picture

📌 NEXT 2 EPISODES

🌱 Episode 2 — Spring Core

🚀 Episode 3 — Spring Boot

Hey, I'm new here! Documenting my Java, Spring Boot & Applied AI learning journey 👋

4️⃣ `@SpringBootApplication`

5️⃣ `SpringApplication.run()`