- 디스패처 서블릿
- 최초 앞단에서 request요청을 받아서 필요한 클래스에 넘겨준다.
왜? web.xml(문지기)에 다 정의하기가 너무 힘듬.
이때, 새로운 요청이 생기기 때문에, request와 response가 새롭게 new 될 수 있다. 그래서 아래의 requestDispather가 필요.
bufferedwriter bufferedreader 의 가변 길이의 문자를 받아서 톰캣이 알아서 객체로 만들어준다!
.do 의 특정주소가 들어오면 frontcontroller 가 낚아챈다.
ex) a.do 가 들어오면 자원1에 접근할 수 있도록 reqeust, 다시 요청한다.
톰캣에는 a에 대한 request, response 정보가 있는데, frontcontroller 에서 a.do -> 자원 1로 보내는 요청으로 내용이 덮어씌워지기때문에 기존 내용도 유지하고, 자원1로 보내는 요청내용도 있어야한다.
이 내용을 유지하기 위한 기술 -> requestDispather !
-
RequestDispather : 필요한 클래스 요청이 도달했을때, FrontController에 도착한 request와 response를 그대로 유지시켜준다.
-
dispatherServlet : frontcontroller 패턴을 직접 짜거나 requestDispather를 직접 구현할 필요가 없다. 왜냐하면 스프링에 dispatherServlet이 있기 때문. DispatherServlet은 FrontController패턴 + RequestDispather이다.
DispatherSerlvet이 자동생성되어질 때 수많은 객체가 생성(Ioc)된다. 보통 필터들이다. 해당 필터들은 내가 직접 등록할 수도 있고, 기본적으로 필요한 필터들은 자동 등록 되어진다.
- 애플리케이션 컨텍스트
-
request -> web.xml -> dispatherServlet
dispatherServlet : 컴포넌트 스캔 / 주소 분배를 해준다. -
static : main 메소드가 실행되기 전부터 떠있다!
-
자바파일 : 객체! 생성과 소멸 시점이 있는 애다.
- 스프링부트는 all 스캔한다!
- 디스패처 서블릿이 src 안에 있는 모든 파일을 컴포넌트 스캔해준다!
- 스프링이 어노테이션을 정의해놓았다.(@Controller, @Service, @Configuration , @Repository..)
- dispatherSerlvet 에 가기전에 ContextLoaderListener 가 있다!
디스패처 서블릿이 만들어지면 젤 처음에 스레드가 만들어진다. - 각각의 스레드는 독립적이기 때문에, 서로 영향을 받지 않는다.
- contextLoaderListener가 root_ApplicationContext 파일을 읽는다. 공통적으로 써야하는것들을 메모리에 띄워준다. Ioc 컨테이너에서 관리해준다.
- 데이터베이스에 관련된 것, 모든 클래스에 관련해서 필요한 것들은 root_applicationContext 파일에 담겨있다.(한번만 띄우면 되잖아!계속 new할 필요 없잖아~)
- applicationContext
수 많은 객체들이 ApplicationContext에 등록된다. 이것을 Ioc라고 한다. Ioc란 제어의 역전을 의미한다. 개발자가 직접 new를 통해 객체를 생성하게 된다면 해당 객체를 가르키는 레퍼런스 변수를 관리하기 어렵다. 그래서 스프링이 직접 해당 객체를 관리한다. 이때 우리는 주소를 몰라도 된다. 왜냐하면 필요할때 DI하면 되기 때문이다. DI를 의존성 주입이라고 한다. 필요한 곳에서 ApplicationContext에 접근하여 필요한 객체를 가져올 수 있다. ApplicationContext는 싱글톤으로 관리되기때문에 어디서든 동일한 객체라는 것을 보장해준다.
ApplicationContext의 종류 : root-applicationContext / servlet-applicationContext
-
context는 변태라고 했잖아! 다 알고있는거야. root는
-
servlet-applicationContext 는 ViewResolver, Interceptor, MultipartResolver 객체를 생성하고 웹과 관련된 어노테이션 Controller, RestController 를 스캔한다.
해당 파일은 DispatherServlet에 의해 실행된다. -
root-applicationContext는 해당 어노테이션을 제외한 어노테이션 Service, Repository 등을 스캔하고 DB관련 객체를 생성한다.(스캔이란 메모리에 로딩한다는 뜻)
해당 파일은 ContextLoaderListener에 의해 실행된다. ContextLoaderListener를 실행해주는 녀석은 web.xml이기 때문에 root-applicationContext는 servlet-applicationContext보다 먼저 로드된다.
당연히 servlet-applicationContext에서는 root-applicationContext가 로드한 객체를 참조할 수 있지만, 그 반대는 불가능하다. 생성시점이 다르기 때문이다.
Bean Factory
- 필요한 객체를 Bean Factory에 등록할 수도 있다. 여기에 등록하면 초기에 메모리에 로드되지 않고, 필요할 때 getBean()이라는 메소드를 통해 호출하여 메모리에 로드할 수 있다. 이것 또한 Ioc이다. 필요할때 DI 하여 사용할 수 있는데, ApplicationContext와 다른 점은 Bean Facotry 에 로드되는 객체들은 미리 로드되지 않고, 필요할 떄 호출하여 로드하기 때문에 lazy-loading 된다는 점이다.
- 스프링부트가 응답하는 방법!
-
요청 주소에 따른 적절한 컨트롤러 요청(Handler Mapping)
-
html 파일을 응답할지 data를 응답할지 결정해야하는데, html 파일을 응답하게되면 ViewResolver가 관여하게 된다.
-
하지만, data를 응답하게 되면 messageConverter가 작동하게 되는데, 메세지를 컨버팅할때 기본전략은 json이다.
-
viewResolver가 WEB-INF/views/hello.jsp
suffix, frefix를 통해 앞 뒤에 경로를 붙여준다! -
@ResponseBody return 값을 데이터로 본다!
요청한 사람한테 데이터를 전달해준다. -
객체를 전달해주면 json으로 변환해서 전달해준다. (이 역할은 messageConvertor가 해준다.)
ex) return user; 이면 messageConverter가 {"id":1, "name" : "홍길동"으로 변환해서 전달해준다.} -
data로 응답을 하게 되면 jackson이 동작을 한다. jackson 이라는 것보다 더 좋은 게 나오면 전부 수정해야하기때문에, messageConverter 라고 부른다. (messageConverter를 추상화로 놓고 jackson 구현 객체)
** 추가
- 디스패처 서블릿은 Http 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 보내주는 frontController이다.
- 동작 원리
1.클라이언트의 요청을 디스패처 서블릿에 전달
2. 요청한 url에 맞는 controller검색하여 handler mapping 에 전달
3. handler mapping에서 해당 controller 에 처리 요청
4. controller에서 처리 결과를 handler adapter에서 modelandview객체로 변환하여 dispatherservlet에 전달
5. dispatherServlet에서 전달받은 modelAndView 객체를 이용하여 매핑되는 view 를 검색
6. viewResolver에서 처리 결과를 view에 전달
7. 처리결과가 포함된 view를 dispather Servlet에 전달
8. Dispather Serlvet에서 최종 응답결과를 클라이언트에게 반환
