[Spring MVC] 인터셉터는 어떻게 동작하는가(feat. HandlerExecutionChain, 인터셉터의 예외처리)

 

 

 

 

 

🧐 서론

스프링에서는 인터셉터를 통해, 컨트롤러(핸들러)를 호출하기 전과 후에 추가적인 작업들을 처리할 수 있도록 해줍니다.

예를 들어 인증 정보를 확인하는 등의 작업이 있을 수 있겠네요.

인터셉터에 대해서는 다음 글을 참고해주세요.

 

이번 글에서는 인터셉터가 실제로 어떤 식으로 동작하는지 알아보도록 하겠습니다.

 

 

우선 설명의 편의를 위해 HandlerExecutionChain부터 살펴보도록 하겠습니다.

 

 

 

 

 

🧐 HandlerExecutionChain

HandlerExecutionChain은 위와 같이 핸들러와, 해당 핸들러에 적용될 인터셉터들을 가지고 있는 클래스입니다.

(@Controller에 @RequestMapping으로 정의한 메서드가 하나의 핸들러가 될 수 있습니다.)

 

즉 HandlerExecutionChain을 통해, 인터셉터를 적용하고 핸들러 메서드를 호출할 수 있습니다.

 

 

 

 

 

 

 

 

🧐 DispacherServlet

우선 인터셉터의 대략적인 작동 과정을 확인하기 위해 DispacherServlet 부터 살펴보도록 하겠습니다.

DispatcherServlet.doDispatch()

 

 

우선 http 요청이 들어온다면, 해당 요청에 대응되는 핸들러(컨트롤러)를 찾는 과정을 거칩니다.

 

만약 해당 요청을 처리할 핸들러가 없다면 noHandlerFound()가 호출된 후 그대로 리턴되므로 인터셉터가 호출되지 않습니다.

어? 아닌데요? 호출되는데요?' 

> 해당 인터셉터가 /error에 매핑되거나,
혹은 ResourceHttpRequestHandler 때문일 것입니다.
/error 때문이라면 excludePathPatterns에 /error를 추가하거나,
spring.mvc.throw-exception-if-no-handler-found=true 를 통해 해결할 수 있으며,
ResourceHttpRequestHandler에 대한 내용은 스프링 인터셉터 적용 시 NOT FOUND가 발생하지 않는 경우를 참고해주세요)

 

getHandler()에서 반환되는 핸들러는 HandlerExecutionChain으로, 위에서 살펴보았듯 인터셉터가 포함된 핸들러입니다.

 

이후 mappedHandler.applyPreHandle()이 실행되는데요, 이곳에서 인터셉터의 preHandle()이 수행됩니다.

이후 핸들러 메서드를 호출한 뒤 applyPostHandler()을 통해 인터셉터의 afterHandler()이 호출됩니다.

 

 

 

이어서 살펴보겠습니다.

 

위에서 살펴본 과정들을 진행하며 예외가 발생하거나, 정상적으로 처리되거나에 상관없이, 마지막으로는 processDispatchResult()가 실행되게 됩니다.

 

아래에서 살펴보겠지만, processDispatchResult() 내부에서 인터셉터의 afterCompletion()이 호출됩니다.

 

만약 processDispatchResult()에서 예외가 발생한다면 catch문에 걸린 뒤에 triggerAfterCompletion()메서드가 호출되는데,

이곳에서 인터셉터의 afterCompletion()가 호출되게 됩니다.

 

즉 afterCompletion()은 어떠한 상황에서도 호출되는 것을 알 수 있습니다.

 

 

 

 

그렇다면 의문이 하나 생깁니다.

인터셉터의 afterCompletion()은 요청을 처리할 핸들러가 없어도 실행되나요?
> 아닙니다.

processDispatchResult()와 triggerAfterCompletion()을 보면 핸들러가 있는 경우에만 인터셉터의 afterCompletion()이 호출되도록 구현되어 있습니다.

 

 

간단한 triggerAfterCompletion()부터 살펴보도록 하겠습니다.

DispatcherServlet.triggerAfterCompletion()

 

 

 

processDispatchResult()는 아래와 같이 구현되어 있습니다.

DispatcherServlet.processDispatchResult()

 

processDispatchResult()에서 예외가 발생하면 triggerAfterCompletion()이 호출되는 것을 위에서 살펴보았습니다.

 

그런데 processDispatchResult() 내부에서도 afterCompletion()을 호출하며, triggerAfterCompletion() 내부에서도 afterCompletion() 를 호출합니다.

 

즉 이로인해 processDispatchResult() 내부에서 호출된 인터셉터의 afterCompletion()에서 예외가 발생한다면,

