DEV Community: Ankit Verma

Recap — M0 Foundations

Ankit Verma — Tue, 16 Jun 2026 09:40:01 +0000

This module built one thing, from many angles: the container — the part of Spring that creates your objects, wires them together, and hands them out. Eight articles each zoomed in on a different corner of it. This recap zooms back out. The goal here is not to re-explain each topic, but to show how they are all the same idea seen from different sides, so the whole module collapses into a picture you can hold in your head at once.

So before the details, here is the single sentence the entire module hangs on: the container is a factory that runs at startup, and almost every feature you met is just that factory doing a little extra work while it builds a bean. Keep that sentence close. Everything below is a way of filling it in.

The factory, in one picture

Picture an assembly line that runs exactly once, when your application boots. You hand it a list of what to build and how the pieces fit. It builds every object your app is made of, connects them, sets them on a shelf, and hands them out on request for the rest of the program's life.

That assembly line is the container. The objects it builds and manages are beans. An object you create yourself with new is not a bean — Spring never touched it — and that distinction is the thread running through every trap in this module.

The factory does four things at startup, and the order matters: it reads recipes, works out who needs whom, builds from the bottom up, and caches each result.

ApplicationContext ctx = SpringApplication.run(App.class, args);
OrderService svc = ctx.getBean(OrderService.class); // already built and wired

By the time run returns, the work is done. Asking for a bean is instant because the building already happened. Every other topic in the module is a detail about how that one startup pass works.

Why we hand the work over at all

The module opened with a question of control. Left alone, a class builds its own collaborators with new — and in doing so it welds together two unrelated decisions: what it needs, and which exact thing it gets and how that thing is built.

class OrderService {
    private final PaymentGateway gateway = new PaymentGateway(new HttpClient());
}

Pulling those two decisions apart is the whole point. The class should declare what it needs and let something outside choose and supply the which. Handing that choice to the framework is Inversion of Control — your code stops creating its own collaborators. The way the collaborator then arrives is Dependency Injection — it is passed in from outside.

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(PaymentGateway gateway) {   // declares the need, receives it
        this.gateway = gateway;
    }
}

IoC is the idea; DI is the delivery. And the delivery has a preferred form for a mechanical reason, not a stylistic one: constructor injection makes the field final, makes the object impossible to build half-wired, and makes it testable with a plain new in a unit test. That preference for the constructor is a decision the rest of the module keeps cashing in.

How a single bean comes to life

Once you accept that the factory builds your beans, the natural next question is how it builds one. The answer is a fixed four-stage sequence — the bean lifecycle:

Instantiate — construct the raw object.
Populate — inject field- and setter-style dependencies.
Initialize — run setup now that everything is wired.
Destroy — run teardown at an orderly shutdown.

The order is the lesson. A field-injected dependency is null if you touch it in the constructor, because populate (stage 2) has not run yet. Setup that needs dependencies belongs in @PostConstruct (stage 3), where wiring is guaranteed complete. Teardown mirrors it in @PreDestroy (stage 4).

Notice how this rewards constructor injection again: it folds populate into instantiate, so a constructor-injected bean is never half-there. The lifecycle is just the factory's per-bean routine, and most of its surprises come from forgetting which stage runs when.

How many, and how long

The lifecycle describes one bean's journey. Scope answers the other two questions about it: how many instances exist, and how long each lives.

Singleton — one instance per container, the default, shared by everyone.
Prototype — a fresh instance on every request, built on demand.
Request and session — one instance per HTTP request or per user session.

"Shared," in the singleton line, is the dangerous word, and it leads to the module's most common bug. Because one singleton serves every thread at once, any mutable field on it is a race condition.

@Service
class CartService {
    private int itemCount;          // one field, every thread, lost updates
    void addItem() { itemCount++; }
}

The rule that falls out is short: keep singletons stateless. Immutable shared state — your injected dependencies — is exactly what a singleton is good at; mutable shared state is the trap.

Which container is doing all this

Up to here, "the container" has been a single idea. In Spring's code it wears two names, and the difference matters. BeanFactory is the minimal contract — store recipes, build beans lazily on request. ApplicationContext extends it and staffs it.

That staffing is the whole reason you always use the ApplicationContext. Features like @Autowired and @PostConstruct are not part of the factory core — each is a plugin called a BeanPostProcessor that gets a crack at every bean during the lifecycle. The bare BeanFactory registers none of them, so it silently ignores your annotations. The ApplicationContext registers them all automatically, and it builds singletons eagerly at startup — so a broken wiring fails at boot, on your machine, not three days later in production.

ApplicationContext ctx = new AnnotationConfigApplicationContext("com.shop");
// every annotation honored, every singleton already built

This is the same fail-fast instinct constructor injection showed with circular dependencies: surface the problem at the safest possible moment.

How you tell the factory what exists — and how it finds it

The factory needs recipes. Where they come from is the configuration style, and Spring has had three, each fixing the last one's pain:

XML — all wiring in an external file. Central, but verbose and string-typed.
Annotations — @Component and friends mark the class itself. The default for your own code.
Java config — @Bean methods inside a @Configuration class. The way to register classes you cannot annotate, like third-party objects.

All three end as the same internal bean definitions, which is why one app mixes them freely. Java config carries one subtlety worth keeping: Spring wraps a @Configuration class in a proxy so that a call from one @Bean method to another returns the shared bean instead of building a second one.

For the annotation style, component scanning is how the factory actually finds your marked classes. @ComponentScan walks a base package and everything beneath it — and only ever downward, which is why the main class lives in the root package, and why a class above the scan's start point silently never registers. The stereotypes — @Service, @Repository, @Controller — are just @Component with a role attached, scanned identically, though @Repository earns exception translation as a bonus.

How the factory connects the beans

With every bean found and defined, the last job is wiring them — autowiring. The rule is resolution by type: the container finds the one bean whose type fits a dependency and injects it. One match and the wiring is silent.

The interesting part is the tie-break, when two beans fit one slot. The container refuses to guess and fails fast; you break the tie three ways:

Parameter name — a quiet fallback that matches the injection point's name to a bean name.
@Primary — one global default, declared on the bean.
@Qualifier — a named choice at the injection point, which overrides @Primary.

And when a dependency might legitimately be absent, Optional<T> or ObjectProvider<T> make that explicit instead of crashing.

The two threads that run through everything

Step back and two ideas turn out to connect almost every topic.

The first is the proxy — a same-shaped stand-in the factory can hand you instead of the bare bean. It is not one feature; it is the same trick reused everywhere. It is how @Transactional opens a transaction around your method. It is how a request-scoped bean gets injected into a singleton — the proxy resolves to the right per-request instance on each call. It is how a @Configuration class avoids building a bean twice. And its timing — created after @PostConstruct runs — is why init code self-calling a proxied method quietly skips the wrapper. Once you see the proxy, a dozen "how does Spring even do that?" questions share one answer.

The second is fail-fast: surface a mistake at the earliest, safest moment. Eager singleton startup catches broken wiring at boot. Constructor injection turns a circular dependency into a boot-time error instead of a production StackOverflowError. An ambiguous autowire stops the app rather than picking the wrong bean. The strictness is the safety.

The traps, as one family

Almost every gotcha in this module is the same mistake wearing different clothes — a mismatch between when injection happens and when you use the result:

A field-injected dependency touched in the constructor is null — populate runs after the constructor.
A mutable field on a singleton races — one instance is wired once and shared across every thread.
A prototype injected into a singleton freezes — injection is a one-time event, so you get one prototype forever; reach for ObjectProvider to pull a fresh one each call.
A proxied method self-called inside @PostConstruct skips the proxy — the wrapper is not built yet.

See them together and they stop being four facts to memorize. They are all consequences of one truth: for a singleton, wiring happens exactly once, at startup.

The one picture to keep

If you keep only one thing from this module, keep the factory. The container reads recipes, builds your beans bottom-up in dependency order, can wrap each one in a proxy, caches the results, and fails fast when something does not fit. Inversion of Control is why you hand the work over; dependency injection is how the pieces arrive; the lifecycle is how one bean is assembled; scope is how many and how long; the ApplicationContext is the fully-staffed factory that runs it; configuration, scanning, and autowiring are how it learns what to build and connects it all.

Everything heavier you meet from here — AOP, transactions, web request handling, data access — is a variation on this one startup pass. The factory does not go away. It just keeps finding new work to do while it builds your beans.

@Autowired resolution, @Qualifier/@Primary, injection types + circular-dependency gotcha

Ankit Verma — Mon, 15 Jun 2026 10:44:01 +0000

The last article left the container in a tidy state. Scanning has finished, and every class you marked is now a bean definition sitting in the container, names and all. But a definition is just a recipe. The moment the container starts actually building beans, it hits the question this article is about: to build OrderService, it needs to pass something into the PaymentGateway slot in its constructor — so which bean does it reach for?

When exactly one bean fits, the answer is obvious and you never think about it. The interesting part is everything around that happy path: how the container makes the match, what happens when two beans fit the same slot, and how you steer the choice when it can't decide on its own.

That whole job — the container finding and supplying the beans a dependency needs, instead of you naming each one by hand — is called autowiring. You meet it for real the first time Spring refuses to start, complaining it found more than one bean of some type and doesn't know which you meant. To fix that on purpose instead of by trial and error, you need to see how resolution actually works.

This article walks it end to end: the match by type, why @Autowired is often already implied, the ambiguity that breaks the match, the three tools that break the tie, what to do when a bean might be missing — and finally a deeper look at the circular-dependency trap the dependency-injection article only cracked open.

The happy path: resolution by type

