[Spring] DispatcherServlet의 동작 과정과 HanderMapping, HandlerAdapter, @RequestMapping

- 김영한 님의 '스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술'을 보고 정리한 글입니다 😊

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의

---

- 지난 포스팅과 이어집니다 :D

[Spring] MVC 패턴이란, V1~V5로 MVC 프레임워크 만들기

- 지난 강의에서 MVC 패턴을 익히기 위해 V1~V5까지 점진시켜나가며 구조를 이해했다.

- 이번 포스팅에서는 스프링에서 이러한 MVC 패턴을 어떻게 제공해주고 있는지 알아보자.

 

 

| Spring MVC

- SpringMVC 구조에 대해서 알아보자.

우리가 지금까지 구현하였던 'FrontController'는 스프링MVC에서 'DispatcherServlet'으로 구현되어 있다.

DispatcherServlet은 HttpServlet을 상속받아서 사용하며, 서블릿으로 동작한다.

정확하게는 DispatcherServlet -> FrameworkServlet -> HttpServletBean -> HttpServlet -> FrameworkServlet 이렇게.

 

스프링 부트 DispatcherServlet을 자동으로 등록하며, 모든 경로에 대해서 매핑한다!

단, 구체적인 것보다 상세한 게 늘 먼저 동작하기 때문에 기존에 등록한 서블릿도 함께 동작한다.

 

스프링 MVC는 FrameworkServlet의 service()의 오버라이딩하였으며, 이를 시작으로 해서 DispatcherServlet의 doDispatch()를 호출한다.

🚩 DispatcherServlet 역시 서블릿이기 때문에, 마찬가지로 init(), doPost, doGet, service 같은 메서드가 존재한다.

부모인 FrameworkServlet의 doGet(), doPost()가 request, response를 processRequest를 통해 넘겨주며,

해당 함수에서 doService()를 호출한다. 그리고 doService는 결국 doDispatch()를 호출한다!

 

[DispatcherServlet - doDispatch()]

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
    HttpServletRequest processedRequest = request;
    HandlerExecutionChain mappedHandler = null;
    boolean multipartRequestParsed = false;

    WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);

    try {
        ModelAndView mv = null;
        Exception dispatchException = null;

        try {
            processedRequest = checkMultipart(request);
            multipartRequestParsed = (processedRequest != request);

            // ####### 1 ########
            // Determine handler for the current request.
            mappedHandler = getHandler(processedRequest);
            if (mappedHandler == null) {
                noHandlerFound(processedRequest, response);
                return;
            }

            // ####### 2 ########
            // Determine handler adapter for the current request.
            HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

            // ####### 3 ########
            // Process last-modified header, if supported by the handler.
            String method = request.getMethod();
            boolean isGet = HttpMethod.GET.matches(method);
            if (isGet || HttpMethod.HEAD.matches(method)) {
                long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
                if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
                    return;
                }
            }

            if (!mappedHandler.applyPreHandle(processedRequest, response)) {
                return;
            }

            // ####### 4 ########
            // Actually invoke the handler.
            mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

            if (asyncManager.isConcurrentHandlingStarted()) {
                return;
            }

            applyDefaultViewName(processedRequest, mv);
            mappedHandler.applyPostHandle(processedRequest, response, mv);
        }
        catch (Exception ex) {
            dispatchException = ex;
        }
        catch (Throwable err) {
            // As of 4.3, we're processing Errors thrown from handler methods as well,
            // making them available for @ExceptionHandler methods and other scenarios.
            dispatchException = new NestedServletException("Handler dispatch failed", err);
        }

        // ####### 5 ########
        processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
    }
    catch (Exception ex) {
        triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
    }
    catch (Throwable err) {
        triggerAfterCompletion(processedRequest, response, mappedHandler,
                new NestedServletException("Handler processing failed", err));
    }
    finally {
        if (asyncManager.isConcurrentHandlingStarted()) {
            // Instead of postHandle and afterCompletion
            if (mappedHandler != null) {
                mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
            }
        }
        else {
            // Clean up any resources used by a multipart request.
            if (multipartRequestParsed) {
                cleanupMultipart(processedRequest);
            }
        }
    }
}

 - 내부의 메서드를 살펴보자.

 

 

🎈 #### 1번 ####

// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
        if (mappedHandler == null) {
            noHandlerFound(processedRequest, response);
            return;
        }

현재의 요청(request)에 대한 핸들러를 결정하는 부분이다.

만약 핸들러를 찾지 못하면 noHandlerFound를 호출하는데, 내부에 response.sendError(HttpServletResponse.SC_NOT_FOUND);가 있다.

