Tomcat의 Context path를 분리하는 이유

1. 애플리케이션 구분

2. URL 설계와 관리 용이성

3. 보안 관리

4. 리소스 분리

   vi server.xml
   
   <Host name="localhost"  appBase="webapps"
           unpackWARs="true" autoDeploy="true">
   <Context path="/appiron-inspect" docBase="appiron-inspect" reloadable="true" />

   contest path : URL요청시 들어오는 값을 의미
   docBase : webapps디렉토리 안의 경로를 의미 (war)가 풀렸을때 디렉토리 이름
   reloadable : Java 파일이 수정시 재기동하지 않아도 바뀌게 해주는 옵션(Debug)
   WEB-INF의 클래스와 Lib 디렉토리를 모니터링 변경이 감지되면 웹 응용 프로그램을 다시로드
   기본값은 false (WAS를 사용자가 직접 재기동해야 반영 됨)

   <Host name="localhost"  appBase="/opt/app" unpackWARs="true" autoDeploy="false" deployOnStartup="false">
   <Context path="" docBase="ROOT.war" reloadable="false">
   </Context>

옵션 정리

unpackWARs="true" # WAR 파일의 압축을 풀어서 배치
autoDeploy="false" # 자동 배치
deployOnStartup="false" # 제일 상위의 옵션으로 실행시 ROOT와 appiron-inspect 두개의 Context가 생긴다. 그것을 방지
Context path="" # 빈칸으로 두게되면 /로 자동 지정
reloadable="false" # true 옵션이면 일정 주기마다 (15초) 루트경로의 Class파일 변경여부 확인하여 자동으로 재기동하여 리로드 시킨다.

고려사항

OOME(Out Of Memory)

리로드 될때 기존 클래스파일의 메모리가 해제되는 것은 아님.
기존 클래프파일의 메모리는 그대로 두고 신규 클래스파일의 메모리가 새롭게 할당됨.
결국 클래스파일의 변경이 자주 있고 이것이 누적될 경우 heap memory 부족으로 oome발생

Jenkins 배포시 오류

jenkins 배포가 진행되는 동안, ant 빌드나 maven빌드를 통해 class파일이 변경되고 이때 서버에서 reloadable옵션이 true이면 서버가 자동 재기동된다.
이때 배포과정에 민감한 솔루션이 포함되어있다면 에러를 발생시킬수 있다.