The Spring ApplicationContext is the central runtime container of a Spring application.
In simple terms:
ApplicationContext is the object that holds your Spring application together.
It knows:
- which objects Spring should manage
- how those objects are created
- how dependencies are injected
- which configuration values are available
- which beans need lifecycle callbacks
- which features like transactions, events, MVC, or JPA are enabled
1. The Short Definition
A Spring ApplicationContext is a container for Spring beans.
A bean is an object managed by Spring.
For example, if you have:
@Service
public class UserService {
}
Spring creates an instance of UserService and stores/manages it inside the ApplicationContext.
Conceptually:
ApplicationContext
├── userService
├── userRepository
├── orderService
├── dataSource
├── transactionManager
└── many internal Spring infrastructure beans
2. Why Does Spring Need an ApplicationContext?
Without Spring, you create and connect objects yourself:
UserRepository repository = new UserRepository();
UserService service = new UserService(repository);
With Spring, you describe the objects and dependencies, and Spring does the wiring:
@Service
public class UserService {
private final UserRepository userRepository;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
}
@Repository
public class UserRepository {
}
Spring sees both classes, creates both objects, and injects UserRepository into UserService.
The place where Spring manages all of this is the ApplicationContext.
3. What the ApplicationContext Contains
The ApplicationContext contains two broad categories of things:
Your application beans
Examples:
UserController
UserService
UserRepository
OrderService
PaymentService
These are the objects you usually write.
Spring infrastructure beans
Examples:
DataSource
EntityManagerFactory
TransactionManager
MessageSource
ConversionService
HandlerMapping
BeanPostProcessor
These are objects Spring uses internally to provide features like:
- dependency injection
- transactions
- validation
- Spring MVC routing
- database integration
- event publishing
- configuration loading
So the context contains both your application and the framework infrastructure around it.
4. What Happens When the ApplicationContext Starts?
When a Spring application starts, Spring creates an ApplicationContext.
A simplified startup flow looks like this:
1. Create the ApplicationContext
2. Read configuration classes, annotations, properties, and component scans
3. Discover bean definitions
4. Decide which beans should exist
5. Create singleton beans
6. Inject dependencies
7. Run bean lifecycle callbacks
8. Apply bean post-processors
9. Create proxies if needed
10. Publish startup events
11. Application is ready
A key detail: Spring first builds bean definitions, then creates actual bean instances.
5. Bean Definition vs. Bean Instance
This distinction helps a lot.
A bean definition is Spring’s recipe for creating a bean.
It includes information like:
Bean name: userService
Bean type: UserService
Scope: singleton
Dependencies: userRepository
Initialization method: maybe present
Lazy or eager: depends on configuration
A bean instance is the actual object created from that recipe.
So conceptually:
Bean definition:
"I know how to create UserService."
Bean instance:
new UserService(userRepository)
The ApplicationContext manages both the recipes and the actual objects.
6. Most Beans Are Singletons by Default
By default, Spring creates one shared instance of each bean per ApplicationContext.
That means this:
@Service
public class UserService {
}
usually results in one UserService object shared wherever it is injected.
So if three controllers need UserService, they all receive the same Spring-managed instance.
UserController ─┐
AdminController ─┼──> same UserService bean
ReportController ┘
This is why Spring service beans should usually be stateless or carefully designed for thread safety.
7. You Usually Do Not Use ApplicationContext Directly
You can ask the context for a bean:
ApplicationContext context = ...;
UserService userService = context.getBean(UserService.class);
But in normal Spring application code, you usually should not do this.
Prefer dependency injection:
@Service
public class ReportService {
private final UserService userService;
public ReportService(UserService userService) {
this.userService = userService;
}
}
This is better because:
- dependencies are explicit
- the class is easier to test
- the class is not tightly coupled to Spring’s container API
- Spring can validate dependencies at startup
Use ApplicationContext#getBean() only when you truly need dynamic lookup.
8. ApplicationContext Is More Than a Bean Factory
Spring has a lower-level interface called BeanFactory.
A BeanFactory can create and manage beans.
ApplicationContext extends that idea and adds higher-level application features, such as:
- event publishing
- internationalization/message resolution
- resource loading
- environment and property access
- integration with Spring AOP
- web application support
- lifecycle management
So you can think of it like this:
BeanFactory:
Basic bean creation and dependency injection
ApplicationContext:
BeanFactory + application-level services
In most real applications, you work with ApplicationContext, not directly with BeanFactory.
9. ApplicationContext and Dependency Injection
The most important job of the ApplicationContext is dependency injection.
Given this:
@Service
public class OrderService {
private final PaymentService paymentService;
private final OrderRepository orderRepository;
public OrderService(
PaymentService paymentService,
OrderRepository orderRepository
) {
this.paymentService = paymentService;
this.orderRepository = orderRepository;
}
}
Spring roughly does this:
1. See that OrderService is a bean
2. See that it needs PaymentService and OrderRepository
3. Find matching beans
4. Create those dependencies if needed
5. Call the OrderService constructor
6. Store the created OrderService bean in the context
You do not manually create the dependency graph. The ApplicationContext does.
10. ApplicationContext and Proxies
Sometimes the object you get from Spring is not the raw object you wrote.
It may be a proxy.
For example:
@Service
public class TransferService {
@Transactional
public void transferMoney() {
// database work
}
}
When @Transactional is involved, Spring may wrap TransferService in a proxy.
Conceptually:
Caller
↓
Transaction proxy
↓
Real TransferService
The proxy adds behavior around your method call:
begin transaction
call transferMoney()
commit transaction
or, if there is an error:
rollback transaction
This is why calls between Spring beans often need to go through the Spring-managed object, not through manually created objects.
The ApplicationContext is responsible for creating and managing those proxied beans.
11. ApplicationContext in a Web Application
In a Spring MVC web application, the ApplicationContext also contains web-related infrastructure.
For example:
Controller beans
Handler mappings
Request mappings
Message converters
Validation support
Exception handlers
View resolvers, if using server-side views
When a request arrives, Spring MVC uses beans from the context to decide:
GET /users/42
maps to something like:
@GetMapping("/users/{id}")
public UserDto findUser(@PathVariable Long id) {
// ...
}
So in a web app, the context is not just managing services and repositories. It also supports request handling.
12. ApplicationContext in Spring Data JPA
With Spring Data JPA, repository interfaces are also managed through the context.
For example:
public interface UserRepository extends JpaRepository<User, Long> {
Optional<User> findByEmail(String email);
}
You do not create the implementation manually.
Spring Data creates a repository bean and registers it in the ApplicationContext.
Then you can inject it:
@Service
public class UserService {
private final UserRepository userRepository;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
}
The context knows that UserRepository is a Spring-managed bean, even though you did not write the implementation class yourself.
13. Common Types of ApplicationContext
Different application types use different context implementations.
For annotation-based configuration, you may see:
AnnotationConfigApplicationContext
For web applications, Spring uses web-aware contexts.
In Spring Boot, you often do not create the context directly. You usually start the app with:
@SpringBootApplication
public class MyApplication {
public static void main(String[] args) {
SpringApplication.run(MyApplication.class, args);
}
}
SpringApplication.run(...) creates and starts the ApplicationContext for you.
14. A Small Manual Example
In a non-Boot or learning example, you might create the context manually:
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
public class Main {
public static void main(String[] args) {
ApplicationContext context =
new AnnotationConfigApplicationContext(AppConfig.class);
GreetingService greetingService =
context.getBean(GreetingService.class);
System.out.println(greetingService.greet("World"));
}
}
But in real application classes, prefer injection over calling getBean().
15. Mental Model
A useful mental model is:
ApplicationContext = Spring's runtime registry and factory
It knows:
- what beans exist
- how to create them
- how to connect them
- how to configure them
- when to initialize them
- when to destroy them
- whether to wrap them in proxies
Your code says:
I need a UserRepository.
I need a PaymentService.
This class is a controller.
This method should be transactional.
This property comes from configuration.
The ApplicationContext says:
I will create those objects,
wire them together,
apply the configuration,
wrap them if needed,
and make the application ready to run.
16. Practical Rules
When working with the ApplicationContext, remember these rules:
- Most application objects should be Spring beans.
- Use constructor injection for dependencies.
- Avoid manually calling
new for services, repositories, and controllers.
- Avoid frequent direct use of
ApplicationContext#getBean().
- Keep singleton beans stateless when possible.
- Remember that Spring may inject a proxy, not the raw class.
- If a bean is missing, check scanning, configuration, profiles, and conditional annotations.
- If multiple beans match, use
@Primary or @Qualifier.
Bottom Line
The Spring ApplicationContext is the running Spring container.
It is responsible for:
- discovering beans
- creating beans
- injecting dependencies
- managing lifecycle
- loading configuration
- publishing events
- supporting framework features
- creating proxies for behavior like transactions
The shortest explanation is:
ApplicationContext is Spring’s runtime container: it creates, stores, wires, configures, and manages the objects that make up your application.
