Spring Core

Spring Core is the foundational module of Spring providing IoC container and dependency injection features.

A principle where object creation and dependency wiring are delegated to a container.

Supplying dependencies from outside a class rather than constructing them internally.

Better testability, loose coupling, and clearer object responsibilities.

An object managed by the Spring container.

Basic Spring container interface for managing beans.

Advanced container interface extending BeanFactory with enterprise features.

ApplicationContext adds events, message source, resource loading, and more convenient capabilities.

Instructions telling container what beans to create and how to wire them.

XML, Java-based @Configuration, and component scanning annotations.

Generic stereotype for auto-detected Spring-managed classes.

Specialized stereotype for service-layer beans.

Persistence stereotype that also participates in data-access exception translation.

Stereotype for presentation layer beans (commonly MVC controllers).

Automatic discovery of candidate beans in specified packages.

Class contains bean definitions (typically methods annotated with @Bean).

Registers the method return object as a bean in the context.

Annotation for automatic dependency injection by type.

Constructor, setter, and field injection.

Constructor injection.

Makes required dependencies explicit and supports immutability.

Multiple candidate beans match one injection point.

Use @Qualifier or @Primary.

Annotation selecting a specific bean candidate.

Marks one bean as default autowire candidate.

Defines lifecycle/visibility of bean instances.

Singleton.

One bean instance per container.

New bean instance each time requested.

Request, session, application, websocket (in web-aware contexts).

Instantiation, dependency population, initialization, and destruction.

Lifecycle callback after dependency injection and before use.

Lifecycle callback before bean destruction.

Typically no; container doesn’t fully manage prototype destruction lifecycle.

Bean created only when first needed.

Use @Lazy on bean or configuration.

Beans created at context startup (default for singletons).

Two or more beans depend on each other directly/indirectly.

Usually no; it signals tight coupling and design issues.

Programmatically retrieving beans from container (e.g., getBean).

DI is preferred; lookup couples code to container API.

Callback to access ApplicationContext from a bean.

No; prefer constructor DI and explicit dependencies.

Abstraction to access profiles and properties.

Origin of key-value config (files, env vars, system properties, etc.).

Injects single property/expression into bean fields/params.

Spring Expression Language for dynamic value expressions.

Adds external property file to Spring Environment.

Conditional activation mechanism for bean definitions per environment.

Through config, environment variables, JVM args, or programmatic setup.

Container matches dependency using its type.

Yes, lists/sets/maps of matching bean types.

Usually decapitalized class name or method name for @Bean.

Providing DI container and fundamental infrastructure abstractions.

Prefer constructor injection, clear bean boundaries, and explicit configuration.

Internal metadata representation of a bean configuration.

Registry storing BeanDefinitions before bean instantiation.

Allows modifying bean definitions before beans are created.

Intercepts bean instances before/after initialization callbacks.

One changes metadata pre-instantiation; other decorates actual bean instances.

Advanced hook around instantiation and property population phases.

Hook for custom logic before bean destruction.

Special bean that itself produces other objects.

By name for product; prefix with & for factory bean instance.

Provider-style lazy access to bean instances.

Enhanced provider with optional/stream-friendly retrieval.

Handle optional or multiple beans lazily without hard failure.

Spring resolves constructor args, then properties, then init callbacks.

Forces initialization order between beans.

Use sparingly; often indicates hidden coupling.

Defines precedence among ordered beans (where applicable).

Alternative way to provide order value programmatically.

Higher-priority ordering contract used in infrastructure processing.

Combined metadata after parent/child and defaults resolution.

Bean definition inheritance for shared configuration templates.

Container overrides methods to return managed dependencies dynamically.

Injects prototype dependency into singleton via method override.

Legacy mechanism to replace method implementation at runtime.

Creates subclasses/proxies for certain runtime enhancements.

They limit subclass-based proxy/enhancement strategies.

Proxy enabling narrower-scoped bean injection into broader-scoped beans.

Inject request-scoped bean into singleton service safely.

Bean eligible for selection at injection points.

Configuration flags (XML/bean definition) or design patterns to hide internal beans.

Special dependency type provided directly by container (e.g., ApplicationContext).

Type conversion system used during property binding and injection.

Converter is modern type-safe approach; PropertyEditor is older mutable API.

Locale-aware text formatting/parsing abstraction.

Resolves placeholders and expressions in annotation attributes/strings.

Usually ${property.name}.