Start with the rule from the dependency-injection article, now seen from the container's side. When the container builds a bean and reaches a dependency, it looks through every bean it knows about for one whose type fits, and injects that one.

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(PaymentGateway gateway) {   // "I need a PaymentGateway"
        this.gateway = gateway;
    }
}

If there is exactly one PaymentGateway bean in the container, the match is unambiguous and the wiring just happens. You declared a need by type; the container found the one bean that satisfies it and handed it over. That is autowiring in its simplest, invisible form.

Where did `@Autowired` go?

You may have noticed there is no @Autowired on that constructor. That is not an oversight. When a class has a single constructor, Spring treats it as an injection point automatically — it assumes the parameters are dependencies to resolve, no annotation required.

So @Autowired only needs to appear in the cases Spring cannot infer:

On a class with more than one constructor, to mark which one the container should call.
On a field or setter, where there is no sole constructor for Spring to assume.

@Service
class OrderService {
    @Autowired                                  // needed here only if there are other constructors
    OrderService(PaymentGateway gateway) { /* ... */ }
}

The useful way to hold it: @Autowired marks an injection point — a spot that says "fill this in from the container." A parameter on a sole constructor is an injection point implicitly. Everywhere else, the annotation is how you point at one.

When two beans fit one slot

Now the situation that breaks the happy path. Suppose two classes implement the same interface, and both are beans:

@Component
class StripeGateway implements PaymentGateway { /* ... */ }

@Component
class AdyenGateway implements PaymentGateway { /* ... */ }

OrderService still asks for a single PaymentGateway. The container searches by type and now finds two candidates. It has no basis to prefer one, and it will not guess. It fails at startup:

NoUniqueBeanDefinitionException: expected single matching bean
but found 2: stripeGateway, adyenGateway

This is the fail-fast philosophy again — an ambiguous wiring is caught at boot, on your machine, not silently resolved into the wrong gateway in production. Spring gives you three ways to resolve it, and they are worth knowing as a set, because they layer.

Tie-breaker 1: the parameter name

Before you reach for any annotation, Spring has a quiet fallback already running. When the type matches several beans, it tries to narrow them by name — matching the name of the injection point against the bean names. Recall from the scanning article that a scanned bean is named after its class, decapitalized: StripeGateway becomes stripeGateway.

@Service
class OrderService {
    OrderService(PaymentGateway stripeGateway) {   // parameter name matches a bean name
        // resolves to the stripeGateway bean
    }
}

Name the parameter stripeGateway and the ambiguity disappears: the container matches it to the bean of that name. It works, but lean on it carefully. It depends on parameter names surviving compilation (Spring Boot compiles with that turned on, so they do), and it is subtle — renaming a parameter silently rewires the application. It is fine as a fallback; it is a poor way to express intent. For that, be explicit.

Tie-breaker 2: `@Primary` — declare a default winner

@Primary marks one bean as the default to use whenever several fit:

@Component
@Primary
class StripeGateway implements PaymentGateway { /* ... */ }

@Component
class AdyenGateway implements PaymentGateway { /* ... */ }

Now any unqualified PaymentGateway injection, anywhere in the app, gets Stripe. The key trait is that @Primary lives on the bean — one declaration, applied everywhere that type is needed. It is the right tool when there is one obvious default and only rare exceptions.

Tie-breaker 3: `@Qualifier` — name the one you want

@Primary decides globally. @Qualifier decides at a single injection point. You give the beans qualifier names and then ask for one by name right where you need it:

@Component
@Qualifier("stripe")
class StripeGateway implements PaymentGateway { /* ... */ }

@Component
@Qualifier("adyen")
class AdyenGateway implements PaymentGateway { /* ... */ }

@Service
class OrderService {
    OrderService(@Qualifier("stripe") PaymentGateway gateway) {   // this slot wants Stripe
        // ...
    }
}

And the two combine cleanly. When both are present, @Qualifier at the injection point wins over @Primary. The idiom that falls out: mark the everyday default with @Primary, and use @Qualifier only at the few spots that need the exception. Most of the code stays quiet; the deviations are explicit.

When the bean might not be there

The mirror image of ambiguity is absence. If a required dependency has no matching bean, the container fails at boot with NoSuchBeanDefinitionException — the same fail-fast instinct. Usually that is exactly what you want. But occasionally a dependency is genuinely optional: a metrics sink that may or may not be configured, say. Spring has three ways to say "inject it if it exists, otherwise carry on":

@Autowired(required = false) — leaves a field or setter unset if no bean is found.
Optional<PaymentGateway> — arrives empty when the bean is absent.
ObjectProvider<PaymentGateway> — a lazy handle you ask for the bean only when you need it (the same type the bean-scopes article used to pull a fresh prototype on demand).

@Service
class OrderService {
    private final Optional<PaymentGateway> gateway;

    OrderService(Optional<PaymentGateway> gateway) {   // empty if no gateway bean exists
        this.gateway = gateway;
    }
}

Prefer Optional or ObjectProvider over required = false: they keep the field final and make the "might be absent" part visible in the type, instead of hiding it behind a field that is sometimes null. (And note the List<PaymentGateway> form from the DI article is a different case entirely — it asks for all matching beans on purpose, so several matches are the answer, not an error.)

Injection types, seen through resolution

The DI article already made the case for constructor injection over setters and fields, so this is just the same picture from the resolver's angle: the matching algorithm above is identical no matter where the injection point sits. @Qualifier and @Primary work the same on a constructor parameter, a setter, or a field.

What changes is when resolution runs and how safely. Constructor injection resolves everything at construction, so the object is never half-built and the fields can be final. Setter injection runs during the populate stage, which suits a truly optional or reconfigurable dependency. Field injection is the most concise and the least testable. The resolution rules don't pick a style for you — but as the next section shows, the style you pick decides how one particular failure behaves.

The circular-dependency gotcha, in full

The DI article showed one slice of this: two beans that depend on each other, wired through constructors, fail at boot. Here is the complete picture, because the outcome depends entirely on the injection style — and that is the whole lesson.

Say A needs B, and B needs A. With constructor injection on both sides, neither object can be built first: building A needs a finished B, which needs a finished A, and round it goes. The container detects the loop and stops:

BeanCurrentlyInCreationException:
Requested bean is currently in creation — is there an unresolvable circular reference?

That looks like an obstacle. It is actually the good case — the cycle is exposed the instant you start the app.

Now switch the two beans to field injection and watch the failure quietly vanish:

@Component
class A {
    @Autowired B b;
}

@Component
class B {
    @Autowired A a;
}

Because field injection happens after construction, Spring has a move available that constructors deny it. It builds the raw A first, then — before A is fully wired — exposes a reference to that half-built A. It builds B, setting B's field to the early A reference. With B now complete, it finishes wiring A by setting A's field to the finished B. The cycle resolves, and the application starts as if nothing were wrong.

That "as if nothing were wrong" is the trap. A circular dependency is a real design flaw — two beans so entangled that neither is whole without the other — and field injection lets it ship undetected. Constructor injection would have failed loudly at boot and forced the conversation. This is one more reason the earlier articles pushed constructors so hard: the strictness is the safety.

Spring offers an escape hatch, @Lazy, for when you must break a cycle without redesigning right now. Put @Lazy on one of the two injection points and the container injects a proxy — the same stand-in trick from the first article — instead of the real bean, deferring the real lookup until the first method call. By then both beans exist, so the loop never has to be resolved at construction time.

@Component
class A {
    A(@Lazy B b) { /* ... */ }   // injects a proxy now, resolves B on first use
}

Treat that as a patch, not a cure. The honest fix is to break the cycle: pull the shared logic into a third bean both can depend on, or let one side publish an event the other listens for, the way the ApplicationContext article wired OrderService to email without either knowing the other. A mutual dependency almost always means a responsibility is living in the wrong class.

It is worth knowing that recent Spring Boot takes your side here: since 2.6 it forbids circular references by default, so even a field-injected cycle fails at startup unless you deliberately set spring.main.allow-circular-references=true. The framework now nudges everyone toward the fix instead of the papering-over.

Putting it together

Autowiring is the container resolving each dependency by type: one matching bean and the wiring is silent, with @Autowired implied on a sole constructor and only spelled out for extra constructors, fields, and setters. When two beans fit one slot, the container fails fast rather than guess — and you break the tie three ways: the parameter name (a subtle fallback), @Primary (one global default on the bean), or @Qualifier (a named choice at the injection point that overrides @Primary). When a bean might be missing, Optional or ObjectProvider make the absence explicit instead of crashing.

The deepest point is the one about cycles. Resolution itself doesn't care which injection style you used — but a circular dependency does. Constructor injection turns it into a boot-time error you cannot miss; field injection papers over it and lets a design flaw ship. That asymmetry, now reinforced by Boot's default of refusing cycles outright, is the last and strongest argument for wiring through the constructor.

With that, the container's whole story is on the table: how it learns what your beans are, builds them, scopes them, and now connects them to each other. The next article steps back from the individual mechanisms and ties the entire Foundations module into one mental model — a recap of how every piece we have built fits together.

Component scanning & stereotypes

Ankit Verma — Sun, 14 Jun 2026 08:30:48 +0000

The last article left a thread dangling. It showed that the annotation style marks a class as a bean by putting @Component — or one of its cousins — right on the class, and then said the container finds those marked classes by component scanning. It promised that scanning was "its own topic, the very next article." This is that article.

Component scanning is the step where Spring walks through your code, finds the classes you marked as beans, and registers each one with the container. It is the bridge between "I annotated a class" and "the container knows that class exists." Without it, an @Service is just an annotation sitting on a class Spring never bothers to look at.

You meet scanning the first time a class you wrote refuses to show up. You added @Service, you asked the container for it, and Spring answers that there is no such bean. Almost always the class is sitting in a package the scan never visited. To fix that with intent instead of guesswork, you need to know what scanning actually does and where it actually looks.

