Method Injection: @Lookup, lookup-method & replaced-method

## The core problem: scope mismatch Spring beans have scopes. A **singleton** bean is created **once** by the container and cached; every injection point receives that same shared instance. A **prototype** bean is meant to produce a **brand-new instance every time it is requested**. Dependency injection happens **once, at bean-creation time**. So if you inject a prototype into a singleton the normal way (constructor or field), Spring resolves the prototype exactly once — when it builds the singleton — and stores that single instance in the singleton's field forever. Every method call on the singleton then reuses the *same* prototype object. The prototype's 'new instance per request' promise is silently broken. ```java @Component // singleton class Processor { @Autowired Task task; // prototype, but resolved ONCE — always the same object void run() { task.execute(); } // same task every time } ``` ## The fix: method injection Instead of injecting the *instance*, you inject a *method that fetches a fresh instance*. Spring supports this in two forms: - **`@Lookup`** (annotation): annotate a method — typically `abstract` — whose body Spring generates. Each invocation returns a newly resolved bean of the method's return type. - **`<lookup-method>`** (XML): the same mechanism declared in XML on a `<bean>`. Under the hood Spring creates a **CGLIB subclass** of your bean and overrides the lookup method to call `getBean(...)` on the container, so each call yields a fresh prototype. ```java @Component abstract class Processor { void run() { createTask().execute(); } // fresh Task each call @Lookup protected abstract Task createTask(); // Spring implements this } ``` ## Why not just inject ApplicationContext and call getBean? You can (`context.getBean(Task.class)`), and it works, but it couples your business class to the Spring container API — an anti-pattern that hurts testability and clarity. Method injection is the container-native way to express 'give me a fresh one each time' without that coupling. ## When to use it - A **long-lived (singleton) bean** needs a **shorter-lived (prototype) collaborator** on demand. - You want to avoid `ApplicationContextAware` / manual `getBean`. In modern code, injecting `ObjectProvider<Task>` / `Provider<Task>` and calling `getObject()` / `get()` is usually preferred (no CGLIB, no abstract methods) — but `@Lookup` remains the classic container-overridden approach and still appears widely.