Spring Application Context Events

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.

Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.

In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:

>> Flexible Pub/Sub Messaging With Spring Boot and Dapr

1. Introduction

In this tutorial, we’ll learn about the event support mechanism provided by the Spring framework. We’ll explore the various built-in events provided by the framework and then see how to consume an event.

To learn about creating and publishing custom events, have a look at our previous tutorial here.

Spring has an eventing mechanism which is built around the ApplicationContext. It can be used to exchange information between different beans. We can make use of application events by listening for events and executing custom code.

For example, a scenario here would be to execute custom logic on the complete startup of the ApplicationContext.

2. Standard Context Events

In fact, there’re a variety of built-in events in Spring, that lets a developer hook into the lifecycle of an application and the context and do some custom operation.

Even though we rarely use these events manually in an application, the framework uses it intensively within itself. Let’s start by exploring various built-in events in Spring.

2.1. ContextRefreshedEvent

On either initializing or refreshing the ApplicationContext, Spring raises the ContextRefreshedEvent. Typically a refresh can get triggered multiple times as long as the context has not been closed.

Notice that, we can also have the event triggered manually by calling the refresh() method on the ConfigurableApplicationContext interface.

2.2. ContextStartedEvent

By calling the start() method on the ConfigurableApplicationContext, we trigger this event and start the ApplicationContext. As a matter of fact, the method is typically used to restart beans after an explicit stop. We can also use the method to deal components with no configuration for autostart.

Here, it’s important to note that the call to start() is always explicit as opposed to refresh().

2.3. ContextStoppedEvent

A ContextStoppedEvent is published when the ApplicationContext is stopped, by invoking the stop() method on the ConfigurableApplicationContext. As discussed earlier, we can restart a stopped event by using start() method.

2.4. ContextClosedEvent

This event is published when the ApplicationContext is closed, using the close() method in ConfigurableApplicationContext.
In reality, after closing a context, we cannot restart it.

A context reaches its end of life on closing it and hence we cannot restart it like in a ContextStoppedEvent.

3. @EventListener

Next, let us explore how to consume the published events. Starting from version 4.2, Spring supports an annotation-driven event listener – @EventListener.

In particular, we can make use of this annotation to automatically register an ApplicationListener based on the signature of the method :

@EventListener
public void handleContextRefreshEvent(ContextStartedEvent ctxStartEvt) {
    System.out.println("Context Start Event received.");
}

Significantly, @EventListener is a core annotation and hence doesn’t need any extra configuration. In fact, the existing <context:annotation-driven/> element provides full support to it.

A method annotated with @EventListener can return a non-void type. If the value returned is non-null, the eventing mechanism will publish a new event for it.

3.1. Listening to Multiple Events

Now, there might arise situations where we will need our listener to consume multiple events.

For such a scenario, we can make use of classes attribute:

@EventListener(classes = { ContextStartedEvent.class, ContextStoppedEvent.class })
public void handleMultipleEvents() {
    System.out.println("Multi-event listener invoked");
}