@EventListener for Application Events

1. The Publish-Subscribe Pattern in Spring

What we've been building is an implementation of the Publish-Subscribe (or "Pub/Sub") design pattern. This pattern is fundamental to modern, scalable backend systems. It allows components to communicate without knowing about each other's existence, promoting loose coupling.

The core idea is visualized in the diagram below:

The key roles are:

• Publisher: A component that creates and sends an event. In our previous lesson, this was the UserService.
• Event: A simple object that contains data about what happened. We created the UserRegisteredEvent.
• EventMultiCaster: An intermediary (often called an event bus or broker) that receives events from publishers and routes them to the correct listeners. In Spring, this is handled automatically for you.
• Listener (or Subscriber): A component that registers interest in a specific type of event and performs an action when it receives one. This is our focus today.

2. Creating an Event Listener with @EventListener

Before Spring 4.2, creating a listener required implementing the ApplicationListener interface. While that approach still works, the modern and much simpler way is to use the @EventListener annotation.

Here's all you need to do:

1. Create a method inside any Spring-managed bean (e.g., a class annotated with @Component, @Service, etc.).
2. Annotate the method with @EventListener.
3. Define the method to accept a single parameter: the specific event class you want to listen for.

Spring handles the rest. It scans for @EventListener annotations on startup and automatically routes any published event object to the methods whose parameter type matches the event's class.

Let's expand on our previous example. We have a UserService that publishes a UserRegisteredEvent. Now, let's create an EmailNotificationListener to send a welcome email.

import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Component;

// 1. Must be a Spring-managed bean
@Component
public class EmailNotificationListener {

    // 2. Annotate the method
    @EventListener
    // 3. The parameter type determines which event is caught
    public void handleUserRegistration(UserRegisteredEvent event) {
        System.out.println("LISTENER: Received UserRegisteredEvent for email: " + event.getEmail());
        System.out.println("LISTENER: Preparing to send welcome email...");
        // In a real application, you would call your email sending logic here.
        System.out.println("LISTENER: Welcome email logic executed.");
    }
}

It's that simple. You don't need to register the listener with the publisher. The components remain completely decoupled.

To see this implemented in a live coding session, let's watch how the presenter in the Java Techie video creates multiple listeners for the PatientDischargeEvent.

3. Synchronous vs. Asynchronous Listeners

A critical concept to understand is that, by default, event listeners are synchronous.

This means when eventPublisher.publishEvent() is called, the publisher's thread of execution stops and waits until every listener has completed its onApplicationEvent or @EventListener method.

Let's see what happens if we run our code with the UserService from the last lesson and the EmailNotificationListener from this one:

// Output from UserService
User registered: user@example.com
Publishing UserRegisteredEvent...

// Execution now jumps to the listener and BLOCKS
LISTENER: Received UserRegisteredEvent for email: user@example.com
LISTENER: Preparing to send welcome email...
LISTENER: Welcome email logic executed.

// Execution now returns to the publisher
User registration method finished.

The publishEvent() call doesn't return until the listener is done. This is useful if the listener's logic is part of the same transaction, but it can be a problem if the listener is slow. Imagine our email service takes 5 seconds to respond; the user would be stuck waiting 5 extra seconds for their registration to complete.

The video you just watched explains this default blocking behavior perfectly.

Making Listeners Asynchronous

The solution is to make the listener run in a separate thread. Since you are already familiar with the @Async annotation, this will be straightforward. Simply add @Async to your @EventListener method.

import org.springframework.context.event.EventListener;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Component;

@Component
public class EmailNotificationListener {

    @Async // Run this method in a background thread
    @EventListener
    public void handleUserRegistration(UserRegisteredEvent event) {
        // ... same logic ...
    }
}

Don't forget to enable asynchronous processing in your application by adding @EnableAsync to a configuration class or your main application class.

With this change, the publishEvent() call will return almost immediately, and the listener's logic will execute on a different thread from the thread pool. The user registration process is no longer blocked by the email-sending logic.

import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Service;

@Service
public class InventoryService {

    @EventListener
    public void handleOrderPlaced(OrderPlacedEvent event) {
        System.out.println("SYNC LISTENER (Inventory): Order " + event.getOrderId() + " received.");
        System.out.println("Deducting items from stock...");
        // Logic to update inventory would go here.
        System.out.println("Stock updated.");
    }
}

import org.springframework.context.event.EventListener;
import org.springframework.scheduling.annotation.Async;
import org.springframework.stereotype.Service;

@Service
public class AnalyticsService {

    @Async
    @EventListener
    public void handleOrderPlaced(OrderPlacedEvent event) {
        System.out.println("ASYNC LISTENER (Analytics): Order " + event.getOrderId() + " received.");
        // Simulate a slow operation
        try {
            Thread.sleep(3000); // 3-second delay
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println("Logging order details to analytics platform...");
    }
}

Conclusion

Fantastic! You have now mastered the complete, end-to-end flow of Spring's application event mechanism. By combining publishers and listeners, you can create highly decoupled, clean, and extensible backend services.

Key Takeaways:

• You can create an event listener by annotating a method in a Spring bean with @EventListener.
• The type of the method's parameter determines which event it will consume.
• By default, listeners operate synchronously, blocking the publisher's thread until they complete.
• You can make a listener asynchronous by adding the @Async annotation, allowing the publisher to continue without waiting.

What's Next?

The event system we've just built is incredibly powerful for communication within a single application. However, in modern microservices architecture, your InventoryService and NotificationService might be completely separate applications running independently. Spring's internal events cannot cross these application boundaries.

To solve this, we need a dedicated, external system. In our next lesson, we will explore the role of message brokers (like RabbitMQ or Kafka), which are designed for reliable, asynchronous communication between distributed services.