Publishing Custom Application Events

1. From Direct Calls to Decoupled Events

Imagine a UserService that handles new user registrations. After a user is registered, the system needs to perform several follow-up actions:

• Send a welcome email.
• Assign a default user role.
• Log an audit trail.

If the UserService directly calls an EmailService, RoleService, and AuditService, it becomes tightly coupled to them. Any change in those services might require modifying the UserService. What if we later need to add another action, like adding the user to a marketing list? We'd have to change the UserService again. This violates the Open/Closed Principle of SOLID design.

Spring Events offer a solution based on the Observer design pattern.

• The UserService (the publisher) simply announces, "A user has registered!" by publishing an event.
• Other services (the listeners) that care about this event can subscribe to it and react accordingly.

The UserService doesn't know or care who is listening. This decoupling makes the system more modular, extensible, and easier to maintain.

To see this concept explained with a real-world example, let's watch a short segment from a video by Java Techie.

2. The Three Components of Spring Events

The Spring event mechanism consists of three main parts, as illustrated below. Today, we'll focus on the first two: the Event and the Publisher.

3. Step 1: Defining a Custom Event

An event is simply a message that signals something has happened. In Spring, this message is an object. This object's primary role is to carry relevant data about what occurred.

For modern Spring applications (version 4.2 and later), an event can be any Plain Old Java Object (POJO).

Here is what a UserRegisteredEvent might look like. It's a simple class that holds the necessary data—in this case, the user's email.

// A simple POJO to represent our event
public class UserRegisteredEvent {
    private final String email;

    public UserRegisteredEvent(String email) {
        this.email = email;
    }

    public String getEmail() {
        return email;
    }
}

A Note on Older Spring Versions:
In older codebases or tutorials (using Spring versions before 4.2), you will often see event classes extending ApplicationEvent. While this still works, it's no longer required. The modern approach of using simple POJOs is cleaner and more flexible. The Baeldung article "Spring Events" (Resource ID: LINK, section 2.1) shows this older style if you are curious.

4. Step 2: Publishing an Event

Once we have our event class, we need a way to publish it. Spring provides the ApplicationEventPublisher interface for this purpose. It's a bean that's automatically available in the application context, so you can inject it into any other bean (like a service) that needs to publish events.

The process is straightforward:

1. Inject ApplicationEventPublisher into your service. Constructor injection is the recommended approach.
2. In the method where the event occurs (e.g., registerUser), create an instance of your custom event object.
3. Call the publishEvent() method on the publisher, passing your event object.

Let's see this in practice.

Applying this to our UserService example from earlier, the implementation would look like this:

import org.springframework.context.ApplicationEventPublisher;
import org.springframework.stereotype.Service;

@Service
public class UserService {

    private final ApplicationEventPublisher eventPublisher;

    // 1. Inject the publisher via the constructor
    public UserService(ApplicationEventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }

    public void registerUser(String email, String password) {
        // ... logic to save the user to the database ...
        System.out.println("User registered: " + email);

        // 2. Create the event object
        UserRegisteredEvent event = new UserRegisteredEvent(email);

        // 3. Publish the event
        System.out.println("Publishing UserRegisteredEvent...");
        eventPublisher.publishEvent(event);
        
        System.out.println("User registration method finished.");
    }
}

By default, the publishEvent() call is synchronous. This means the registerUser method will block and wait until all listeners have finished processing the event before it continues. We'll learn how to make listeners asynchronous in a future lesson.

To see a live-coding demonstration of event publishing, let's return to the Java Techie video.

Conclusion

Great work today! You've learned a fundamental pattern for building decoupled, modular Spring applications. By using events, you can create components that react to changes in the system without being tightly bound to the source of the change.

Key Takeaways:

• Spring Events help decouple application components, following the Observer design pattern.
• An event is an object (typically a simple POJO) that carries data about something that happened.
• You can publish an event from any Spring bean by injecting the ApplicationEventPublisher and calling its publishEvent() method.
• By default, event publication is a synchronous, blocking operation.

What's Next?

We've successfully published an event, but right now, nothing is happening in response because we haven't created any listeners. In our next lesson, we will complete the picture by learning how to create listeners to consume application events using the @EventListener annotation. You'll see just how easy it is to subscribe to the events we've just learned to publish.