DispatcherServlet by 바론

[somsom13]

DispatcherServlet 질문 남겨주세요^^
발표 자료

[Cl8D]

스프링은 서블릿에 대한 생명주기로 관리하나요?
서블릿을 여러 개 구현할 수 있다는 것은 스프링 웹 애플리케이션 내부에서 설정할 수 있는 건가요 ?_?

[somsom13]

1. 스프링이 서블릿을 생명주기로 관리하는건 아닐거예요! 서블릿을 생명주기로 관리하는건 서블릿 컨테이너의 역할이고, 스프링은 서블릿 컨테이너가 아니기 때문에 스프링이 서블릿을 생명주기로 관리하는건 아닐 것 같습니다.
   여담으로 DispatcherServlet은 첫 요청이 들어올 때 initialize되고, 서블릿 컨테이너가 종료될 때 destroy 된다고 합니다.

2. 넵 어플리케이션 내부에 직접 구현한 서블릿을 추가적으로 등록할 수 있습니다. Servlet 인터페이스를 상속받는 클래스를 만들고, (보통은 HttpServlet을 상속받는 Servlet을 만들게 됩니다.) @WebServlet 어노테이션을 달아서 해당 클래스를 서블릿으로 등록하고, url을 설정할 수 있습니다.

서블릿 등록하기 baeldung

서블릿 등록은 오늘 진행된 서블릿&SpringMVC 테코톡을 참고해주세요!^^

[hgo641]

• 리퀘스트를 보내는 클라이언트는 하나의 서블릿과만 연결되나요, 아니면 리퀘스트마다 여러 개의 서블릿과 무작위로 연결되나요?

• 서블릿 컨테이너를 봤을 때는 하나의 프로그램에서 여러개의 서블릿이 구동되는 것 같은데, 프로그램 실행중 디스패처 서블릿 한 번 생성되면 변경되지 않는다고 느꼈는데 틀린 지식이었나요? 아니면 디스패처 서블릿은 싱글톤처럼 하나만 사용되고 나머지 서블릿은 디스패처 서블릿과 다른 일을 한다고 생각하면 되나요? (서블릿 클래스들은 SpringMvc밖에 있으니까??)

• SpringMVC 밖에 있는 서블릿 클래스들은 무슨 일을 하나요? 외부 서버와의 연동을 위해 필요한 클래스인가요? (Redis 라던가?)

• 디스패처 서블릿이 핸들러를 찾는 범위를 제한할 수 있을까요? Configuration을 사용해서 핸들러(또는 그 상위객체)를 빈으로 등록하냐 마느냐로 제한하는 수 밖에 없나요? 핸들러가 등록되어있는데도, 디스패처 서블릿이 탐색하는 걸 제한할 수 있나요? 생각해보니 이딴 기능은 그냥 없는게 낫겠죠?

• HandlerAdapter 내부에 ArgumentResolver, ReturnValueHandler, MessageConverter 들을 가지고 있다.

  DispatcherServlet도 ArgumentResolver들을 초기화하는 걸로 알고있는데 그러면 HandlerAdapter는 DispatcherServlet의 ArgumentResolver들을 그대로 전달 받을 뿐인가요?

• ArgumentResolver는 핸들러 어댑터에서 처리하면서 ViewResolver는 디스패처 서블릿이 직접 처리하는거... 맞나요?

[somsom13]

1. 원래는 "요청 받은 URL에 따라 이 요청을 처리할 수 있는 서블릿과 연결" 됩니다. 다만, 스프링의 경우에는 DispatcherServlet이 "/"로 모든 요청을 다 받기 때문에, DispatcherServlet 하나가 모든 요청을 받는다고 생각하시면 될 것 같습니다.

2. 이건 조금 애매하네요 ㅎㅎ... ㅠㅠ

하나의 프로그램에서 여러개의 서블릿이 구동

하나의 어플리케이션에서 여러 개의 서블릿들을 구동할 수 있는 건 맞습니다!

프로그램 실행중 디스패처 서블릿 한 번 생성되면 변경되지 않는다

이 내용은 맞습니다!

Spring MVC 밖의 서블릿들은 동작할 수 있고, 각각 자신만의 역할을 가집니다. (DefaultServlet의 정적 자원 처리, JSP Servlet의 JSP 처리 등)
하지만, 스프링에서는 DispatcherServlet이 요청을 다 받기 때문에 다른 서블릿들이 사실상 하는 일이 없는 것으로 알고 있습니다. (DispatcherServlet이 정적 자원까지 모두 처리하고 (by. ResourceHttpRequestHandler), JSP의 경우에는 테스트해보지 않아서 잘 모르겠습니다.. 하하)

3. SpringMVC 밖에 있는 서블릿들은 Tomcat에 의해 기본적으로 제공되는 서블릿들입니다.
   제가 알고 있는 선에서는 외부 서버와의 연동을 담당하는 서블릿이 있는지는 잘 모르겠지만.. ㅎ.ㅎ
   보통은 JSP 파일을 컴파일, 실행하는 JspServlet 과 정적 자원을 처리하는 핸들러 역할을 하는 DefaultServlet 등의 서블릿들이 있는 것으로 알고있습니다.