This article walks the whole mechanism: how the scan finds your classes, the stereotype annotations that mark them, the one stereotype that quietly does more than mark, where the search begins, and the traps that come from searching too narrowly or too widely.

The mark and the search are two halves of one thing

Recall the single job of @Component: it labels a class as something the container should build and manage — a bean. But a label does nothing on its own. Something has to go looking for it.

That something is the component scanner. At startup, before a single bean is built, the scanner walks a set of packages, inspects every class it finds, and for each class wearing @Component it writes down a bean definition — the recipe card from the earlier articles. When the scan finishes, the container holds a definition for every annotated class, exactly as if you had spelled them all out in Java config by hand.

@Service
class OrderService {
    OrderService(PaymentGateway gateway) { /* ... */ }
}

On its own, that class is inert. The annotation says "I am a bean"; the scan is what hears it. Miss either half — forget the annotation, or never scan the package it lives in — and the bean simply does not exist.

Turning the scan on

You rarely write the line that starts scanning, but it is worth seeing once, plainly. The annotation that switches it on is @ComponentScan:

@Configuration
@ComponentScan("com.shop")
class AppConfig { }

That says: walk the com.shop package and everything beneath it, and register every @Component you find. The string is a base package — the root where the search begins. Scanning is recursive, so com.shop, com.shop.orders, and com.shop.billing.tax are all swept in by that one line.

In a Spring Boot app you never actually write @ComponentScan, because it is hidden inside the annotation on your main class. But it is running all the same, and knowing it is there is what makes the next trap avoidable.

Where the search starts — and the classic trap

The annotation on your main class, @SpringBootApplication, is a bundle: it folds together @Configuration, the auto-configuration switch, and @ComponentScan — the last one with no package argument.

When you give @ComponentScan no package, it does not scan nothing. It defaults to the package of the class it sits on, and everything below it.

package com.shop;          // the root package

@SpringBootApplication      // scans com.shop and downward
class ShopApplication {
    public static void main(String[] args) {
        SpringApplication.run(ShopApplication.class, args);
    }
}

This is the reason every Boot project puts its main class in the root package, above all the others. From there, the default scan naturally covers the whole application — com.shop.web, com.shop.billing, all of it.

Now the trap, which catches nearly everyone once. Move that main class down into a sub-package by mistake:

package com.shop.web;       // oops — not the root

@SpringBootApplication       // scans com.shop.web and downward ONLY
class ShopApplication { }

Scanning now starts at com.shop.web. Your com.shop.billing package is above the start point, so it is never visited, and none of its beans get registered. The symptom is a NoSuchBeanDefinitionException at startup — Spring asking for a bean it was never told about. The fix is to move the main class back up to the root, or to name the packages explicitly with @SpringBootApplication(scanBasePackages = "com.shop"). Either way, the cause is the same: the scan only ever looks down from where it starts.

The stereotypes: same scan, different meaning

@Component is the generic mark. On top of it, Spring ships three specialized labels — @Service, @Repository, and @Controller — known together as the stereotype annotations, because each names the role a class plays in the usual layered design: business logic, data access, web entry point.

Here is the detail that ties them to everything above. Each stereotype is itself meta-annotated with @Component — that is, @Component is stamped on the annotation itself:

@Component          // <-- right here, on the annotation
public @interface Service {
    // ...
}

Because the scanner treats "annotated with @Component, directly or through another annotation" as the trigger, a @Service is picked up by exactly the same scan as a bare @Component. There is no separate machinery for them. A stereotype is a @Component with a name on it.

So why bother with the specialized ones? Two reasons, both real but modest. They document the layer at a glance — @Repository tells a reader "this talks to the database" in a way @Component never could. And they give Spring and your tools a hook to treat a layer specially. For most classes the stereotypes are interchangeable with @Component; the habit is simply to pick the one that names what the class actually does.

@Repository earns more than its name

One stereotype does more than label, and it is worth knowing exactly what. When the scan registers a @Repository bean, Spring also wraps it in a proxy — the same stand-in trick from the first article — to perform exception translation.

Here is the problem it solves. Every persistence technology throws its own exceptions: raw JDBC throws SQLException, Hibernate throws its own HibernateException, and so on. If your service layer caught those directly, it would be welded to whichever library sits underneath.

@Repository
class JpaOrderRepository {
    Order findById(long id) { /* ... */ }   // may hit a vendor-specific failure
}

Because this is a @Repository, the proxy around it catches those vendor-specific exceptions on the way out and rethrows them as Spring's own DataAccessException family — one consistent hierarchy, the same no matter what runs below. Swap JPA for plain JDBC tomorrow, and the exception types your service code catches do not change. That single benefit is a concrete reason to put @Repository on data-access classes rather than a generic @Component.

The @Controller stereotype has its own special handling too — the web layer recognizes it and routes HTTP requests to its methods — but that belongs to the web module later. For now it is enough that the scan treats it like any other @Component, and something downstream gives it extra meaning.

Every scanned bean gets a name

When the scanner registers a bean, the container needs a name for it. By default, scanning takes the simple class name and decapitalizes the first letter: OrderService becomes the bean named orderService.

@Service
class OrderService { }      // registered under the name "orderService"

Most of the time you never touch the name, because injection resolves by type, as the dependency-injection article showed. The name starts to matter only when two beans share a type and you must point at one specifically — that tie-breaking is the next article's subject — or when two names collide.

The collision is worth flagging because it fails loudly. Put two classes with the same simple name in different packages, and both want to be orderService:

// com.shop.billing.OrderService   -> wants "orderService"
// com.shop.legacy.OrderService    -> also wants "orderService"

Scanning refuses the ambiguity and throws ConflictingBeanDefinitionException at startup. That is the fail-fast philosophy again — a name clash is caught at boot, not silently resolved into the wrong bean. When you genuinely need two such classes, give one an explicit name with @Service("legacyOrderService").

Scanning too wide

By default the scan registers everything annotated that it finds below the base package. Usually that is what you want. But a base package set too broad will quietly pull in classes you never meant to activate — a stray @Configuration in some sub-module that switches a feature on, or test-only beans that have no business in production.

For that, @ComponentScan accepts filters that include or exclude classes by annotation, type, or pattern:

@ComponentScan(
    basePackages = "com.shop",
    excludeFilters = @ComponentScan.Filter(
        type = FilterType.ANNOTATION,
        classes = Configuration.class)   // skip stray @Configuration classes
)
class AppConfig { }

Filters are the precise tool when the default sweep grabs too much. The blunter fix is the better default: keep your base packages tight. A narrow scan registers only what you intend, and as a bonus it costs less at startup — walking a smaller slice of the classpath is faster than walking all of it. Over-broad scanning is one of the quiet reasons a large application boots slowly.

Putting it together

Component scanning is how the annotation style turns marked classes into registered beans. The scanner walks a base package and everything under it, and for every class carrying @Component — directly or through a stereotype — it writes a bean definition into the container. The annotation declares the intent; the scan is what acts on it, and both halves are required.

The base package is where the search starts and only ever goes downward — which is why the main class lives in the root package, and why a class above the scan's start point silently never registers. The stereotypes — @Service, @Repository, @Controller — are @Component with a role attached; they are scanned identically, but @Repository also earns exception translation, and @Controller is later picked up by the web layer. Each scanned bean gets a decapitalized class name by default, and a name clash fails fast at boot.

So the scan ends with the container holding a complete set of bean definitions, names and all. Which raises the question the next article answers: when the container goes to build OrderService and sees it needs a PaymentGateway — and two beans happen to fit that type — how does it decide which one to inject? That is the job of @Autowired, @Qualifier, and @Primary, and it is where we go next.

Configuration styles: XML annotations Java config

Ankit Verma — Sat, 13 Jun 2026 10:31:11 +0000

Every Spring application starts with the same quiet question: how does the container know which objects to build? The first articles in this module described the container as a factory that reads recipe cards — bean definitions — and builds your objects from them. But they skipped over where those recipe cards actually come from.

That source is a configuration style: the way you tell Spring what beans exist and how they wire together. Spring has had three of them over its life — XML files, annotations, and Java config — and they arrived in that order, each fixing a pain in the one before.

You meet all three whether you like it or not. A legacy module still carries an XML file. Your own code is dotted with @Service. And the framework's own internals, plus most modern setup, are written in Java config. This article walks the three in the order they appeared, because each one only makes sense as an answer to the problem the previous one left behind.

The recipe cards have to come from somewhere

Recall the one rule from the first article: Spring's powers only apply to beans the container built. So before the container can build anything, something has to hand it the list of beans — their classes, their dependencies, their scopes. That list is the configuration.

Here is the part that ties everything together. The format of that list is separate from what the container does with it. However the definitions arrive, they all become the same internal bean definition objects, and the same factory builds from them.

So the three styles are not three different containers. They are three different ways of writing down the exact same thing. Keep that in mind, because it is why you can freely mix them in one application.

The XML era: configuration as a separate file

In the beginning, Spring kept all configuration in a separate XML file, completely outside your Java code. You listed each bean by its class name and spelled out its wiring by hand:

<beans>
    <bean id="httpClient" class="com.shop.HttpClient"/>

    <bean id="gateway" class="com.shop.PaymentGateway">
        <constructor-arg ref="httpClient"/>
    </bean>

    <bean id="orderService" class="com.shop.OrderService">
        <constructor-arg ref="gateway"/>
    </bean>
</beans>

Read it top to bottom and it is just the recipe cards, written out longhand. Each <bean> names a class. Each <constructor-arg ref="..."> says "pass this other bean into the constructor." You point the container at the file, and it builds everything listed.