@Nullable
protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
    if (this.handlerMappings != null) {
        for (HandlerMapping mapping : this.handlerMappings) {
            HandlerExecutionChain handler = mapping.getHandler(request);
            if (handler != null) {
                return handler;
            }
        }
    }
    return null;
}

getHandler의 경우 다음과 같이 생겼다. 

여기서 HandlerExecutionChain이라는 걸 볼 수 있는데, 이는 핸들러 객체와 핸들러 인터셉터로 구성된 일종의 체인이라고 한다.

this.handlerMappings라고 되어 있는데, DispatcherServlet이 내부에서 초기화 시 등록한 여러 handlerMapping의 리스트이다.

각 리스트의 요소에 대해서 getHandler를 통해 (이는 핸들러 객체를 리턴해주는 함수이다) 요청에 맞는 handler를 리턴해준다.

 

 

🎈 #### 2번 ####

- 자, 이렇게 핸들러를 찾았으니 이제 핸들러 어댑터를 찾아야 한다.

// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
    if (this.handlerAdapters != null) {
        for (HandlerAdapter adapter : this.handlerAdapters) {
            if (adapter.supports(handler)) {
                return adapter;
            }
        }
    }
    throw new ServletException("No adapter for handler [" + handler +
            "]: The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler");
}

다음과 같이 파라미터로 핸들러를 넘겨준 다음에, 해당 핸들러를 처리할 수 있는지를 support함수로 판단한다!

마찬가지로 처리할 수 없다면 Exception을 터트려준다.

 

 

🎈 #### 3번 ####

// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = HttpMethod.GET.matches(method);
if (isGet || HttpMethod.HEAD.matches(method)) {
    long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
    if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
        return;
    }
}

if (!mappedHandler.applyPreHandle(processedRequest, response)) {
    return;
}

그리고, 이제 applyPreHandle을 통해서 인터셉터를 실행해준다고 보면 된다.

아까, mappedHandler = getHandler()를 실행했을 때 HandlerExecutionChain이 반환된 건 바로 이 이유 때문이다.

-> 인터셉터 처리를 위해!

여기서 preHandle을 사용하였는데, 이는 핸들러가 실행되기 전에 가로채서 어떠한 조건에 맞는지 체크하는 역할을 주로 실행한다.

boolean applyPreHandle(HttpServletRequest request, HttpServletResponse response) throws Exception {
    for (int i = 0; i < this.interceptorList.size(); i++) {
        HandlerInterceptor interceptor = this.interceptorList.get(i);
        if (!interceptor.preHandle(request, response, this.handler)) {
            triggerAfterCompletion(request, response, null);
            return false;
        }
        this.interceptorIndex = i;
    }
    return true;
}

- 반환값이 true면 다음으로, false면 return 시켜버린다.

 

🎈 #### 4번 ####

// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

if (asyncManager.isConcurrentHandlingStarted()) {
    return;
}

applyDefaultViewName(processedRequest, mv);
mappedHandler.applyPostHandle(processedRequest, response, mv);

- 그리고, 이제 실제로 호출을 진행해준다!

- 앞에서 찾은 핸들러 어댑터(ha)의 handle() 메서드를 실행하여 ModelAndView 객체를 반환받는다.

- 보통의 HandlerAdapter는 인터페이스로 정의되어 있기 때문에, 핸들러에 맞는 구현체가 실행된다고 볼 수 있다.

void applyPostHandle(HttpServletRequest request, HttpServletResponse response, @Nullable ModelAndView mv)
        throws Exception {

    for (int i = this.interceptorList.size() - 1; i >= 0; i--) {
        HandlerInterceptor interceptor = this.interceptorList.get(i);
        interceptor.postHandle(request, response, this.handler, mv);
    }
}

- 이후 수행이 끝나면 인터셉터로 applyPostHandle을 호출하는데, 이는 로직이 종료 후 실행되는 메서드라고 볼 수 있다.

 

 

🎈 #### 5번 ####

processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);

- 다음으로 processDispatchResult를 호출한다.

