> 스프링부트 동작원리
내장 톰켓을 가진다.
- 톰켓을 따로 설치할 필요 없이 바로 실행이 가능하다.
- 소켓 통신 : 연결 지속, stateful 방식
- 소켓을 기반으로 한 http 통신 : stateless 방식(연결 지속하지 않고 끊어버림)
- 웹서버 : 아파치(요청한 정적인 파일 응답) + 톰켓(요청한 파일 중 자바 파일이 있으면 컴파일 하여 html파일로 번역해서 응답)
- 스프링에서는 전부 자바 파일(서블릿)을 요청하기 때문에 아파치는 동작하지 않음
서블릿 컨테이너 (톰켓)
- URL : 자원 접근 (예: http://www.yeonji.com/a.png) - 아파치 실행!! 톰켓 실행 X
- URI : 식별자 접근 - 특정한 파일 요청을 할 수 없고 요청시에는 무조건 자바를 거친다. - 톰켓 실행!! (예: http://www.yeonji.com/picture/a)
web.xml
- ServletContext의 초기 파라미터
- Session의 유효시간 설정
- Servlet/JSP에 대한 정의
- Servlet/JSP 매핑
- Mime Type 매핑
- Welcome File list
- Error Pages 처리
- 리스너/필터 설정
- 보안
여기에서 Servlet/JSP 매핑시(web.xml에 직접 매핑 or @WebServlet 어노테이션 사용)에 모든 클래스에 매핑을 적용시키기에는 코드가 너무 복잡해지기 때문에 FrontController 패턴을 이용함.
FrontController 패턴
- 위에서 언급했듯이 web.xml에서 다 정의하기가 너무 힘이 든다. 따라서 최초 앞단에서 request 요청을 받아서 필요한 클래스에 넘겨준다.
- 이때 새로운 요청이 생기기 때문에 request와 response가 새롭게 new될 수 있다.
- 그래서 아래의 RequestDispatcher가 필요하다.
RequestDispatcher
- 필요한 클래스 요청이 도달했을 때 FrontController에 도착한 request와 response를 그대로 유지시켜준다.
- 데이터를 그대로 들고 다른 페이지로 이동할 때 사용
⭐ 스프링의 DispatchServlet
- DispatchServlet = FrontController 패턴 + RequestDispatcher
- 컴포넌트 스캔 (패키지 하위 전부 스캔하여 해당하는 어노테이션 붙어 있으면 메모리에 띄움 - @Controller, @RestController, @Configuration ...)
- 메모리에 띄운 후(new) 주소 분배
- static : main 메서드 전부터 메모리에 떠있음. 태초부터 존재!
- 자바 파일 : 객체 (생성과 소멸이 있음)
- FrontController 패턴을 직접 짜거나 RequestDispatcher를 직접 구현할 필요가 없다.
- DispatchServlet이 자동생성 되어 질 때 수 많은 객체가 생성(Ioc)된다.
- 보통 필터들이고, 해당 필터들은 내가 직접 등록할 수도 있고 기본적으로 필요한 필터들은 자동 등록 되어진다.
스프링 컨테이너
- DispatchServlet에 의해 생성되어지는 수 많은 객체들은 어디에서 관리될까?
- 첫째, ApplicationContext 둘째, Bean Factory
요청 주소에 따른 적절한 컨트롤러 요청 (Handler Mapping)
- DispatchServlet이 컴포넌트 스캔을 통해 메모리에 띄우고, 주소 분배를 할 때 Handler Mapping에게 해달라고 함
- GET요청 -> 해당 주소 요청이 오면 적절한 컨트롤러의 함수를 찾아서 실행
응답
- html 파일을 응답할지 Data를 응답할지 결정해야 한다.
- htm 파일을 응답하게 되면 ViewResolver가 관여하게 된다.
- Data를 응답하게 되면 MessageConverter가 작동하게 되는데 메세지를 컨버팅 할 때 기본 전략은 json이다.
