The IoC Container

In traditional procedural or tightly coupled object-oriented architectures, high-level business services directly instantiate their own low-level dependencies (such as new SqlTaskRepository()). This hardcodes infrastructure details directly into domain logic, makes unit testing without real external systems impossible, and requires modifying source code whenever an implementation changes.

The Spring IoC container serves as the central registry, assembler, and lifecycle coordinator. It maintains the single source of truth for runtime singleton instances, ensures that dependencies are injected before an object executes, and wraps components in dynamic proxies when cross-cutting concerns like transactions or security are requested.

At the heart of Spring lies a fundamental architectural division between two container contracts: BeanFactory and ApplicationContext. Understanding their internal differences is crucial for diagnosing startup issues, memory consumption, and enterprise behavior.

org.springframework.beans.factory.BeanFactory is the root interface of the IoC container. It provides basic configuration and lookup facilities (getBean(), containsBean(), isSingleton(), getType()). Its primary implementation is DefaultListableBeanFactory. By default, BeanFactory uses lazy initialization: it does not instantiate or wire a bean until application code explicitly requests it via getBean(). This made it ultra-lightweight for memory-constrained environments 20 years ago, but introduces severe production risk: configuration errors, missing classes, and broken wirings remain hidden at startup and crash at runtime during customer traffic.

org.springframework.context.ApplicationContext is a complete enterprise superset that extends BeanFactory (specifically ListableBeanFactory and HierarchicalBeanFactory). By default, it uses eager pre-instantiation of singletons: during startup (refresh()), it instantiates, wires, and validates every non-lazy singleton bean. This provides a fail-fast guarantee: configuration mistakes, missing dependencies, or circular constructor references crash immediately at application startup in CI or staging, never in front of end users.

Over its 20-year evolution, Spring supported three major configuration styles. While modern Spring Boot applications standardise on Java-based configuration and annotations, understanding their evolution and how Spring Boot maintains basic XML interoperability is vital for enterprise developers.

1
2
3
4
5
6
7
8
9
10
11
12

<!-- 1. HISTORICAL / LEGACY XML CONFIGURATION -->
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="taskRepository" class="com.example.tasks.InMemoryTaskRepository"/>

    <bean id="taskService" class="com.example.tasks.TaskService">
        <constructor-arg ref="taskRepository"/>
    </bean>
</beans>

To use legacy XML configuration inside a modern Spring Boot application, annotate any @Configuration class with @ImportResource("classpath:beans.xml"). Spring Boot automatically boots the XML reader and registers those bean definitions alongside modern annotations.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// 2. STEREOTYPE ANNOTATION CONFIGURATION (Co-located with classes)
@Repository
public class InMemoryTaskRepository implements TaskRepository {}

@Service
public class TaskService {
    private final TaskRepository taskRepository;
    public TaskService(TaskRepository taskRepository) { // Pure constructor injection
        this.taskRepository = taskRepository;
    }
}

// 3. MODERN JAVA-BASED CONFIGURATION (@Configuration & @Bean)
@Configuration(proxyBeanMethods = true)
@ImportResource("classpath:beans.xml") // Basic XML interoperability if needed
public class AppConfig {

    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper().findAndRegisterModules(); // Ideal for 3rd-party library beans
    }
}

Every Spring container bootstrap centers on one critical method: AbstractApplicationContext.refresh(). This method executes a deterministic, 12-step sequence that moves from raw configuration metadata to a verified, running object graph.

1. 01prepareRefresh(): Records startup timestamp, initializes property sources, and validates required environment variables.
2. 02obtainFreshBeanFactory(): Creates and initializes the internal DefaultListableBeanFactory engine.
3. 03prepareBeanFactory(): Configures standard ClassLoader, SpEL resolver, property editors, and registers standard Aware callbacks.
4. 04invokeBeanFactoryPostProcessors(): Executes BeanFactoryPostProcessors (like ConfigurationClassPostProcessor, which scans @Component classes and parses @Bean methods into BeanDefinitions before any beans are created).
5. 05registerBeanPostProcessors(): Finds and registers all BeanPostProcessor definitions, sorted by @Order and PriorityOrdered.
6. 06initMessageSource(): Configures internationalization and message resolution subsystem.
7. 07initApplicationEventMulticaster(): Configures internal event bus for publishing and handling ApplicationEvents.
8. 08onRefresh(): Subclass hook (Spring Boot starts embedded Tomcat/Jetty web server here).
9. 09registerListeners(): Registers all ApplicationListener beans with the event multicaster.
10. 10finishBeanFactoryInitialization(): The critical execution phase: iterates through all non-lazy singleton BeanDefinitions, resolving dependencies, running BeanPostProcessors, and caching singletons.
11. 11finishRefresh(): Publishes ContextRefreshedEvent to notify listeners that the application is fully running.

The most common architectural bug among junior developers is assuming that adding annotations like @Service or @Transactional to a class makes all instances of that class managed by Spring, regardless of how they are instantiated.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Service
public class TaskService {
    @Autowired
    private TaskRepository repository; // Field injection anti-pattern

    @Transactional
    public void execute(long id) {
        repository.findById(id); // Will throw NullPointerException!
    }
}

// In another class or test:
TaskService service = new TaskService(); // Calling 'new' bypasses the container entirely!
service.execute(42);

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "TaskRepository.findById(long)" because "this.repository" is null
    at com.example.tasks.TaskService.execute(TaskService.java:12)
    at com.example.tasks.BypassedContainerDemo.main(BypassedContainerDemo.java:18)

The fix is architectural: always allow Spring to instantiate and supply dependencies via constructor injection, or retrieve the managed bean directly from the ApplicationContext.