The appeal was real. All wiring lived in one place, visible at a glance, and you could change which class got wired where without recompiling a line of Java. Configuration was data, not code.

But the costs piled up fast. The file is verbose — three lines of XML for what a constructor call says in one. The class names are plain strings, so a typo or a renamed class fails only at startup, never at compile time. And your IDE cannot help: rename PaymentGateway in Java and the XML still says the old name, silently. As applications grew to hundreds of beans, the XML grew with them, and it became its own burden to maintain.

Moving the marks into the code

The next step was to stop describing beans in a far-off file and instead mark the class itself as a bean, right where it is defined. That is what @Component and its specialized cousins — @Service, @Repository, @Controller — do:

@Service
class OrderService {
    OrderService(PaymentGateway gateway) { /* ... */ }
}

One annotation replaces a whole <bean> block. The container finds these marked classes by component scanning — walking your packages at startup and registering every annotated class as a bean. (Scanning is its own topic, the very next article; for now just take it that the container can find these marks.)

This fixed the worst of XML. The bean definition now sits next to the code it describes, so the two can never drift apart. There are no class-name strings to mistype — the annotation rides on the class, so a rename carries it along. And the dependencies are simply the constructor parameters, resolved by type, exactly as the dependency-injection article described.

So annotations won for your own classes, and that is where they remain the default today. But they have one hard limit, and it is the reason a third style had to exist.

The wall annotations hit

@Component only works if you can put it on the class. For your own code, fine. But a large share of the beans in a real application are not your classes at all — they come from libraries. A DataSource from a connection-pool library, an ObjectMapper from Jackson, a RestTemplate from Spring itself.

You cannot annotate those. You do not own the source, and editing a library's jar to add @Component is not an option. Annotation-based configuration simply has nothing to say about a class you did not write.

// You want this as a bean, but you can't add @Component to it —
// HikariDataSource lives in someone else's jar.
HikariDataSource ds = new HikariDataSource();
ds.setJdbcUrl("jdbc:postgresql://localhost/shop");

So you need a way to register a bean without touching its class — and ideally one that is still plain, type-safe Java, not a string-typed file off to the side. That is exactly what Java config provides.

Java config: methods that build beans

The third style writes configuration as ordinary Java, in a class marked @Configuration. Inside it, each method marked @Bean builds and returns one bean. The method body is the recipe — you write the construction yourself:

@Configuration
class InfrastructureConfig {

    @Bean
    DataSource dataSource() {
        HikariDataSource ds = new HikariDataSource();
        ds.setJdbcUrl("jdbc:postgresql://localhost/shop");
        return ds;
    }
}

The container calls dataSource() once at startup, takes the returned object, and registers it as a bean named dataSource — the method name. The third-party problem is gone: you never needed to annotate HikariDataSource, you just called its constructor inside a method you do own.

Notice what this keeps from the annotation style and what it wins back from XML. It is plain Java, so it is type-safe and your IDE refactors it like any other code — no magic strings. But like XML, it can register beans for classes you cannot annotate, and it hands you a real method body where you can run logic — read a property, pick an implementation, tune the object — before returning it.

How Java-config beans find each other

A bean usually needs other beans. In Java config you wire them by writing a method that takes the dependency as a parameter, or by calling another @Bean method directly:

@Configuration
class InfrastructureConfig {

    @Bean
    PaymentGateway gateway(DataSource dataSource) {   // asks for the DataSource bean
        return new PaymentGateway(dataSource);
    }

    @Bean
    OrderService orderService() {
        return new OrderService(gateway());   // calls the other @Bean method
    }
}

The parameter form is the clean one: ask for DataSource as a method argument and the container injects the existing bean, exactly as constructor injection does for your @Components.

The second form is where people get nervous. orderService() calls gateway() directly — and a plain Java method call would run the method again, building a second PaymentGateway. That would shatter the singleton guarantee: two different gateways floating around, when the whole point was one shared instance.

The @Configuration proxy that makes it safe

Here the proxy from the first article comes back to do real work. Spring does not use your @Configuration class directly. At startup it wraps it in a proxy — a same-shaped subclass — that intercepts every call to a @Bean method.

So when orderService() calls gateway(), the proxy steps in front of that call. Instead of running the method body again, it checks the container: if the gateway bean already exists, it hands back that cached instance. The body runs once, no matter how many other @Bean methods call it.

@Bean
OrderService orderService() {
    return new OrderService(gateway());   // proxy returns the SAME gateway bean, not a new one
}

That is why inter-bean method calls are safe inside a @Configuration class — and only inside one. The same call from a plain class, or from a class marked @Component instead of @Configuration, gets no proxy and really does run the method twice. (Spring lets you switch the proxy off with @Configuration(proxyBeanMethods = false) when you know no @Bean method calls another — it trims a little startup work, at the cost of this guarantee.)

Which style, when

These three styles all feed the same container, and a single application happily uses more than one at once. The modern division of labor is settled:

Annotations (@Component and friends) for your own application classes — the default, because the mark lives right on the code it describes.
Java config (@Configuration + @Bean) for everything you cannot annotate: third-party objects, and any bean whose creation needs real logic.
XML essentially never in new code. You learn to read it only because older codebases — and a lot of the internet — still speak it.

The thing to hold onto is that the choice is about where the recipe is written, not about what you get out. Whichever style registers a bean, it lands in the container as the same kind of bean definition, builds the same way, and can be wired into beans declared by any other style.

Putting it together

Configuring Spring means handing the container its recipe cards, and the configuration style is just the form those cards take. Spring has offered three, each answering the last one's weakness. XML put all wiring in one external file — central and recompile-free, but verbose, string-typed, and blind to refactoring. Annotations moved the mark onto the class itself, killing the drift and the typos, but they only work on classes you own. Java config writes each bean as a @Bean method in a @Configuration class — type-safe Java that can register anything, including third-party objects, and run logic while it builds.

The one mechanism worth remembering is the @Configuration proxy: it intercepts calls between @Bean methods so a shared bean is built once, not every time it is referenced. That single trick is what lets Java config read like ordinary method calls while still honoring the container's singleton promise.

All three styles end in the same place — bean definitions in one container. Which leaves the question we kept deferring: when you use the annotation style, how does the container actually find your @Component classes scattered across dozens of packages? That is component scanning, and it is where we go next.

ApplicationContext vs BeanFactory

Ankit Verma — Thu, 11 Jun 2026 21:14:09 +0000

Every article so far has talked about "the container" — the factory that builds and wires your beans. In Spring's actual code, that factory has two names. BeanFactory and ApplicationContext are both interfaces that mean "the container," and sooner or later you meet both. SpringApplication.run(...) hands you an ApplicationContext. Older tutorials, framework internals, and the bottom of stack traces talk about BeanFactory. The Javadoc of each keeps pointing at the other.

So which one is the container? Both — at different levels. BeanFactory is the minimal core: just the machinery that stores recipes and builds beans. ApplicationContext is built on top of it: the same factory, plus everything a real application needs around it. This article walks through what each one actually is, and the one difference that fails silently — the reason almost nobody should ever touch the bare factory.

The container's contract is an interface

Strip the factory from the first article down to its essence and ask: what is the smallest thing it must be able to do? Hold the recipes, build beans from them, and hand them out when asked. Spring writes that contract down as an interface, and it is startlingly small:

public interface BeanFactory {
    Object getBean(String name);
    <T> T getBean(Class<T> requiredType);
    boolean containsBean(String name);
    boolean isSingleton(String name);
    // ... a few more lookup variants, nothing else
}

Read what is there: lookups. Nothing about annotations, nothing about configuration files, nothing about proxies. That is the point. BeanFactory is the minimal contract for a bean container — store bean definitions, build each bean on demand, resolve its dependencies, hand it out.

One behavioral detail is worth flagging now, because it becomes a real difference later: a plain BeanFactory is lazy. It does not build anything up front. A singleton gets built the first time somebody asks for it, and not a moment before.

Driving the bare factory by hand

The contract has a real, concrete implementation inside Spring called DefaultListableBeanFactory. You can use it directly, and doing so once is the fastest way to understand what it is — and what it isn't:

DefaultListableBeanFactory factory = new DefaultListableBeanFactory();

factory.registerBeanDefinition("gateway",
        new RootBeanDefinition(PaymentGateway.class));
factory.registerBeanDefinition("orders",
        new RootBeanDefinition(OrderService.class));

OrderService orders = factory.getBean(OrderService.class);

This is the factory from the first article, operated manually. You hand it recipe cards — the bean definitions from before — and when you call getBean, it looks at OrderService's constructor, sees it needs a PaymentGateway, builds that first, then builds and caches the service. Dependency resolution, bottom-up construction, singleton caching: all there, in a dozen lines.

Which raises the obvious question. If this little object already builds and wires beans, why does every real Spring application use something bigger?

What the bare factory quietly doesn't do

Try feeding the bare factory a class written the way the previous articles taught:

@Component
class OrderService {
    @Autowired
    private PaymentGateway gateway;

    @PostConstruct
    void ready() { System.out.println("wired and ready"); }
}

Register it, fetch it. No error. No warning. But gateway is null, and "wired and ready" never prints. Every annotation on that class was silently ignored.

Here is why, and it connects straight back to the lifecycle article. Features like @Autowired, @PostConstruct, and the proxy that powers @Transactional are not built into the factory core at all. Each one is implemented by a BeanPostProcessor — the lifecycle hook that gets a crack at every bean as it is built. Field injection is done by one post-processor. Init annotations by another. Proxy wrapping by a third. They are plugins around the factory, not parts of it.

And the bare factory ships with none of them registered. If you insist on using it raw, you have to install each plugin yourself:

factory.addBeanPostProcessor(new AutowiredAnnotationBeanPostProcessor());
// ...and one for @PostConstruct, one for @Transactional proxies, one for...

