위와 같이 정상 실행되는 것이 확인된다. 다만, 웹 프로젝트는 가능하면 절대 경로를 이용하는 것이 바람직하므로 Tomcat의 'Modules' 메뉴를 이용해서 '/'경로로 프로젝트가 실행될 수 있도록 한다.
Server > Tomcat 더블 클릭
Tomcat의 'Modules' 메뉴 수정 전
http://localhost:8080/controller// 경로는 찾을 수 없음
Tomcat의 'Modules' 메뉴 수정 후 재실행
'/' 경로 인식 완료
예제 프로젝트의 로딩 구조
: 프로젝트 구동시 관여하는 XML은 web.xml, root-context.xml, servlet-context.xml이 있다.
web.xml : Tomcat 구동과 관련된 설정 파일 root-context.xml : Spring Core등 일반 JAVA 영역 servlet-context.xml : Spring MVC 등 Web 관련 영역
1. 프로젝트의 구동은 web.xml부터 시작!
web.xml 일부
<context-param>에는 root-context.xml의 경로가 설정되어 있고, <listener>에는 스프링 MVC의 ContextLoaderListener가 등록되어 있는 것을 볼 수 있다. (ContextLoaderListener가 가장 먼저 실행된다.)
프로젝트 구동시 가장 먼저 ContextLoaderListener의 로그가 출력됨을 확인 가능
2. root-context.xml 처리
: root-context.xml이 처리되면 파일에 있는 빈(Bean) 설정들이 동작한다. 즉, 객체(Bean)들은 스프링의 영역(Context) 안에 생성되고, 객체들 간의 의존성이 처리된다.
3. DispatcherServlet의 동작
: 스프링 MVC에서 사용하는 DispatcherServlet이라는 서블릿 관련 설정이 동작한다. 이는 내부적으로 웹 관련 처리의 준비작업을 진행하며, servlet-context.xml 파일을 기반으로 한다.
web.xml 일부
프로젝트 구동 후 로그 일부를 보면,
XmlWebApplicationContext 를 이용해서, servlet-context.xml을 로딩하고 해석한다.
이 과정에서 등록된객체(Bean) 들은 기존에 위에서 만들어진 객체들과 같이 연동된다.
스프링 MVC의 기본 사상
: 스프링 개발자들은 직접적으로 Servlet/JSP(HTTPServletRequest/HTTPServletResponse 등) 의 API를 사용할 필요성이 준다. 스프링은 중간에 연결 역할을 하기 때문에 이러한 코드를 작성하지 않고도 원하는 기능을 구현할 수 있는 유용함이 있다.
1) 사용자의 Request는 Front-Contoller인 DispatcherServlet을 통해서 처리한다. 모든 Request는 DispacherServlet이 받는다.
2~3) HandlerMapping은 Request의 처리를 담당하는 컨트롤러를 찾는 역할을 한다. 적절한 컨트롤러가 찾아지면 HandlerAdapter를 이용해서 해당 컨드롤러를 동작시킨다. (HandlerMapping 인터페이스를 구현한 여러 객체들 중 RequestMappingHandlerMapping 같은 경우는 개발자가 @RequestMapping 어노테이션이 적용된 것을 기준으로 판단한다.)
4) Controller는 개발자가 작성하는 클래스로 실제 Request를 처리하는 로직을 작성한다. Controller는 다양한 타입의 결과를 반환하는데 이에 대한 처리는 ViewResolver를 이용한다.
5) ViewResolversms Controller가 반환한 결과를 어떤 View를 통해서 처리하는 것이 좋을지 해석하는 역할을 한다. servlet-context.xml
6~7) View는 실제로 응답 보내야하는 데이터를 JSP 등을 이용해서 생성하는 역할을 하며, 만들어진 응답은 DispatcherServlet을 통해서 전송된다.