Can fail startup unless default provided or ignore settings enabled.

Syntax like ${name:defaultValue}.

Unified access to classpath/file/url resources.

ClassPathResource, FileSystemResource, UrlResource, ByteArrayResource.

Strategy interface to load resources by location string.

Base type for events published within Spring context.

Using ApplicationEventPublisher.

With @EventListener methods or listener interfaces.

Synchronous by default (unless configured otherwise).

Lifecycle contract with phase control and auto-start behavior.

Controls startup/shutdown order among lifecycle beans.

Strategy for internationalization (i18n) message resolution.

BeanFactory supporting parent-child container relationships.

Share common infrastructure beans across child contexts.

Reinitialize container state and recreate singleton beans.

Shuts container down and triggers destruction callbacks.

Fail fast with clear diagnostics when mandatory beans/properties are missing.

Registering another bean with same name, replacing existing definition (policy-dependent).

It causes unpredictable wiring and hard-to-debug behavior.

Programmatic/profile/property-based conditions deciding bean creation.

Conditionally registers bean when profile is active.

Injects proxy/provider delaying actual target resolution.

Annotation-based lookup method injection.

Callback after all singleton beans are instantiated.

Post-bootstrap coordination once singleton graph is ready.

Hint distinguishing application/support/infrastructure beans.

Improves maintainability and avoids accidental application coupling.

Reads class metadata without loading every class eagerly.

Improves startup and avoids side effects.

Use extension points intentionally; keep container customizations minimal and well-tested.

Primary Spring bean factory implementation handling registration and autowiring.

Interface for programmatic wiring/initialization of existing objects.

It can bypass clean architecture and couple code to container internals.

Algorithm selecting constructor for bean instantiation/autowiring.

Helps resolve dependencies and bind values when names are needed.

Unified view over direct/meta/repeatable annotations for consistent processing.

Container-generated definition not directly declared by user.

BeanPostProcessor that wraps eligible beans with proxies for cross-cutting behavior.

Proxy types may differ; equality semantics must be designed carefully.

Strategy for obtaining actual target object behind proxy.

Swap implementation instances at runtime behind stable proxy.

More indirection, memory overhead, and debugging complexity.

Complex circular references plus locks can stall startup in extreme cases.

Smaller modules, explicit boundaries, event-driven decoupling.

Verify required beans/contracts at startup per module.

Programmatic bean registration style (common in advanced/bootstrap scenarios).

Hook to customize context before refresh.

Early hook to customize property sources before app context fully builds.

Wrong-phase customization may be ignored or applied too late.

Dynamic reflection/proxy behavior may need hints or alternative generation strategies.

Reflective access may require opened modules/packages.

Too many profile-specific variants causing configuration complexity.

Layer shared defaults, minimize branching, document environment matrix.

Large bean graphs and metadata caches increase startup/runtime memory usage.

Reduce scanning scope, avoid unnecessary beans, prefer lazy where sensible.

Creating smaller focused contexts per service/module/tests.

It slows startup and increases coupling/failure blast radius.

Measuring creation times and failures per bean for diagnostics.

Enable debug logs, custom post-processors, startup metrics/reporting.

Dependency resolution should be explicit and reproducible across environments.

Using container lookups or static holders instead of explicit constructor dependencies.

They reduce readability, testability, and refactoring safety.

Register extension beans via interfaces and discover/invoke dynamically.

Strict interfaces, validation, isolation boundaries, and controlled classloading.

Injecting short-lived stateful bean into long-lived singleton incorrectly.

Scoped proxies, providers, or redesign state handling.

Bind external properties once into validated immutable classes.

Thread-safety, predictability, and safer runtime behavior.

Detecting differences between expected and actual runtime configuration.

Package rules, dependency direction checks, and context-level contract tests.

Context integration tests for wiring + focused unit tests for business logic.

Disallow by default in large codebases unless explicit need exists.

Optional subsystems fail independently while critical core still boots (carefully controlled).

Minimum bean set required before app can serve traffic.

Improves reliability, readiness checks, and incident recovery speed.

Over-customizing container internals when simpler design would solve the problem.

Only for cross-cutting infrastructure concerns not achievable by simpler means.

Clear modules, explicit DI, minimal magic, observable lifecycle, and predictable wiring.

Purpose, ordering, affected beans, failure modes, and rollback plan.

Treat the container as infrastructure foundation—keep domain logic independent and clean.