Event-driven Model in Spring (Part 2)

These reviews

The previous article covered concepts related to the event-driven model in Spring. The Spring event-driven model is composed of three parts: event, publisher and subscriber. The definition and implementation of these three parts are analyzed based on Spring source code. This article focuses on event-driven Spring with specific examples. When I wrote two articles about the subscription and publishing of events in Spring Cloud Bus, I thought of supplementing the explanation of the event-driven model in Spring, which is also a more basic knowledge point.

Apply the event-driven pattern in Spring

When the configuration server receives the submitted configuration event, it will trigger each service response to update its own configuration. The specific code is as follows:

The event

public class ConfigRefreshEvent extends ApplicationEvent {
    public ConfigRefreshEvent(final String content) {
        super(content); }}Copy the code

Define an event that configures a refresh. Simply inherit ApplicationEvent, and content is the object to be passed.

Defining listeners

Define two services that both implement SmartApplicationListener. This interface is an extension of standard listeners that inherits from ApplicationListener and Ordered interfaces and exposes more metadata, such as supported event types and sortable listeners.

public interface SmartApplicationListener extends ApplicationListener<ApplicationEvent>, Ordered {

	/** * Determines whether the listener supports the given event */
	boolean supportsEventType(Class<? extends ApplicationEvent> eventType);

	/** * determines whether the listener supports the given target type before */ is called
	boolean supportsSourceType(Class
        sourceType);

}
Copy the code

The code for two services is posted below.

ServiceAListener

@Component
public class ServiceAListener implements SmartApplicationListener {

    @Override
    public boolean supportsEventType(final Class<? extends ApplicationEvent> eventType) {
        return eventType == ConfigRefreshEvent.class;
    }

    @Override
    public boolean supportsSourceType(finalClass<? > sourceType) {
        return sourceType == String.class;
    }

    @Override
    public void onApplicationEvent(final ApplicationEvent event) {
        System.out.println("ServiceA receives new configuration:" + event.getSource());
    }

    @Override
    public int getOrder(a) {
        returnOrdered.HIGHEST_PRECEDENCE; }}Copy the code

ServiceBListener

@Component
public class ServiceBListener implements SmartApplicationListener {

    @Override
    public boolean supportsEventType(final Class<? extends ApplicationEvent> eventType) {
        return eventType == ConfigRefreshEvent.class;
    }

    @Override
    public boolean supportsSourceType(finalClass<? > sourceType) {
        return sourceType == String.class;
    }

    @Override
    public void onApplicationEvent(final ApplicationEvent event) {
        System.out.println("ServiceB receives new configuration:" + event.getSource());
    }

    @Override
    public int getOrder(a) {
        returnOrdered.LOWEST_PRECEDENCE; }}Copy the code

The test class

@RunWith(SpringRunner.class)
@SpringBootTest
public class ApplicationTest {
    @Autowired
    private ApplicationContext applicationContext;

    @Test
    public void testPublishEvent(a) {
        System.out.println("Publish configuration update:");
        ConfigRefreshEvent event = new ConfigRefreshEvent("Configuration information has been updated.") applicationContext.publishEvent(event); }}Copy the code

Above is our test class, which acts as an event publisher, first defining an event that is configured to refresh and then publishing that event through the injected ApplicationContext.

Since ServiceA takes precedence over ServiceB, we see the following result:

Issue configuration updates: ServiceA receives a new configuration: the configuration information is updatedCopy the code

conclusion

This article is relatively simple, based on the event driven model in Spring introduced in the previous article, specifically applied to the configuration refresh scenario. Spring’s event-driven model uses the observer pattern. The ApplicationEvent abstract class and the ApplicationListener interface allow events to be defined and listened to, and the ApplicationContext allows events to be published. The SmartApplicationListener used in the example extends the standard Event listener interface. The listener can determine the incoming Event and set the priority of the listener when processing the Event. I’ll write later about the Spring Cloud’s hot update mechanism, which is also based on the event-driven model in Spring.

Subscribe to the latest articles, welcome to follow my official account