개요

Tomcat의 가상 호스트 위에서 실행되는 웹 어플리케이션을 뜻하며 각 Context는 Context Path로 정의된다 (Context Path가 유니크하지 않음). 각각의 Context는 WAR(Web Application Archive) 파일 또는 해당 WAR 파일이 unpack된 디렉토리를 기반으로 동작한다. 이 때 하나의 가상 호스트에서 HTTP 요청을 수신하면 요청 URI와 가장 길게 매칭되는 Context Path 기준으로 어떤 Context로 요청을 쏠 것인지 결정한다.

각 Context는 일종의 namespace을 가지고 있다고 생각하면 편한데, Context를 정의하는 xml 태그안에 정의한 Resources 태그의 리소스들이 해당 Context 폴더 안에 보관된다.

안약 Context 태그의 autoDeploy또는 deployOnStartup옵션이 며시되어 있다면, 해당 웹 어플리케이션의 Context Path는 해당 앱 파일이 있는 디렉토리 이름으로 자동 설정된다. 이때 만약 동작 시키고자 하는 앱 파일이 Tomcat 설치 폴더 하위에 있는 webapps가 아닌 다른 장소에 있다면, Context 태그의 appBase태그 값으로 앱 디렉토리 위치를 명시해주어야 한다.

Resources

사용하고자 하는 웹 앱의 정적 리소스에 대한 접근에 대한 설정을 해주는 부분이다.

레포트 어드민 서버의 경우 크게 세 가지의 파일 set이 존재한다

1. JSP, CSS, web.xml 등으로 대표되는 WebContent 하위에 존재하는 정적리소스
2. 자바, 코틀린 소스코드를 컴파일하면 생기는 클래스 파일 및 스프링 초기화에 필요한 각종 xml 파일들
3. 프로젝트가 의존하고 있는 다양한 의존성 패키지들

Smart Tomcat의 경우 1번 폴더를 가상 호스트 최상단의 webapps 폴더로 인식하기 때문에 (=appBase ==docBase) 이 폴더만 지정해주면 JSP에서 import 문을 수행하기 위한 2번 리소스들이 없을 것이다. 그래서 PreResources태그를 통해 컴파일이 완료된 모든 클래스 파일 및 필수적인 스프링 관련 xml 파일들의 위치를 지정해주고 (base) 해당 위치에 있는 파일을 “가상으로” webAppMount에 명시되어 있는 위치로 옮겨준다. 그 후, 해당 클래스 파일들이 의존하고 있는 각종 라이브러리 jar 파일 역시 각각 PostResources태그로 실제 위치와 가상 위치인 webAppMount을 명시 해줌으로써 가짜 WAR exploded 디렉토리를 만든다. 그 후에 이 디렉토리를 기반으로 Java RunTime을 띄워 서버를 올리는 방식이다.

<aside> 💡 Watched Resources란 해당 태그에 명시되어 있는 디렉토리를 감시하고 있다가 만약 소속된 파일에 변경점이 생긴다면 자동으로 앱의 메모리를 reload 해준다.

</aside>