일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- spring6
- kakao
- docker
- mongo
- spring-web
- spring caching
- 값객체
- 바운디드컨텍스트
- springboot
- MongoDB
- Spring
- Pay
- 애그리거트
- IDDD
- ifkakao
- Kotlin
- springboot3
- 신입
- ddd
- 개발자
- java17
- Conference
- spring scheduler
- Redis
- webframework
- zuul
- MSA
- armeria
- 반버논
- springcloud
- Today
- Total
Easy Understanding
스프링 Web Servlet 문서 읽고 정리하기 본문
1. 서블릿이 무엇인가
우선 예전에는 몰랐던 Servlet의 의미를 다시 한 번 정리해보려고 한다.
대부분의 설명에서는 자바 웹서버 '프로그램'이라고 하는데,
'아 그래서 프로그램이 정확하게 뭘 말하는 건데 ㅡㅡ' 라는 생각으로 좀 찾아보았다.
정확하게 말하면 Servlet은 Java의 스펙이다.
JPA도 단순 명세이고 이것을 구현한 것이 Hibernate인 것 처럼,
Servlet도 명세고, 구현체로는 Tomcat 같은 것이 있는 것이다.
그래서 Servlet 코드를 열어보면 대부분이 인터페이스밖에 없다.
Servlet은 Spring처럼 ServletContext라는 Container에서 관리된다.
이 Servlet Container에서 여러 개의 Servlet을 관리하는 식으로 동작을 하게 된다.
Servlet이 실제 통신을 할 수 있도록 기능을 구현해주고,
그것들을 관리하는 Container까지 구현을 하면 그것이 Tomcat이다.
2. 그렇다면 Tomcat과 Spring의 관계는 어떻게 되는 것인가.
스프링부트의 시대에서 스프링과 Tomcat의 관계를 보고 좀 놀랐다.
Spring 프로젝트 내부에 main 메서드가 없는 것과 같은 맥락의 이유인데,
Tomcat이 내부적으로 Spring을 실행한다.
당연히 스프링을 켜고 Tomcat과 연결을 하거나 그러는 줄 알았는데 그렇지 않았다.
(참고로 지금의 SpringBoot는 스프링 내부에서 Tomcat을 실행한다)
스프링 내부적으로 Servlet을 따로 구현하는데 그 이름이 DispatcherServlet이다.
그리고 이 dispatcherServlet들은 Tomcat의 Container에 포함된다.
그 다음,
이 DispatcherServlet은 사용될 때마다 Spring의 ApplicationContext를 가져가다 쓴다.
그리고 우리의 스프링에 등록된 다양한 Component(Service, Repository 등)을 사용하여 요청을 처리한 다음 결과를 반환하게 된다.
3. 기타 내용 정리
1) Context Hierarchy
코드로 선언이 될 때 Distpatcher Servlet이 Context를 감싸는 식으로 구성이 된다.
DispatcherServlet servlet = new DispatcherServlet(context);
보통 하나의 WebApplicationContext이 여러 개의 DispatcherServlet에 의해서 공유되거나 재사용 된다.
2) Special Bean Types
다음은 Web Mvc에서 사용하는 대표적인 기본 빈들의 목록이다.
- HandlerMapping: request를 매핑하는 빈.
구현체로는 RequestMappingHandlerMapping, SimpleUrlHandlerMapping이 있다.
- HandlerAdapter: 실제 Handler(Controller 의 메서드) 를 관리하는 빈이다.
- HandlerExceptionResolver: Exception을 다루는 빈
- ViewResolver: string 주소를 실제 View로 연결하는 빈
- 기타: LocaleResolver, ThemeResolver, MultipartResolver, FlashMapManager 등
3) Web Mvc Config
대부분의 설정은 Mvc Config에서 이루어진다.
4) Servlet Config
Webapplication을 초기화 하기 위한 여러 가지 방법에 대하여 다루고 있다.
WebApplicationInitializer,
AbstractAnnotationConfigDispatcherServletInitializer,
AbstractDispatcherServletInitializer
같은 것들을 구현하여 초기화가 가능하다.
5) Processing(요청 시 DispatcherServlet의 실행 과정)
- WebApplicationContext을 찾아 바인딩 한다.
- Locale Resolver가 바인딩 된다.
- Theme Resolver가 바인딩 된다.
- Multipart File Resolver가 필요하다면 바인딩된다.
- 요청에 해당하는 Handler를 찾아 결과를 반환한다. preprocessor, postprocessor 등의 과정도 여기에 포함된다.
- Model이 return 되고, view가 렌더링된다.
6) Interception
인터셉터를 사용해 특정 Url에 대한 preHandle과 postHandle 같은 것들을 적용할 수 있다.
결과값으로 true를 반환하면 handler 체인을 진행하고, false면 중단한다.
7) Exceptions
Exception이 발생하면 HandlerExceptionResolver에게 그 예외를 넘긴다.
주 구현체는 4가지 정도가 있으며, 사용자가 Exception을 다루는 방식에 따라 구현이 달라진다.
(@ExceptionHandler나 @ControllerAdvice 같은 것들, 또는 @ResponseStatus 의 사용에 따라 따라 다르다.)
Exception의 체인을 설정해 순서를 조절할 수도 있다.
기타) View Resolution, Locale, Themes, Multipart Resolver, Logging
DispatcherServlet에서 기타 수행하는 기능들이다.
이후 목차) 대부분 사용법에 대한 내용이 많아서 한 번 읽어보고 이후에 참고하면 될 듯 하다.
- Filters
- Annotated Controllers: 기존 @Controller의 사용법
- Functional Endpoints: 스프링 5.x 에서 등장한 함수형 엔드포인트 방식의 사용법
- URI Links
- Asynchronous Requests
- CORS
- Web Security: Spring Security에서 자세히 다룸
- HTTP Caching
- View Technologies
- MVC Config
- HTTP/2
- REST Clients
- Testing
- WebSockets
'Study' 카테고리의 다른 글
Spring Security 뼈대 정리(Tomcat에서 Spring 까지의 처리 과정) (0) | 2021.07.12 |
---|---|
Spring Web MVC 코드 분석(Initialization와 DispatcherServlet) (0) | 2021.06.22 |
Spring IoC 코드 읽어보기 (0) | 2021.06.12 |
스프링 Core 문서 읽고 정리하기 - 2. Resource ~ 5. Aop (0) | 2021.06.05 |
스프링 Core 문서 읽고 정리하기 - 1. IoC (0) | 2021.05.26 |