Spring은 Event를 어떻게 구현했을까?

현재 진행중인 프로젝트에서 특정 비즈니스 로직들(알림 등)로 인해 핵심 비즈니스 로직의 처리가 제대로 이루어 지지 않거나 코드의 가독성이 떨어지는 상황이 발생했다.

이런 문제들을 해결 하기 위해 리서치를 진행하여 @TransactionEventlistener라는 기술을 알게 되었고, 이를 이용하여 부가 비즈니스 로직들로 인한 문제가 핵심 비즈니스 로직을 방해하지 않도록 조치할 수 있었다.

그러나, '기술에 대한 히스토리를 알지 못한 상태로 도입했다.'라는 생각이 들어 오늘은 Spring에서 제공하는 Event 처리 방식에 대해 기본부터 알아보고자 한다.

EventListener

Spring에서 Event를 처리하기 위해 사용되는 가장 대표적인 요소는 @EventListener 어노테이션이다.

@EventListener 는 “메서드를 애플리케이션 이벤트의 리스너로 표시하는 어노테이션이다.”라고 Java Docs에 기재되어있는데 처음부터 해석이 쉽지 않다. (Annotation that marks a method as a listener for application events)

 

 

애플리케이션 이벤트가 뭔데?

개인적으로 '애플리케이션 이벤트'를 간단 명료하게 “애플리케이션에서 발생하는 특정 사건”이라고 정의하고자 한다.

Spring에서는 이러한 “특정 사건”을 사용자가 구현하기 위해 ApplicationEvent 라는 추상클래스를 제공하고 있으며, Spring 4.2 이후로는 ApplicationEvent를 상속 받지 않고 POJO 만으로 쉽게 구현할 수 있도록 추가적인 기능을 제공하게 되었다고 한다.

 

그럼 리스너는?

리스너는 특정 사건이 발생하면 특정 동작을 수행하는 컴포넌트 역할을 한다. 이를 통해 @EventListener는 “애플리케이션에서 발생하는 특정한 사건 이후 특정한 비즈니스가 처리될 수 있도록 만드는 요소이다.”와 같은 나만의 정의를 내릴 수 있었다.

 

그럼 이제 누가 진짜 애플리케이션 이벤트 리스너를 등록하는지 알아보자.

 

 

EventListenerMethodProcessor

Docs 에 의하면 EventListenerMethodProcessor는 “EventListener를 개별 ApplicaitionListener 인스턴스로 등록하는 역할”을 한다고 한다.(Registers EventListener methods as individual ApplicationListener instances.)

ApplicaitonListener 라는 알아야 할 또 다른 무언가가 생겨버렸다. 매번 느끼지만 Docs를 통해 코드를 따라가다보면 '정글을 탐험하는 느낌이 이렇지 않을까?' 라는 생각이 든다.

 

 

ApplicaitonListener

Docs에 의하면 ApplicationListener는 “애플리케이션 이벤트 리스너가 구현할 인터페이스”라고 한다. 코드를 보면 제네릭을 통해 구현체는 ApplicationEvent를 상속하는 클래스로 제한하고 있다. 여기서 재미있는 점은 옵저버 패턴을 위해 Java에서 1996년부터 제공하는 표준 EventListener 인터페이스를 상속하고 있는 부분이다. 뭐랄까 실제 뼈대가 등장한 느낌?

 

 

 

마무리

여기서 끊는 것은 "절단신공이 너무나 화려하다."라고 판단 되지만 오늘은 여기까지 알아보려 한다. 다음 글에서는 실제 뼈대라 판단되는 표준 EventListener 인터페이스와 Spring에서 옵저버 패턴을 어떻게 구현하는지에 대한 알아보자.