private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
                                   @Nullable HandlerExecutionChain mappedHandler, @Nullable ModelAndView mv,
                                   @Nullable Exception exception) throws Exception {

    boolean errorView = false;

    if (exception != null) {
        if (exception instanceof ModelAndViewDefiningException) {
            logger.debug("ModelAndViewDefiningException encountered", exception);
            mv = ((ModelAndViewDefiningException) exception).getModelAndView();
        }
        else {
            Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
            mv = processHandlerException(request, response, handler, exception);
            errorView = (mv != null);
        }
    }

    // Did the handler return a view to render?
    if (mv != null && !mv.wasCleared()) {
        // ####### 6 ########
        render(mv, request, response);
        if (errorView) {
            WebUtils.clearErrorRequestAttributes(request);
        }
    }
    else {
        if (logger.isTraceEnabled()) {
            logger.trace("No view rendering, null ModelAndView returned.");
        }
    }

    if (WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {
        // Concurrent handling started during a forward
        return;
    }

    if (mappedHandler != null) {
        // Exception (if any) is already handled..
        mappedHandler.triggerAfterCompletion(request, response, null);
    }
}

여기서 잘 보면 render()를 호출하는 걸 볼 수 있다.

 

 

🎈 #### 6번 ####

protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception {
    // Determine locale for request and apply it to the response.
    Locale locale =
            (this.localeResolver != null ? this.localeResolver.resolveLocale(request) : request.getLocale());
    response.setLocale(locale);

    View view;
    String viewName = mv.getViewName();
    if (viewName != null) {
        // We need to resolve the view name.
        view = resolveViewName(viewName, mv.getModelInternal(), locale, request);
        if (view == null) {
            throw new ServletException("Could not resolve view with name '" + mv.getViewName() +
                    "' in servlet with name '" + getServletName() + "'");
        }
    }
    else {
        // No need to lookup: the ModelAndView object contains the actual View object.
        view = mv.getView();
        if (view == null) {
            throw new ServletException("ModelAndView [" + mv + "] neither contains a view name nor a " +
                    "View object in servlet with name '" + getServletName() + "'");
        }
    }

    // Delegate to the View object for rendering.
    if (logger.isTraceEnabled()) {
        logger.trace("Rendering view [" + view + "] ");
    }
    try {
        if (mv.getStatus() != null) {
            request.setAttribute(View.RESPONSE_STATUS_ATTRIBUTE, mv.getStatus());
            response.setStatus(mv.getStatus().value());
        }
        view.render(mv.getModelInternal(), request, response);
    }
    catch (Exception ex) {
        if (logger.isDebugEnabled()) {
            logger.debug("Error rendering view [" + view + "]", ex);
        }
        throw ex;
    }
}

그리고, 내부에서는 resolveViewName()를 호출하여 view의 논리 이름을 물리 이름으로 변환해준다. (실제 뷰 찾기)

최종적으로 렌더링을 하기 위해서 view.render()를 통해서 실제로 뷰에 렌더링을 진행한다!   

view에 ModelAndView.getModelInternal()을 활용해 model의 데이터를 view에 렌더링을 해주는 것이다.

 

 

이렇게 DispatcherServlet의 전반적인 구조에 대해서 알아보았다.

스프링 MVC는 이런 DispatcherServlet 코드의 변경 없이 원하는 기능을 변경하거나 확장할 수 있도록 제공한다.   

-> 핸들러 매핑 (HandlerMapping) / 핸들러 어댑터 (HandlerAdapter) / 뷰 리졸버 (ViewResolver) / 뷰 (View)   

이러한 인터페이스를 구현해서 디스패처 서블릿에 등록만 해주면 된다.

하지만, 직접 만들 일은 거의 없다. 왜냐면 웬만한 거는 다 있기 때문...!

 

---

 

| HandlerMapping / HandlerAdapter / ViewResolver

- 핸들러 매핑과 핸들러 어뎁터는 어떻게 사용이 될까?

- 기본적으로 Controller를 호출하기 위해서는 2가지가 필요하다.

 

 

✔ HandlerMapping (핸들러 매핑)

- 스프링 빈의 이름으로 핸들러를 찾을 수 있는 핸들러 매핑이 필요하다.

ex) ⭐RequestMappingHandlerMapping : @RequestMapping에서 사용

BeanNameUrlHandlerMapping: 스프링 빈의 이름으로 핸들러 찾음

 

 

✔ HandlerAdapter (핸들러 어댑터)

- 핸들러 매핑을 통해 찾은 핸들러를 실행할 어댑터가 필요하다.

ex) ⭐RequestMappingHandlerAdapter : @RequestMapping에서 사용

HttpRequestHandlerAdapter : HttpRequestHandler 처리

SimpleControllerHandlerAdapter : Controller 인터페이스에서 사용 (@Controller 아님)

 

- 모두 RequestMappingHandlerMapping, RequestMappingHandlerAdapter가 우선순위가 높다.

🚩 [RequestMappingHandlerMapping.java]

