스프링부트 개념정리(4) - web.xml

(3) web.xml (약간 문지기 같은 애)

-ServletContext의 초기 파라미터

-Session의 유효시간 설정

-Servlet/JSP에 대한 정의

-Servlet/JSP 매핑

-Mime Type 매핑

get 방식의 요청은 데이터를 들고 오지 않는다.

클라이언트가 들고온 데이터 타입 체크해서 가공, 매핑

-Welcome File list

아무 이유없이 들어온 애들 모아놓는 곳 설정함

-Error Pages 처리

-리스너/필터 설정

필터 : 들어온 애 신분 확인해서 걸러내는 것

리스너 : 문지기 대리인 역할

-보안 

이상한 애 들어오면 쫓아보냄

 

-여기에서 Servlet/JSP 매핑시(web.xml에 직접 매핑 or @WebServlet 어노테이션 사용)에 모든 클래스에 매핑을 적용시키기에는 코드가 너무 복잡해지기 때문에 FrontController 패턴을 이용함.

 

(4) Frontcontroller 패턴

 

최초 앞단에서 request 요청을 받아서 필요한 클래스에 넘겨준다. 왜? web.xml에 다 정의하기가 너무 힘들기 때문에.

특정주소로 최초요청이 오면 바로 자원으로 못가고 web.xml로 가서 톰켓이 request, response 객체를 만든다.

이 request은 요청한 사람의 정보(어떤 데이터를 요청했는지, 어떤 데이터를 들고왔는지)를 들고있다.

이 정보를 토대로 response 객체를 만든다. 이 때 web.xml에 jsp 서블릿 매핑이 너무 많이 들어있으면 너무 복잡해진다.

그래서 특정주소가 들어오면 전부 다 프론트 컨트롤러가 낚아채라고 세팅해두면 frontcontroller가 낚아채서 알맞은 자원을 찾아갈 수 있게 다시 한번 request한다.  

이때 새로운 요청이 생기기 때문에 request와 response가 새롭게 new 될 수 있다. 그래서 아래의  RequestDispatcher가 필요하다.

(5) RequestDispatcher

필요한 클래스 요청이 도달했을 때 FrontController에 도착한 request와 response를 그대로 유지시켜준다.

그리고 requestDispatcher를 이용해야지 페이기 간 데이터 이동이 가능하다.

데이터를 그대로 가지고 페이지를 이동하는 방법.

(6) DispatchServlet

frontcontroller패턴을 직접짜거나 requestDispatcher를 직접구현할 필요가 없다. 왜냐하면 스프링에는 DispatchServlet이 있기 때문이다. DispatchServlet은 frontcontroller패턴 + requestDispatcher이다.

DispatchServlet이 자동생성되어 질 때 수 많은 객체가 생성(IoC)된다. 보통 필터들이다. 해당 필터들은 내가 직접 등록할 수 도 있고 기본적으로 필요한 필터들은 자동 등록 되어진다.