Forget one, and that feature simply doesn't exist in your application. Nothing fails loudly — fields just stay null, transactions just don't open. A container that ignores your annotations without telling you is a container you don't want to operate by hand. What you want is the version that comes fully staffed.

ApplicationContext: the factory, fully staffed

ApplicationContext is an interface that extends BeanFactory. It is not a rival container — it is a superset, and the inheritance is written right in its declaration:

public interface ApplicationContext extends ListableBeanFactory,
        EnvironmentCapable, MessageSource,
        ApplicationEventPublisher, ResourcePatternResolver {
    // every BeanFactory method, plus all of the above
}

Each parent interface in that list is a service a real application was going to need anyway:

ListableBeanFactory — enumerate beans, not just look them up one at a time. This is the machinery behind injecting a List<ShippingRule> of every implementation, the plugin trick from the DI article.
EnvironmentCapable — access to properties and profiles, which is what makes @Value("${...}") resolve.
ApplicationEventPublisher — publish events to other beans (a concrete example in a moment).
MessageSource — translated text for internationalization.
ResourcePatternResolver — load files from the classpath or disk with one call.

But the bigger difference is behavioral. An ApplicationContext registers all the standard post-processors automatically. Create one and every annotation just works — injection, init callbacks, proxies, the lot:

ApplicationContext ctx =
        new AnnotationConfigApplicationContext("com.shop");

OrderService orders = ctx.getBean(OrderService.class);
// gateway injected, @PostConstruct ran, proxies applied

The string is the package to scan: the context finds every @Component under com.shop and registers it, no manual registerBeanDefinition needed. And it is the same getBean call as before — it is a BeanFactory, after all. The difference is everything that already happened before you asked.

Eager startup — the difference you can feel

Remember that the bare factory is lazy: nothing is built until first asked for. The ApplicationContext makes the opposite choice. During startup it walks every singleton definition and builds them all eagerly, before the application serves a single request.

That sounds like a detail. It is actually a guarantee about when you find out something is broken.

With a lazy container, a bean with a missing dependency or a broken constructor sits undetected until the first time someone asks for it — which might be a rarely-used endpoint, three days after deploy, in production, on a real user. With eager startup, that same mistake kills the application at boot, on your machine or in CI, with a stack trace pointing at the bad bean.

This is the same fail-fast philosophy the DI article praised when constructor injection turned circular dependencies into boot-time errors. Failing at the safest possible moment is the feature. (When a bean is genuinely too expensive to build up front, @Lazy opts it out one bean at a time — but the eager default is the right one.)

One of the extras, in action: events

The added interfaces aren't decoration; they change how you can structure code. Take ApplicationEventPublisher. Suppose that after an order is placed, an email should go out — but OrderService shouldn't know or care about email. Publish a plain object as an event:

@Service
class OrderService {
    private final ApplicationEventPublisher events;

    OrderService(ApplicationEventPublisher events) {
        this.events = events;
    }

    void placeOrder(Order order) {
        // ...persist the order...
        events.publishEvent(new OrderPlaced(order.id()));
    }
}

Any other bean can listen for it by annotating a method:

@Component
class EmailNotifier {
    @EventListener
    void on(OrderPlaced event) {
        // send the confirmation email
    }
}

The container delivers the event from publisher to every listener. OrderService gained an email feature without ever learning that email exists — and adding an SMS notifier later means adding one new bean, touching nothing. A bare BeanFactory has no idea how to do any of this. The container as event bus only exists at the ApplicationContext level.

So which one do you use?

In application code: always ApplicationContext. In practice you never even construct it yourself: SpringApplication.run(...) builds one and hands it back. Every Spring Boot app you have ever run was an ApplicationContext the whole time.

Under the hood, the relationship is composition, not reimplementation. A running ApplicationContext holds a DefaultListableBeanFactory inside it and delegates every getBean call down to it. The context is a shell of services wrapped around the same little factory you drove by hand earlier. That is why BeanFactory still exists as a separate interface: it is the internal engine and the extension point framework code is written against. You will see the name in Spring's own internals and in stack traces — but app code has no reason to reach for it.

One habit falls out of the layering. When a bean needs one of the context's services, inject the narrow interface, not the whole context. The OrderService above asked for ApplicationEventPublisher, not ApplicationContext — so its signature admits exactly what it uses, and a test can hand it a one-line fake instead of a whole container.

Putting it together

BeanFactory and ApplicationContext are the same container at two levels of dress. BeanFactory is the minimal contract — store definitions, build beans lazily on request — and DefaultListableBeanFactory is its real implementation, the engine at the bottom of every Spring app. ApplicationContext extends it and staffs it: all the standard post-processors registered automatically so annotations actually work, singletons built eagerly so broken wiring fails at boot instead of in production, plus events, properties, messages, and resources.

The bare factory ignores your annotations silently; the context honors them automatically. That single difference decides the question for you: use the ApplicationContext, let Boot create it, and remember that somewhere inside it, the little factory is still doing all the building.

Bean scopes (singleton/prototype/request/session) + singleton thread-safety gotcha

Ankit Verma — Mon, 08 Jun 2026 07:41:11 +0000

Every object the container builds has to answer two quiet questions: how many copies of it should exist, and how long should each one live? One shared copy for the whole application? A fresh one every time someone asks? One per web request? The answer to those two questions is the bean's scope.

You usually meet scope the day shared state misbehaves. A field on a @Service holds a value for one user and somehow shows up for another. Or you expected a brand-new object each time and kept getting the same one back. Both are scope surprises — and both have the same root cause once you can see it.

So this article walks the scopes Spring gives you, starting with the default you have been leaning on without ever naming it. Then it covers the two traps scope sets — including the one that causes real, hard-to-find production bugs.

The default you have already been using

Every bean in the previous articles was a singleton: the container builds exactly one instance, caches it at startup, and hands that same object to everyone who needs it, for the whole life of the application. You never asked for this. It is simply what @Component, @Service, and a bare @Bean give you.

@Service
class OrderService { }   // one instance, shared everywhere

Ask the container for it twice and you get the identical object back:

OrderService a = ctx.getBean(OrderService.class);
OrderService b = ctx.getBean(OrderService.class);
// a == b  → true, same instance

One word of caution on the name. A Spring singleton means one instance per container — not the classic JVM-wide singleton from design-pattern books. Spin up a second container and you get a second instance. Within one application that distinction rarely bites, but it is why "singleton" here is a scope, not a guarantee about the whole JVM.

Asking for a fresh one each time: prototype

Sometimes one shared instance is exactly wrong. You want a short-lived, stateful helper — a builder you fill in, use once, and throw away. For that, Spring offers the prototype scope: a brand-new instance every single time the bean is requested.

@Component
@Scope("prototype")
class ReportBuilder { }   // a new one on every request

Now each getBean hands back a different object:

ReportBuilder a = ctx.getBean(ReportBuilder.class);
ReportBuilder b = ctx.getBean(ReportBuilder.class);
// a != b  → two separate instances

Two more things change with prototype. The container builds it on demand, when you ask — not eagerly at startup like a singleton. And, as the lifecycle article noted, Spring runs a prototype's setup but then forgets it: it never calls the destroy stage. The container builds a prototype, hands it over, and walks away.

Why the default is a singleton — and the trap hiding inside it

One shared instance is cheap and fast, which is why it is the default. But "shared" is the dangerous word, and it leads straight to the single most common Spring bug.

A web application handles many requests at the same time, each on its own thread. Every one of those threads calls into the same singleton instance. So any mutable field on a singleton is shared across all of them at once:

@Service
class CartService {
    private int itemCount;          // ONE field, shared by every thread

    void addItem() { itemCount++; } // two threads here = lost updates
}

This looks fine in testing, where one request runs at a time. In production it corrupts data. Two users add items concurrently, both threads read itemCount, both increment, both write back — and one update vanishes. Worse, one user's count is now visible to another, because there was only ever one field.

The fix is a rule, not a trick: keep singletons stateless. Don't store per-call or per-user data in fields. Let that data live in method parameters, local variables, and return values — those sit on each thread's own stack, so they are never shared.

@Service
class CartService {
    int withItemAdded(int count) {   // state passed in and out, never stored
        return count + 1;
    }
}

Note what is not a problem: fields that are set once at construction and never change — your injected dependencies, anything final. Those are shared too, but since nobody mutates them, no thread can corrupt them. The bug is specifically mutable shared state. Immutable shared state is exactly what a singleton is good at.

Scopes that follow the web request

Sometimes you genuinely need per-user or per-request state, and stuffing it through method parameters everywhere gets ugly. For that, Spring adds two web-aware scopes.

A request-scoped bean lives for exactly one HTTP request: the container builds a fresh one when the request arrives and discards it when the response is sent. A session-scoped bean lives for one user's session, spanning their many requests until the session ends.

@Component
@RequestScope
class RequestContext {
    private String traceId;   // safe: each request gets its own instance
}

Because every request gets its own instance, that mutable traceId field is now perfectly safe — the sharing that doomed the singleton simply isn't there. This is the right home for "data that belongs to this one request."

But it raises an awkward question. A singleton is built once, at startup. A request-scoped bean does not exist yet at startup — no request is in flight. So how can you inject a request-scoped bean into a singleton, when the thing you want to inject won't exist until much later, and then keeps being replaced?

The scoped-proxy fix

This is where the proxy from the first article comes back to do real work. When you inject a shorter-lived bean into a longer-lived one, Spring does not inject the real bean — it injects a proxy: a same-shaped stand-in that, on every method call, looks up the correct instance for the current request and forwards to it.

@RequestScope switches this proxy on by default, so the injection just works:

@Service
class AuditService {
    private final RequestContext context;   // really a proxy, injected once

