How do I understand the Spring ApplicationContext?

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.

1. The Short Definition

2. Why Does Spring Need an ApplicationContext?

3. What the ApplicationContext Contains

Your application beans

Spring infrastructure beans

4. What Happens When the ApplicationContext Starts?

5. Bean Definition vs. Bean Instance

6. Most Beans Are Singletons by Default

7. You Usually Do Not Use ApplicationContext Directly

8. ApplicationContext Is More Than a Bean Factory

9. ApplicationContext and Dependency Injection

10. ApplicationContext and Proxies

11. ApplicationContext in a Web Application

12. ApplicationContext in Spring Data JPA

13. Common Types of ApplicationContext

14. A Small Manual Example

15. Mental Model

16. Practical Rules

Bottom Line

Leave a ReplyCancel reply