@Override
protected boolean isHandler(Class<?> beanType) {
        return (AnnotatedElementUtils.hasAnnotation(beanType, Controller.class) ||
        AnnotatedElementUtils.hasAnnotation(beanType, RequestMapping.class));
        }

- 코드를 보면 이런 식으로 어노테이션의 클래스를 따지는 부분이 있다!

 

🚩 핸들러 매핑으로 핸들러 조회 -> 핸들러 어댑터 조회 -> 핸들러 어댑터 실행

 

 

✔ ViewResolver (뷰 리졸버)

- 스프링 부트는 InternalResourceViewResolver라는 뷰 리졸버를 자동으로 등록하는데, 

이때 application.yml (프로퍼티)에 등록한 spring.mvc.view.prefix / suffix 설정 정보를 사용해서 등록한다.

(보통 prefix에 /WEB-INF/views/를, suffix에 .jsp를 두어서 jsp를 사용하는 편이다)

ex) BeanNameViewResolver : 빈 이름으로 뷰를 찾아서 반환한다

InternalResourceViewResolver : JSP를 처리할 수 있는 뷰를 반환한다.

 

🚩 핸들러 어댑터로 논리 뷰 이름 획득 -> 뷰 리졸버 호출 -> 반환된 뷰의 render() 호출

- 여기서 JSP의 경우 (InternalResourceViewResolver) forward()를 통해서 JSP를 실행 후 렌더링이 진행된다.

   - 나머지의 경우 forward 필요 없이 바로 렌더링이 된다.

- 추가적으로, JSTL 라이브러리가 있으면 JstlView를 반환하며, 약간의 부가 기능을 조금 더 가지고 있다.

- 타임리프 사용 시 ThymeleafViewResolver를 스프링 부트가 자동으로 등록해준다.

 

---

| Spring MVC

- 스프링이 제공하는 컨트롤러는 어노테이션을 기반으로 동작한다!

✔ @RequestMapping

- 핸들러 매핑으로 RequestMappingHandlerMapping, 핸들러 어댑터로 RequestMappingHandlerAdapter를 사용한다.

- 지난 포스팅에 사용하였던 예제들을 SpringMVC에서 제공하는 방식들로 변경해보자.

 

[application.properties]

spring.mvc.view.prefix=/WEB-INF/views/
spring.mvc.view.suffix=.jsp

[MemberFormController.java] 

@Controller
public class SpringMemberFormController {

    @RequestMapping("/springmvc/v1/members/new-form")
    public ModelAndView process() {
        return new ModelAndView("new-form");
    }
}

- @Controller를 통해 자동으로 스프링 빈으로 등록을 해주었다. 

- @RequestMapping을 통해 해당 URI로 들어온 요청을 해당 메서드가 처리할 수 있도록 한다. 

- Model과 View 정보를 담은 ModelAndView를 반환한다.

 

🚩 RequestMappingHandlerMapping은 스프링 빈 중에서 @RequestMapping과 @Controller가 클래스 레벨에 붙어 있는 경우 매핑 정보로 인식한다. 그렇기 때문에, @Controller 대신에 @Component과 @RequestMapping을 클래스 레벨에 붙여줘도 된다!

- 혹은, 스프링 빈으로 직접 등록해도 된다 (@Bean 이용) - 하지만... 귀찮으니까.

 

[SpringMemberSaveController.java]

@Controller
public class SpringMemberSaveController {
    private final SMemberRepository repository
            = SMemberRepository.getRepository();

    @RequestMapping("/springmvc/v1/members/save")
    public ModelAndView process(HttpServletRequest req, HttpServletResponse resp) {
        String username = req.getParameter("username");
        int age = Integer.parseInt(req.getParameter("age"));

        SMember member = new SMember(username, age);
        repository.save(member);

        ModelAndView mv = new ModelAndView("save-result");
        mv.addObject("member", member);
        return mv;
    }
}

- model에 데이터를 추가할 때는 ModelAndView의 addObject를 사용해주면 된다!

 

[SpringMemberListController.java]

@Controller
public class SpringMemberListController {
    private final SMemberRepository repository
            = SMemberRepository.getRepository();

    @RequestMapping("/springmvc/v1/members")
    public ModelAndView process() {
        List<SMember> members = repository.findAll();
        ModelAndView mv = new ModelAndView("members");
        mv.addObject("members", members);
        return mv;
    }
}

- 마찬가지로 실행해보면 매우 잘 동작하는 것을 확인할 수 있다.

 

- 그러나, 이런 식으로 파일이 많이 존재하는 건 상당히 불편하다.