    AuditService(RequestContext context) {
        this.context = context;
    }

    void record(String event) {
        context.setTraceId(event);   // resolves to THIS request's instance
    }
}

The singleton AuditService is wired exactly once at startup, holding the proxy forever. But each call through that proxy lands on the right per-request RequestContext. Without the proxy you would be stuck: either a startup failure because no request exists to inject, or one shared instance that defeats the entire point of request scope. The proxy bridges the lifespans.

The prototype-in-singleton trap

Now the trap that catches almost everyone, because it fails silently rather than loudly. Inject a prototype into a singleton the obvious way, and you do not get a fresh prototype per call:

@Service
class InvoiceService {
    private final ReportBuilder builder;   // injected ONCE, frozen forever

    InvoiceService(ReportBuilder builder) {
        this.builder = builder;
    }

    void generate() {
        builder.reset();   // same instance every invoice — not what you wanted
    }
}

You chose prototype precisely so each invoice would get its own ReportBuilder. Instead you got exactly one, captured at startup, reused for the life of the app. The reason is simple once it clicks: injection is a one-time event for a singleton. Spring builds InvoiceService once, so it resolves and injects its dependencies once. The prototype scope only promises a new instance per request to the container — and that request happened a single time, at wiring.

The fix is to ask the container for a new one at the moment you need it, instead of capturing one at startup. ObjectProvider is the clean way to do exactly that:

@Service
class InvoiceService {
    private final ObjectProvider<ReportBuilder> builders;

    InvoiceService(ObjectProvider<ReportBuilder> builders) {
        this.builders = builders;
    }

    void generate() {
        ReportBuilder builder = builders.getObject();   // a fresh prototype each call
    }
}

Each getObject() is a new request to the container, so each returns a new prototype. (A scoped proxy on the prototype achieves the same thing transparently, the way @RequestScope did — but ObjectProvider makes the "give me a fresh one now" intent obvious at the call site.)

Putting it together

A scope answers two questions about a bean: how many instances exist, and how long each lives. Singleton — one per container, the default — is built once and shared by everyone. Prototype is a new instance on every request, built on demand, and never destroyed by the container. Request and session scope tie a bean's life to one HTTP request or one user's session.

Both traps in this article come from mixing lifespans. The thread-safety bug is one singleton shared across many threads at once, so any mutable field is a race — fixed by keeping singletons stateless. The stale-injection bug is a short-lived bean injected once into a long-lived one, so it freezes at startup — fixed by the scoped proxy, or by pulling a fresh instance from an ObjectProvider when you actually need it.

Hold on to the one idea underneath both: for a singleton, wiring happens exactly once. Everything that surprises you about scope follows from remembering when injection actually runs.

Bean lifecycle: instantiate populate init destroy

Ankit Verma — Mon, 08 Jun 2026 06:49:43 +0000

A Spring bean does not blink into existence fully formed. The container assembles it in a fixed order of stages — build the object, fill in its dependencies, run its setup, and much later, run its teardown. That ordered sequence is the bean lifecycle.

You meet it the first time you need something to happen at an exact moment. You want a connection pool opened after the bean has all its dependencies, but before it handles a single request. You want a cache flushed to disk when the app shuts down — but only if startup actually finished. To put your code in the right place, you have to know the order these stages run in, and what is guaranteed to be ready when each one fires.

The whole lifecycle is just the container doing work around an object it built. We will walk it end to end: the four main stages, the hooks Spring opens at each one, and two traps that fall straight out of the ordering.

The four stages, in one breath

Here is the spine of the whole article — the path every singleton bean walks, from startup to shutdown:

Instantiate — construct the raw object.
Populate — inject its dependencies.
Initialize — run setup now that it is fully wired.
Destroy — run teardown at shutdown.

Everything else is detail hung on those four pegs. Let's take them one at a time, because the order is the entire point — each stage is only safe to use once you know what ran before it.

Stage 1: instantiate — a bare object

First the container calls a constructor and gets back a raw Java object. Nothing Spring-specific has happened yet; this is the same new you would write by hand, just done for you.

@Component
class InventoryService {
    private final WarehouseClient client;

    InventoryService(WarehouseClient client) {   // constructor injection
        this.client = client;
    }
}

There is a subtlety worth pausing on. When you use constructor injection — dependencies passed as constructor arguments, as above — the wiring happens inside this first stage. Spring works out what WarehouseClient is, builds it, and hands it in as the object is created. For constructor-injected beans, "instantiate" and "populate" are the same moment.

That is not true for the other injection styles, and the difference is where the next stage earns its name.

Stage 2: populate — the fields get filled

If a dependency is injected into a field or through a setter, it cannot arrive in the constructor — the object has to exist first, then Spring reaches in and sets it. That second step is populate: the container assigns every field- and setter-injected dependency onto the freshly built object.

@Component
class InventoryService {
    @Autowired private WarehouseClient client;   // set during populate, not in the constructor
}

This ordering explains a bug everyone hits once. A field-injected dependency is null if you touch it inside the constructor:

@Component
class InventoryService {
    @Autowired private WarehouseClient client;

    InventoryService() {
        client.connect();   // NullPointerException — populate hasn't run yet
    }
}

The constructor runs in stage 1. Populate is stage 2. At the moment the constructor body executes, the field is still empty. This is one more reason the previous article pushed constructor injection so hard: it collapses these two stages into one, so a dependency is never half-there. But when you do use field or setter injection, populate is the stage that fills them — and nothing before it can rely on them.

Between populate and the next stage, Spring may also hand the bean a few references to the container itself, if the bean asks for them by implementing an Aware interface (for example BeanNameAware to learn its own bean name). It is a narrow feature you will rarely reach for, but it slots in right here: after the dependencies, before initialization.

Stage 3: initialize — the bean gets ready

Now the object is fully wired. This is the moment to do setup that needs the dependencies in place — open that connection pool, warm a cache, validate configuration. Spring calls this the initialization stage, and it gives you a hook that fires exactly here:

@Component
class InventoryService {
    private final WarehouseClient client;
    private Connection pool;

    InventoryService(WarehouseClient client) {
        this.client = client;
    }

    @PostConstruct
    void openPool() {
        this.pool = client.connect();   // every dependency is guaranteed wired by now
    }
}

The @PostConstruct method runs after populate, so it can lean on every dependency being present — the guarantee the constructor could not give you. This is the right home for "do this once, at startup, after wiring."

There are three ways to register init code, and when more than one is present they run in a fixed order:

A method annotated @PostConstruct — runs first. This is the standard, framework-agnostic choice.
afterPropertiesSet(), if the bean implements the InitializingBean interface — runs second. It couples your class to Spring's API, so it is rarely the better option.
A method named in @Bean(initMethod = "...") — runs last. Useful when the class is third-party and you cannot annotate it.

Reach for @PostConstruct unless you have a specific reason not to. The other two exist mostly for cases where you cannot put an annotation on the method.

The proxy slips in right after init

Remember from the first article that the container can wrap a bean in a proxy — a same-shaped stand-in that runs extra code (a transaction, an async hand-off) around your methods. The lifecycle is where that wrapping actually happens, and exactly when it happens is the source of a classic trap.

Spring exposes the init stage through an interface called BeanPostProcessor, which has two callbacks: one that runs before your init code, and one that runs after. The proxy is created in that second, after-init callback. So the order is:

Populate the bean.
Run your @PostConstruct / init methods — on the raw object.
Then wrap the result in a proxy and store that proxy in the container.

Read step 2 again, because it bites. Inside @PostConstruct, the proxy does not exist yet. The this you are holding is the bare bean. So if your init method calls one of its own proxied methods, the wrapper is skipped:

@PostConstruct
void warmUp() {
    this.reload();   // if reload() is @Transactional, there is NO transaction here
}

reload() may be annotated @Transactional, but calling it through this during init goes straight to the raw method — the proxy that would have opened the transaction has not been built yet. The fix is not to depend on proxied behavior from inside initialization. The lesson generalizes: your own init code always sees the unwrapped bean. Everyone else, fetching the bean from the container later, sees the proxy.

In service

Once initialization and any wrapping are done, the bean is finished. The container drops it on the shelf and hands out that same instance — the proxy, if there is one — to everyone who needs it, for the rest of the application's life. No more lifecycle events fire until shutdown. For a normal singleton, that "in service" period is essentially the whole life of the program.

Stage 4: destroy — teardown at shutdown

When the application context closes — a graceful shutdown, a SIGTERM, the JVM shutdown hook firing — Spring walks its singletons one last time and runs their teardown. This is the place to release what initialization acquired: close the pool, flush the buffer, deregister from a discovery service.

@PreDestroy
void closePool() {
    pool.close();   // mirror of @PostConstruct, run on the way down
}

Destruction mirrors initialization exactly, including the three-way ordering:

A method annotated @PreDestroy — runs first.
destroy(), if the bean implements DisposableBean — runs second.
A method named in @Bean(destroyMethod = "...") — runs last.

One honest caveat: these run only on an orderly shutdown, when Spring is given the chance to close the context. A hard kill — kill -9, a power loss — bypasses the whole stage. So @PreDestroy is the right place for a graceful flush, but it is not a guarantee that your teardown will ever run. Anything that absolutely must survive a crash needs to be durable by other means, not parked in a destroy callback.

The prototype trap

Everything above describes a singleton — the default, one shared instance the container holds and manages. Spring also offers the prototype scope, where you get a brand-new bean every time you ask for one. Prototypes go through the first three stages in full: Spring instantiates them, populates them, and runs their init callbacks.

Then it lets go. Spring does not run the destroy stage for prototype beans. It builds one, hands it to you, and forgets it ever existed — so @PreDestroy on a prototype is never called by the container.

