#ioc-container
Posts
-
Digging into Gradle's Source 4: The Service Registry — the DI Container Inside Gradle
Who puts a FileSystemOperations into your task when you mark its constructor with @Inject? This post reads DefaultServiceRegistry, one per scope, which looks services up through its parents; the rules for declaring services with @Provides methods and decorators; lazy singletons created on first lookup; ServiceScopeValidator, which keeps services in their proper scope; GradleModuleServices, through which 57 modules add services to every scope; and the _Decorated classes that fill in abstract getters. We use the registry directly outside a build and print the stack of a task being created to check it all against the source.
-
Digging into Spring's Source 5: How @Autowired Picks the Bean to Inject — Dependency Resolution
Which bean Spring puts into an @Autowired field or constructor, how it finds that bean, and how it chooses when there are several — followed through the real source. Candidate lookup, the precedence of @Primary, @Qualifier and name matching, List and Map injection, the constructor selection rules, and what happens when nothing is found, each checked by running an example.
-
Digging into Spring's Source 6: Lifecycle Callbacks and PostProcessors — Where You Can Step into the Container
When exactly, and in what order, are BeanFactoryPostProcessor, BeanPostProcessor and its sub-interfaces, the Aware interfaces, @PostConstruct, InitializingBean, init-method, @PreDestroy, DisposableBean, destroy-method, SmartInitializingSingleton and SmartLifecycle called? Checked against the real source and real program output, with a look at why there are so many different hooks.
-
Digging into Spring's Source 7: The Twelve Steps of refresh() — the Order in Which the Container Starts
Behind the single line new AnnotationConfigApplicationContext(...) runs refresh(). This post opens its twelve steps one by one, and checks in the real source and with runnable examples what ApplicationContext adds on top of BeanFactory, why there are two branches (GenericApplicationContext and AbstractRefreshableApplicationContext), and what happens when startup fails or when close() is called.
-
Digging into Spring's Source 8: How @Configuration and @ComponentScan Become Blueprints
How a configuration class (@Configuration), its @Bean methods, and the @Component classes found by @ComponentScan turn into bean blueprints (BeanDefinition), followed step by step for someone new to Spring. How ConfigurationClassPostProcessor reads blueprints to add more blueprints, how component scanning reads class files without loading them, and why a @Configuration class is wrapped with CGLIB so that calling a @Bean method twice still gives you the same object — all checked against the real source and runnable examples.
-
Digging into Spring's Source 9: @Conditional, @Profile and @Import — Choosing Beans by Condition
How @Conditional and @Profile, which register a bean only when a condition holds, and @Import, which pulls in other configuration, are evaluated inside the container — when and how — explained for someone new to Spring. Why a condition is evaluated three times, the three kinds of @Import, what DeferredImportSelector "defers" and why, the ImportStack that catches circular imports, and why every @EnableXxx is just @Import in disguise, all checked against the real source and small runnable examples.
-
Digging into Spring's Source 3: The BeanFactory Hierarchy and BeanDefinition
Before Spring builds an object it prepares a blueprint for it (BeanDefinition), and it hands objects out through a front desk (BeanFactory) that is split into several small interfaces. This post follows both through real source excerpts and diagrams, written for someone new to Spring.
-
Digging into Spring's Source 4: How a Bean Gets Created — the Creation Flow and the Three-Level Cache
What happens inside Spring when getBean() is called once, followed step by step for someone new to Spring. The cache lookup, the three creation steps (instantiate, inject, initialise), and how three maps untangle a circular reference where A needs B and B needs A — all checked against the real source.