- 하나의 파일에다가 옮겨보자.

 

[SpringMemberController.java]

@Controller
@RequestMapping("/springmvc/v2/members")
public class SpringMemberController {
    private final SMemberRepository repository
            = SMemberRepository.getRepository();

    @RequestMapping("/new-form")
    public ModelAndView newForm() {
        return new ModelAndView("new-form");
    }

    @RequestMapping("/save")
    public ModelAndView save(HttpServletRequest req, HttpServletResponse resp) {
        String username = req.getParameter("username");
        int age = Integer.parseInt(req.getParameter("age"));

        SMember member = new SMember(username, age);
        repository.save(member);

        ModelAndView mv = new ModelAndView("save-result");
        mv.addObject("member", member);
        return mv;
    }

    @RequestMapping()
    public ModelAndView members() {
        List<SMember> members = repository.findAll();
        ModelAndView mv = new ModelAndView("members");
        mv.addObject("members", members);
        return mv;
    }

}

- 이런 식으로 하나의 파일에다가 줄일 수 있다. 특히, 중복되는 경로는 클래스 단위에, 세부 경로는 메서드 단위에 달아주면 된다 :D

 

- 그러나, 이 코드는 또 다시 ModelAndView를 개발자가 직접 작성해줘야 한다는 단점이 있다.

- 이를 더 줄여보자!

 

[SpringMemberController.java] - 수정

@Controller
@RequestMapping("/springmvc/v3/members")
public class SpringMemberController extends RequestMappingHandlerMapping {
    private final SMemberRepository repository
            = SMemberRepository.getRepository();

    @GetMapping("/new-form")
    public String newForm() {
        return "new-form";
    }

    @PostMapping("/save")
    public String save(@RequestParam("username") String username,
                       @RequestParam("age") int age,
                       Model model) {
        SMember member = new SMember(username, age);
        repository.save(member);
        model.addAttribute("member", member);
        return "save-result";
    }

    @GetMapping
    public String members(Model model) {
        List<SMember> members = repository.findAll();
        model.addAttribute("members", members);
        return "members";
    }

}

Model을 파라미터로 받고, 뷰의 논리 이름을 반환한다.

또한, 요청 파라미터를 @RequestParam으로 받을 수 있는데, @RequestParam("username") = HttpServletRequest.getParameter("username")이라고 생각하면 된다.

 

추가적으로, 메서드 단위에서 단순히 @RequestMapping을 사용하지 않고 @PostMapping / @GetMapping을 사용하였다.

기존의 requestMapping(method="")의 method를 통해 Http Method를 구분지을 수 있었지만, 더 편리하게 어노테이션으로 분리 가능하다. @GetMapping의 경우 Http Method가 Get이면서 해당 URI을 가지는 요청을 받는다.

 

 

여러 가지 레퍼런스 보다가 갑자기 생각나서 적는 거...

🎈 HTTP API vs REST API

- Http API는 HTTP를 사용하여 정해둔 스펙을 통해 데이터를 주고 받으며 통신하는 것.

- REST는 여기에 4가지의 제약 조건을 추가한 것.

 

1) 자원의 식별

- 요청 내에 기술된 자원을 식별할 수 있어야 하며, URI을 사용하는 것이 그 예시이다.

- 서버는 DB의 자료를 HTML, JSON 같은 형식으로 전송한다.

 

2) 메시지를 통한 리소스 조작

- 클라이언트가 자원을 지칭하는 메시지와 메타데이터만 있으면 서버 상의 자원을 변경 및 삭제할 수 있다.

 

3) 자기서술적 메시지

- 각 메시지는 어떻게 처리해야 하는지에 대한 정보를 포함해야 한다.

인터넷 미디어 타입이라면 어떠한 파서를 써야 하는지에 대한 정보도 들어가야 한다.

 

4) 애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

- 클라이언트가 리소스에 접근하고 싶다면, 리턴되는 지시자에서 구별할 수 있어야 한다.

- HTML 같은 파이퍼링크가 추가되어, 다음에 어떤 API를 호출해야 하는지 링크를 통해 받을 수 있어야 한다는 점.

 

- 이러한 4가지 제약 조건을 다 지킨 게 RESTful API지만, 실무에서는 이렇게 다 만족하기 어렵다.

- 그래서 요즘은 대부분 HTTP API를 그냥 Restful API와 동일하게 생각한다고 한다...!

 

- 아무튼, 다음 포스팅에서는 본격적으로 스프링 MVC에서 제공하는 다양한 어노테이션과 HTTP 요청, 응답 메시지에 대해 알아보자.