triggerAfterCompletion()에서 인터셉터가 한번 더 호출될까요?

 

이는 아닙니다.

 

이러한 이유는 HandlerExecutionChain의 triggerAfterCompletion() 메서드에 있는데요, 다음과 같이 구현되어 있습니다.

HandlerExecutionChain.triggerAfterCompletion()

 

 

 

지금까지 살펴본 내용들을 바탕으로 알 수 있는 것을 정리하면 다음과 같습니다.

요청을 처리할 수 있는 핸들러(컨트롤러)가 없다면 인터셉터는 작동하지 않습니다.

인터셉터의 preHandle, postHandle에서 예외가 발생한다면, @ControllerAdvice에서 처리할 수 있습니다.

인터셉터의 afterCompletion에서 예외가 발생한다면, @ControllerAdvice등에서 처리할 수 없으며, 단순히 로그만 찍힙니다.

 

 

 

지금까지 인터셉터의 preHandle, postHandle, afterCompletion의 동작 방법을 살펴보았는데요,

이제부터는 어떻게 우리가 등록한 인터셉터가 핸들러에 적용되는지를 살펴보도록 하겠습니다.

 

 

핸들러에 인터셉터를 적용하기 위해서 HandlerExecutionChain을 사용한다는 것을 맨 위에서 살펴보았는데요,

HandlerExecutionChain을 만드는 과정에서 어떠한 방식으로 적용할 인터셉터들이 설정되는지 확인하도록 하겠습니다.

 

HandlerExecutionChain를 생성하는 DispatcherServlet의 getHandler() 메서드를 살펴보도록 하겠습니다.

 

 

 

 

 

 

 

 

 

🧐 getHandler를 통해 HandlerExecutionChain를 만드는 과정

DispatcherServlet.getHandler()

우선 위와 같이 DispatcherServlet이 가진 handlerMappings를 순회하며,

요청(request)에 대응되는 핸들러를 가져오는 과정을 수행합니다.

 

컨트롤러를 @Controller와 @RequestMapping을 사용하여 구현하였다면

여러 handlerMappings 중 RequestMappingHandlerMapping에서 찾을 수 있습니다.

 

 

RequestMappingHandlerMapping은 AbstractHandlerMapping을 상속받아 구현되어있으며, 

AbstractHandlerMapping의 getHandler()는 다음과 같습니다.

AbstractHandlerMapping.getHandler()

 

위처럼, 내부에서 getHandlerExecutionChain() 메서드를 통해 HandlerExecutionChain을 가져오는 것을 알 수 있습니다.

 

 

 

getHandlerExecutionChain 내부에서 저희가 등록한 인터셉터들이 등록되는 것을 알 수 있습니다.

AbstractHandlerMapping.getHandlerExecutionChain()

 

 

 

인터셉터를 등록하는 과정에서 MappedInterceptor의 경우에는 matches()의 결과가 true인 경우에만 등록되도록 구현되어 있습니다.

 

MappedInterceptor는 무엇일까요?

 

 

이에 대해서 알아보기 전에, 우선 위에서 DispatcherServlet에 등록된 adaptedInterceptors를 살펴보겠습니다.

includePatterns 혹은 excludePatterns가 있는 인터셉터는 MappedInterceptor가 되며,

그렇지 않은 인터셉터는 그냥 등록되는 것을 예상할 수 있습니다.

(NoPathInterceptor는 제가 지어준 인터셉터 클래스명입니다)

 

 

 

 

 

 

 

 

 

 

🧐 MappedInterceptor

MappedInterceptor는 다음과 같이 구현되어 있습니다.

 

 

 

 

 

인터셉터를 등록하는 경우에는 인터셉터에 대해서 경로를 지정하여 등록하거나, 혹은 지정하지 않고 등록할 수 있습니다.

@Component
public class Config implements WebMvcConfigurer {

    @Override
    public void addInterceptors(final InterceptorRegistry registry) {
       registry.addInterceptor(new SetPathInterceptor())
               .order(1)
               .addPathPatterns("/**")
               .excludePathPatterns("/error");  // 경로 지정 -> MappedInterceptor
               
        registry.addInterceptor(new NoPathInterceptor())
                .order(2);  // 경로 지정 X -> 등록한 인터셉터 그대로 반환
    }
}

 

 

 

이때 전자의 경우 MappedInterceptor로 포장되어 생성되는데, 생성 과정은 다음과 같습니다.

InterceptorRegistration.getInterceptor()

 

 

 

 

mappedInterceptor의 matches()는 다음과 같이 구현되어 있습니다.

이를 통해 interceptor에 excludePath와 includePath가 동일하게 등록된다면 excludePath가 먼저 동작하는 것도 알 수 있습니다.