That is a real leak waiting to happen. If a prototype opens a file handle or a socket in @PostConstruct, expecting @PreDestroy to close it, the close never fires and the resource leaks every time you request the bean. For a prototype that holds something which must be released, you are responsible for closing it yourself — the lifecycle only takes you halfway.

Putting it together

A bean is built in four ordered stages, and the order is the whole point. Instantiate makes the raw object — and for constructor injection, wires it at the same time. Populate fills in any field- and setter-injected dependencies, which is why those are null if you touch them too early. Initialize runs your setup once everything is wired, with @PostConstruct as the natural home. And destroy runs your teardown on an orderly shutdown, with @PreDestroy as its mirror.

Two traps fall straight out of that ordering. The proxy is built after your init code, so initialization always sees the unwrapped bean — self-calls to transactional or async methods quietly do nothing there. And prototypes get the first three stages but never the fourth, so anything they open, you must close.

Hold on to the shape rather than the annotations: wired, then ready, then — much later, and only if you shut down cleanly — gone.

Dependency Injection — the problem it solves

Ankit Verma — Mon, 08 Jun 2026 06:43:53 +0000

The first article in this module made one claim and moved on: stop calling new on your collaborators, and let the container hand them in. That was the what. This article is the why — because a rule you don't understand is a rule you'll break the first time it's inconvenient.

Dependency injection is the practice of giving an object the things it needs from the outside, instead of letting it build them itself. You met the name in passing already. Here we look at what it actually buys you, what it costs, and why one way of doing it is plainly better than the rest.

You hit this decision every time you write a class that needs another class. Do you reach for new and build the collaborator inside? Or do you ask for it and let something else supply it? That one choice, repeated across a codebase, is the difference between code you can test and change and code that quietly fights you.

The thing DI actually fights

It is tempting to think the enemy here is the new keyword. It isn't. The enemy is coupling to construction — a class deciding, inside its own body, exactly how its collaborators are built.

Look at what a class signs up for the moment it builds its own collaborator:

class OrderService {
    private final PaymentGateway gateway = new PaymentGateway(new StripeClient());

    void placeOrder(Order order) {
        gateway.charge(order.total());
    }
}

That one line welds together two decisions that have nothing to do with each other:

What OrderService needs — something that can charge money.
Which exact thing it gets, and how that thing is built — this concrete class, wired to Stripe, constructed just so.

The first decision is OrderService's business. The second is not. OrderService should not hold an opinion on whether payments go through Stripe or Adyen, or what a gateway needs underneath. The moment it bakes that opinion into code, the two decisions can never move apart again.

Pulling the two decisions apart

So separate them. Make OrderService depend only on the role — what it needs — and let it state that need without naming a concrete class:

interface PaymentGateway {
    void charge(Money amount);
}

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(PaymentGateway gateway) {   // "give me something that charges"
        this.gateway = gateway;
    }
}

OrderService now names an interface and nothing else. It has no idea which class shows up at runtime. Something outside decides that and supplies it.

The principle you just applied has a name: depend on abstractions, not on concrete implementations — and let an outside party choose and supply the concrete one. Dependency injection is simply the delivery mechanism for that idea. The interface is the contract; injection is how the chosen implementation arrives.

That separation is the whole payoff, and it shows up in three concrete ways.

You can test it. In a test you hand OrderService a fake gateway that records calls instead of hitting a bank — possible only because nothing concrete is baked in.

You can swap implementations. Moving from Stripe to Adyen in production means changing one bean definition. Not a single line of OrderService changes.

The container can wrap what it supplies. Because the gateway arrives from outside, the container gets a chance to hand you something that isn't your plain object — it can wrap it first. That wrap is how @Transactional and the other annotations from the last article attach themselves, and it is only possible because you didn't build the thing yourself.

How Spring picks what to inject

So OrderService asks for a PaymentGateway. How does the container know what to give it?

By type. When Spring builds OrderService and sees a constructor parameter of type PaymentGateway, it looks through the beans it knows about for one whose type fits PaymentGateway, and injects that one.

@Component
class StripeGateway implements PaymentGateway {
    public void charge(Money amount) { /* ... */ }
}

You never told Spring "use StripeGateway for OrderService." You declared a need by type, you have one bean of that type, and the container connected them.

What happens when two classes implement PaymentGateway — how you break the tie — is its own topic later in this module. For now the point is just this: resolution is by type.

Why the style of injection is not a matter of taste

There are three places Spring can put an injected dependency: the constructor, a setter, or straight into a field by reflection. They look interchangeable. They are not — and the difference is mechanical, not stylistic.

Here is the field version. It looks the cleanest and costs the most:

@Service
class OrderService {
    @Autowired private PaymentGateway gateway;   // looks tidy
}

Watch what this quietly allows. The object can be fully built while completely empty — new OrderService() succeeds and hands you an instance whose gateway is null. The field can't be final, so it stays mutable for the object's whole life. The only way to fill it is reflection, so you can't build a valid instance in a plain unit test without dragging Spring in. And the dependency is invisible from outside: nothing in the signature tells a caller this class even needs a gateway.

Now the constructor version:

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(PaymentGateway gateway) {
        this.gateway = gateway;
    }
}

Every one of those problems is gone — and not by convention, by language mechanics. The field is final, so it is set exactly once and the object is immutable after construction. There is no way to create the object without supplying its dependency; the compiler enforces it. And the dependency is right there in the signature for anyone to read.

The testing win becomes concrete the moment you write a test. No framework, no reflection — just a constructor call:

@Test
void chargesTheOrderTotal() {
    var gateway = new RecordingGateway();          // a fake, records instead of charging
    var service = new OrderService(gateway);       // plain Java, no Spring in sight

    service.placeOrder(new Order(Money.of(90)));

    assertThat(gateway.lastCharge()).isEqualTo(Money.of(90));
}

That last point hides the most useful one. Because every dependency has to pass through the constructor, a class with too many of them grows an ugly seven-argument constructor you can't ignore. Field injection lets the same class quietly pile up fifteen @Autowired fields and still look tidy. The constructor turns "this class is doing too much" from a hidden fact into a visible smell. That isn't a style preference — it is design feedback you would otherwise never get.

The circular-dependency trap

There is a sharper version of the same benefit, and it is worth seeing in full. Suppose A needs B, and B needs A — a circular dependency.

With field injection, Spring can often paper over it. It creates both raw objects first, then sets the fields afterward, so the cycle "works" by accident and ships. With constructor injection, neither object can be built before the other exists, so Spring can't even start — it fails at boot with BeanCurrentlyInCreationException.

It is tempting to read that as constructor injection being stricter and therefore more annoying. It is the opposite. The cycle is a real design flaw. Constructor injection forces you to see it the second you boot the app, instead of meeting it as a StackOverflowError in production weeks later. Failing fast, at the safest possible moment, is the feature.

Setter injection is the third style. It has one honest, narrow use: a genuinely optional dependency that can be reconfigured after the object exists. That is rare. Everywhere else, reach for the constructor.

One thing resolution-by-type gives you for free

Because injection is by type, a trick falls out that turns DI into a plugin system. Ask for a List of an interface, and Spring injects every bean that implements it:

interface ShippingRule {
    boolean applies(Order order);
    Money surcharge(Order order);
}

@Service
class ShippingCalculator {
    private final List<ShippingRule> rules;

    ShippingCalculator(List<ShippingRule> rules) {   // every ShippingRule bean, injected
        this.rules = rules;
    }

    Money totalSurcharge(Order order) {
        return rules.stream()
                    .filter(r -> r.applies(order))
                    .map(r -> r.surcharge(order))
                    .reduce(Money.ZERO, Money::add);
    }
}

Adding a new rule is now just adding one @Component that implements ShippingRule. ShippingCalculator never changes — it doesn't even know how many rules exist. That is the plugin pattern, delivered entirely by DI.

One trap rides along with it: the order of the beans in that injected list is not guaranteed unless you make it so. If your rules must run in a set sequence — a discount rule before a tax rule — relying on whatever order Spring happened to hand them in is a bug waiting for the day a refactor reshuffles them. Pin it with @Order on each implementation (or have them implement Ordered), and the list arrives in that order. (Ask for Map<String, ShippingRule> instead, and you get each implementation keyed by its bean name — handy when you need to pick one by name at runtime.)

Putting it together

Dependency injection isn't about dodging a keyword. It is about refusing to let a class decide both what it needs and which implementation it gets — and pulling those apart so the implementation can be swapped, centralized, and wrapped by the container.

Spring resolves the need by type. Constructor injection is the way to receive it — not for neatness, but because the language then guarantees your object is immutable, impossible to build half-wired, trivial to test without the framework, and honest about how many dependencies it really carries. And once injection is by type, the List-of-interface plugin pattern comes for free — just remember to pin the order when it matters.

Why Spring exists; the IoC container in one analogy

Ankit Verma — Mon, 08 Jun 2026 06:41:13 +0000

Spring is a framework that builds and connects the objects your application is made of. You write the classes. Spring creates them, wires them together, and hands them to each other at startup. That sounds like a small favor. It quietly reshapes how the whole codebase fits together, and almost every other Spring feature is built on top of it.

You meet this on day one, usually before anyone names it for you. You open a Spring project, find a class with no new anywhere in it, and wonder where its dependencies actually come from. The answer is the mechanism this article is about.

So this first piece is about why that job needs to exist at all, and the single mechanism Spring uses to do it. Once that mechanism is clear, most of Spring stops looking like magic.

Let's start with no Spring at all, and watch the problem show up on its own.

A class that builds its own tools

Here is a class that needs another class to do its job. The natural instinct is to build what it needs, right where it needs it, with new:

class OrderService {
    private final PaymentGateway gateway = new PaymentGateway(new HttpClient());

