Spring Core

Inspect the contract and its failure cases.

1. 1Spring ApplicationContext: construct and close an object graph
2. 2Spring constructor injection: required dependencies stay visible
3. 3Spring qualifiers: select a collaborator when types are ambiguous
4. 4Spring bean scopes: singleton identity is not thread safety
5. 5Spring ObjectProvider: deferred resolution without hiding ownership
6. 6Spring lifecycle cleanup: close container-owned resources
7. 7Spring application events: local delivery is not a durable queue
8. 8Spring AOP proxies: self-invocation bypasses proxy advice

Inspect the state boundary and run its checked fixture.

1. 1Spring transaction events: run a listener after commit without claiming durability

Check the boundary and follow the related lessons.

1. 1Spring request scope proxy: resolve state for the current HTTP request

Read the contract, run the checked fixture and inspect the rejected path.

1. 1Spring session scope: one target across requests, separate targets across sessions

Run the source-kit test and inspect the rejected case.

1. 1Spring @Async futures: make worker failure observable to the caller
2. 2Spring async work versus durable delivery: separate latency from recovery

Run the local fixture and inspect the retained state.

1. 1Spring task executors: reject work when every slot is occupied
2. 2Spring async work has two failure points: submission and completion

Trace scheduled claims, retries and duplicate-safe completion.

1. 1Spring TaskScheduler: poll committed outbox rows in the background
2. 2Spring TaskScheduler shutdown: stop new polls and account for in-flight work

Follow the request or object-graph boundary through its failure cases.

1. 1Spring @Component versus @Bean: choose who constructs the dependency
2. 2Spring circular dependencies: break the constructor graph

Run the source-kit test, then inspect the failure and ownership rule.

1. 1Spring @Primary and @Qualifier: default selection versus an explicit bean
2. 2Spring @Configuration proxyBeanMethods: direct calls can create a second object
3. 3Spring @Order on injected lists: execution order is not startup order

Check creation, routing and failure at the exact framework boundary.

1. 1Spring @Lazy singleton: failure moves from context refresh to first use
2. 2Spring @Lazy injection point: defer a dependency behind a proxy
3. 3Spring @DependsOn: force initialization and reverse destruction order

Inspect the local proof and the remaining deployment boundary.

1. 1Spring Modulith module APIs: call the inventory root package, not its internals
2. 2Spring Modulith events: publish a domain fact after a valid state change

Read the checked local boundary and the next integration test.

1. 1Spring Modulith event ordering: decide which state the listener may observe

Definition processing, instance callbacks, factory products and worker drain order.

1. 1Spring BeanFactoryPostProcessor: inspect definitions before instances exist
2. 2Spring BeanPostProcessor: instance callbacks and the early-bean trap
3. 3Spring FactoryBean: expose the product type without constructing it
4. 4Spring SmartLifecycle phases: drain work before destroying dependencies

Concurrent singleton calls, generic injection, prototype lookup, event failures and AOP method limits.

1. 1Spring singleton state: one bean does not mean one request at a time
2. 2Spring generic autowiring: preserve type arguments at the injection point
3. 3Spring @Lookup: obtain a fresh prototype from a singleton method
4. 4Spring synchronous event listener failure: publication can fail the caller
5. 5Spring async event listener: handle detached failures and queue pressure
6. 6Spring AOP final methods: advice requires an interceptable call