4. 찾는 범위를 제한하는 방법은 없는 것으로 알고 있습니다. Component로 등록된 controller는 모두 handler로 등록되기 때문에, 핸들러의 등록 자체를 제한하는 방법은

• Component로 인식되지 않게 어노테이션을 달지 않는다.
• DispatcherServlet이 찾는 URL 범위를 변경한다. (현재의 / 에서 /test 하의 요청들만 처리하도록 변경하는 등)
  뿐 인 것 같습니다!

5. ArgumentResolver를 초기화하는 역할은 명시적으로는 DispatcherServlet이 하지 않습니다.
   DispatcherServlet의 initHandlerAdapters는 handlerAdapter들을 모두 조회해 옵니다. 이 때, 조회해온 HandlerAdapter 내에 각각 ArgumentResolver들이 이미 모두 세팅되어 있습니다.
   

따라서, DispatcherServlet이 handlerAdapter를 초기화 할 때 이미 HandlerAdapter들 내부에 ArgumentResolver들이 초기화 되어있으며,
argumentResolver들의 초기화는 HandlerAdapter 내의 getDefaultArgumentResolvers 메서드에서 실행됩니다.

6. 넵 맞습니다! ArgumentResolver를 통한 resolving은 handlerAdapter의 흐름 내에서 이루어지고, ViewResolver의 view 처리는 ha.handle 후 반환되는 ModelAndView에 따라서 DispatcherServlet이 처리합니다.

[Cl8D]

^_^ 안녕하세요 바론 질문을 더 하고 싶어서 가져왔어요~

• 서블릿 컨테이너가 멀티스레드를 통해 다중 요청 처리를 지원한다고 말씀하셨는데, 하단 글을 읽어보면 서블릿 컨테이너가 스레드 풀을 관리하는 것처럼 보이네요. 그럼 스레드 풀이 여기에서 관리되고 스레드 생성까지 서블릿 컨테이너의 책임인 걸까요?_?
• 톰캣 서블릿이 제공하는 에러 핸들링 서블릿이 저희가 처리하지 않은 500 에러에서 나오는 white label page인가요?
  => 맞다면, white label page에 대한 커스텀이 가능한가요?
• 핸들러 어댑터는 단순히 핸들러에게 요청이 가기 전에 다양한 기능을 처리하기 위해서 만들어진 것일까요? 핸들러 어댑터는 어떤 식으로 핸들러를 찾는지 궁금합니당 (애초부터 1:1 매칭인가요? - 디스패처가 기본적으로 4개의 핸들러 어댑터를 가지고 있다는데, 그렇다면 어떤 식으로 매칭되나요?)

[somsom13]

질문 STOP

[somsom13]

1. 넵 그런 걸로 알고 있습니다. 스프링에서 사용하는 서블릿 컨테이너인 Tomcat이 부팅될 때 스레드 풀을 생성하고, 요청이 올 때 요청을 처리할 스레드를 풀에서 꺼내 쓰는 작업이 서블릿 컨테이너 내부에서 이루어집니다.
   스레드 풀 설정은 application.properties (yml) 파일에서 바꿀 수 있다고 합니다!

2. 져니의 질문을 받고 후다닥 찾아본 결과..^^ WhiteLabelPage는 Spring Boot가 제공해주는 디폴트 에러 페이지라고 합니다. ErrorMvcAutoConfiguration 클래스 내에 있는 WhitelabelErrorViewConfiguration 에서 관리됩니다.
   

이 StaticView 클래스 내부를 보면

위와 같이 WhiteLabelPage가 정의되어 있습니다.

기본 에러 페이지를 커스텀하기 위해서는 (즉 WhiteLabelPage 대신 커스텀 에러 페이지를 사용하려면)

• 에러 html 페이지 생성
• 해당 에러 페이지를 반환하는 controller 생성 (ex. URI = /error)
• property 파일에 server.error.path=/error (앞에서 구현한 해당 URI 지정)
  의 과정을 거쳐야 한다고 합니다. (출처: baeldung)
  그리고 스프링 부트의 예외는 톰캣이 제공하는 에러 핸들링 서블릿이 아닌, ExceptionResolver에 의해서 처리가 됩니다.

3. 핸들러 어댑터는 공통 기능을 처리하기 위해서라기 보다는, 다양한 형태로 구현된 handler들에게 공통적으로 Request를 넘겨주기 위해서 존재합니다.
   우선은 기본적으로, DispatcherServlet 내의 getHandlerAdapter 메서드에서 4개의 어댑터들을 모두 순환하면서 "이 adpater가 이 handler를 지원하는가?"를 확인하고, 가장 첫 번째로 찾은 adapter를 요청을 처리할 adapter로 선정합니다.

지원여부를 결정하는 supports 메서드의 설명은 다음과 같습니다.

Given a handler instance, return whether this HandlerAdapter can support it. Typical HandlerAdapters will base the decision on the handler type. HandlerAdapters will usually only support one handler type each.

즉, 말씀해주신대로 하나의 어댑터 - 하나의 핸들러 1:1 매칭으로 생각하면 될 것 같습니다.