    void placeOrder(Order order) {
        gateway.charge(order.total());
    }
}

Look at what OrderService now owns. It places orders — that is its real job. But it also knows how to build a PaymentGateway. And because a gateway needs an HttpClient, it builds that too. One class doing two jobs: its actual work, and the plumbing underneath it.

That second job is where the trouble starts. It costs you three concrete things, and each one points to what comes next.

You can't test it in isolation. The real PaymentGateway calls a real bank. It is baked in with new, so there is no way to slip a fake one in for a test. To test the order logic, you'd have to charge actual money.

The plumbing gets copied everywhere. Every class that needs a gateway writes the same new PaymentGateway(new HttpClient()). Change how a gateway is built, and you have to hunt down every copy.

There is nowhere to add shared behavior. Suppose you want every payment wrapped in a database transaction. With the gateway hard-wired by new, there is no single seam to hook that in.

Handing over control

Now the same class, written the way Spring wants it. It stops building anything. It just states what it needs:

@Service
class OrderService {
    private final PaymentGateway gateway;

    OrderService(PaymentGateway gateway) {   // "I need a PaymentGateway"
        this.gateway = gateway;              // someone hands one in
    }
}

OrderService no longer knows or cares how a PaymentGateway is built. It declares the need in its constructor and trusts that a finished one will arrive from outside.

That flip has a name. Normally your code is in control of creating its own collaborators. Here, your code gives that control away — something else creates the objects and supplies them. Handing that control to the framework is called Inversion of Control, or IoC. The "control" is specifically control over creating and wiring objects. The "inversion" is that it now runs the other way around: the framework builds your objects and calls into them, instead of your objects building everything themselves.

The way the gateway actually arrives — through the constructor above — has its own name: Dependency Injection, or DI. The dependency, the gateway, is injected into OrderService from outside. It can arrive through a constructor, through a setter, or straight into a field. Prefer the constructor: the dependency is visible right there in the signature, and the field can be final, so the object is complete the moment it exists.

So IoC is the idea — your code no longer creates its own collaborators. DI is the delivery — how each collaborator gets in. Which raises the obvious question: who actually does the creating and the handing-over?

The container: a factory that runs at startup

The thing that creates and wires your objects is the container. In Spring it is an object called the ApplicationContext.

Here is the one analogy worth holding onto: the container is a factory. Not "factory" in the design-pattern sense — picture a literal assembly line that runs once, when your application starts. You hand it a list of what to build and how the pieces fit together. It produces every finished, connected object your app is made of, sets them on a shelf, and hands them out on request for the rest of the program's life. Everything below is just detail about how that factory runs.

Two small words have been quietly working and now deserve a definition. To wire two objects is just to give one a reference to the other — to set OrderService's gateway field to a real PaymentGateway instance, so the call inside placeOrder has something to land on. And a bean is simply an object that the factory creates and manages for you. Your @Service, your @Component, the things Spring builds — those are beans. An object you build yourself with new is not a bean, because Spring never touched it. That distinction looks small now; it matters in a minute.

Here is what the factory does, in order:

It scans your code and writes down recipes, not objects. When Spring sees @Component, @Service, or a method marked @Bean, it does not build anything yet. It records a bean definition: which class, how many copies to make, what that bean depends on, and any startup hooks. Think of it as a recipe card, not the finished dish.
It works out the dependency graph. From those recipes it figures out who needs whom. OrderService needs PaymentGateway, which needs HttpClient. A short chain here; in a real app, a wide web.
It builds the objects bottom-up. You can't inject a PaymentGateway before it exists, so Spring builds the leaves of the graph first and works upward, passing each finished bean into the next one's constructor.
It caches each finished bean and reuses it. Once a bean is built, the container keeps it and hands out that same instance to everyone who needs it. It does not build a fresh one each time.

That third step is worth making concrete, because the order is the whole point. Take the chain from earlier: OrderService needs a PaymentGateway, which needs an HttpClient. The factory cannot build OrderService first — it has nothing to put in the constructor yet. So it walks the chain from the bottom:

Build HttpClient. It depends on nothing, so it is a leaf and goes first.
Build PaymentGateway, passing in the HttpClient from step 1.
Build OrderService, passing in the PaymentGateway from step 2.

Three objects, built in the one order that lets each constructor receive a finished dependency. You never wrote a line of that sequencing. The factory read it off the graph and did it for you — and the same logic scales from this three-link chain to a graph with thousands of beans.

By the time startup finishes, every bean exists and every dependency is in place. Asking for one is now instant, because the work already happened:

ApplicationContext ctx = SpringApplication.run(App.class, args);
OrderService svc = ctx.getBean(OrderService.class); // already built and wired

The extra move: wrapping a bean in a proxy

There is one more thing the factory can do while it builds a bean, and it explains a surprising amount of Spring. While assembling a bean, the container can wrap it in a proxy before handing it over.

A proxy is a stand-in object. It looks exactly like your bean — same type, same methods — but it runs a little extra code before and after each call, then forwards to your real object. Callers cannot tell the difference. They think they are holding your bean directly.

That one trick is the real answer to a whole family of "how does Spring even do that?" questions:

@Transactional works because the proxy opens a database transaction before your method runs, and commits it after the method returns.
@Async works because the proxy hands your call off to run on another thread.
Security and caching annotations work the same way — extra code wrapped neatly around your untouched method.

This is also the seam the third cost was missing earlier. Back when OrderService built its own gateway with new, there was nowhere to slip in "wrap every payment in a transaction." Now there is: the gateway arrives from the factory, so the factory gets one chance, at build time, to hand back a wrapped version instead of the bare one. You wrote a plain method; the container wrapped it at startup. Hold on to this frame, because it keeps paying off: most Spring features are just the container doing extra work while it assembles your beans.

The one rule that ties it together

All of this only works on objects the container built. The moment you build one yourself, none of it happens:

OrderService svc = new OrderService(); // built by you, not Spring
// no gateway injected — Spring never saw this object

The usual symptom is a NullPointerException on a field you were sure Spring would fill in. Spring did not create the object, so it never wired it, and the field stayed null.

The same bypass quietly kills proxies. Call a @Transactional method on a hand-built instance, and there is no proxy around it, so no transaction ever starts. Nothing errors. The transaction simply isn't there. This is exactly why the bean-versus-new distinction from earlier mattered: Spring's powers ride on objects the factory made, and skip everything it didn't.

So the rule is short: if you want any of Spring's powers on an object, let Spring create the object. Don't new your beans.

Putting it together

Spring exists to take one job off your code: creating and connecting objects. Hand that job over, and three ideas fall out of it.

Inversion of Control is the handover itself — your code stops creating its own collaborators. Dependency injection is how those collaborators arrive, best through the constructor. And the container is the factory that does the work: it reads your recipes at startup, builds the objects in dependency order, caches them, and can quietly wrap each one in a proxy on the way out.

That last move, the proxy, is why so much of Spring feels like magic later. It isn't magic. It is the factory doing extra work as it builds your beans. Bean scopes, AOP, transactions — everything heavier you meet from here is a variation on this one startup pass.

DEV Community: Ankit Verma

Recap — M0 Foundations

The factory, in one picture

Why we hand the work over at all

How a single bean comes to life

How many, and how long

Which container is doing all this

How you tell the factory what exists — and how it finds it

How the factory connects the beans

The two threads that run through everything

The traps, as one family

The one picture to keep

@Autowired resolution, @Qualifier/@Primary, injection types + circular-dependency gotcha

The happy path: resolution by type

Where did @Autowired go?

When two beans fit one slot

Tie-breaker 1: the parameter name

Tie-breaker 2: @Primary — declare a default winner

Tie-breaker 3: @Qualifier — name the one you want

When the bean might not be there

Injection types, seen through resolution

The circular-dependency gotcha, in full

Putting it together

Component scanning & stereotypes

The mark and the search are two halves of one thing

Turning the scan on

Where the search starts — and the classic trap

The stereotypes: same scan, different meaning

@Repository earns more than its name

Every scanned bean gets a name

Scanning too wide

Putting it together

Configuration styles: XML annotations Java config

The recipe cards have to come from somewhere

The XML era: configuration as a separate file

Moving the marks into the code

The wall annotations hit

Java config: methods that build beans

How Java-config beans find each other

The @Configuration proxy that makes it safe

Which style, when

Putting it together

ApplicationContext vs BeanFactory

The container's contract is an interface

Driving the bare factory by hand

What the bare factory quietly doesn't do

ApplicationContext: the factory, fully staffed

Eager startup — the difference you can feel

One of the extras, in action: events

So which one do you use?

Putting it together

Bean scopes (singleton/prototype/request/session) + singleton thread-safety gotcha

The default you have already been using

Asking for a fresh one each time: prototype

Why the default is a singleton — and the trap hiding inside it

Scopes that follow the web request

The scoped-proxy fix

The prototype-in-singleton trap

Putting it together

Bean lifecycle: instantiate populate init destroy

The four stages, in one breath

Stage 1: instantiate — a bare object

Stage 2: populate — the fields get filled

Stage 3: initialize — the bean gets ready

The proxy slips in right after init

In service

Stage 4: destroy — teardown at shutdown

The prototype trap

Putting it together

Dependency Injection — the problem it solves

The thing DI actually fights

Pulling the two decisions apart

How Spring picks what to inject

Why the style of injection is not a matter of taste

The circular-dependency trap

One thing resolution-by-type gives you for free

Putting it together

Why Spring exists; the IoC container in one analogy

A class that builds its own tools

Handing over control

Where did `@Autowired` go?

Tie-breaker 2: `@Primary` — declare a default winner

Tie-breaker 3: `@Qualifier` — name the one you want