톰캣 클래스패스의 이해 (번역)

톰캣의 클래스패스 (웹어플리케이션이 필요로하는 JAR 파일을 찾는) 를 어떻게 설정하는지에 관한 문제는 

어느 게시판을 가더라도 많은 흔한 주제이다.

왜 톰캣 유저에게 클래스패스가 문제를 일으키나? 

classpath  는 JVM 에게 해당 어플리케이션을 동작시키기 위해 클래스/패키지를 어디서 찾으라고 알려주는 인자이다. 

근데 왜  저런 클래스 패스를 잘 알고있는 경험많은 자바 개발자들이 톰캣에서는 문제를 가질까? 

그것에 대한 3가지 답변이 있다.

1. Tomcat 는 다른 자바프로그램과 동일한 방법으로 classpath 를 바라보지 않는다.
2. Tomcat 이 classpath 를 해결하는 방법은 매 버전마다 조금씩 달라져 왔다.
3. 톰캣의 기술문서와 기본 설정은 어떤것을 이루어내는 가장 좋은 방법을 푸쉬하는데, 만약 이 가장좋은 방법을 
   따르지 않는다면 , 어둠속에서 배회하게 될것이며  만약 니가 다른 이상한 짓을 한다면 , 별다른 정보를 제공받지 못할것이다.
   (바깥에 있는 디펜던시 , 공유되는 디펜던시  or  동일한 라이브러리/클래스의 다중 버전 같은..) 

일반적인 사용법과 달리 어떻게 톰캣 클래스 패스는 사용되는가?

모든 아파치 톰캣은 가능한 자동적이면서,  직관적이며,  자기-포함 (self-contained) 이라는 목적을 갖고있는데 효율적인 관리를 위해 웹 어플리케이션의 배포나 설정을 표준화하려고 노력중이다. 그와 동시에 보안과 네임스페이스 이유에 대한 여러 라이브러리들의 접근을 제한하고 있다. (?)

자바 클래스 패스 환경 변수를 사용하는것보다 어려운 이유는 , 톰캣의 "시스템" 클래스로더를 만들어질때  톰캣의 스타트 스크립트는 이런 변수(OS환경변수) 를 무시하며,자신의 클래스패스를 만들어버린다.  

Tomcat 이 어떻게  classpath 를 설정하는지 이해하기위해  Tomcat 6 의 시작 프로세스를 살펴보자.

1. JVM 부트스트랩 로더는 코어 자바 라이브러리를 로딩한다. JAVA_HOME  변수를 통해서 코어라이브러리의 위치를 알수있다.
   
   
2. Startup.sh 은 "start"  파라미터와 함께  bin/Catalina.sh 를 호출하며 , 시스템 클래스 패스를 덮어쓰고  bootstrap.jar  과 tomcat-juli.jar. 를 로딩한다.  이 리소스들은 오직 Tomcat 한테만 보인다.
   
   
3. 클래스로더들은 각각 디플로이된 컨텍스트에 대해 생성되며  그것들은 웹 어플리케이션 마다의   WEB-INF/classes 와 WEB-INF/lib  안에 있는 JAR 와 클래스들을 로드한다. 이런 리소스들은 오직 그들을 로드한 웹어플리케이션에만 보인다.
    
4. Common 클래스로더는  $CATALINA_HOME/lib 에 있는 모든 클래스들과 JAR 를 로드한다.  이 리소스들은 톰켓과 모든 어플리케이션에 노출된다.
   
   

톰캣은 4개 혹은 그 이상의 속성에 의해 설정된 여러가지 클래스패스들을 해석하는데,  그것중에 

하나만 표준위치에 있을뿐이다.톰캣에 공통 라이브러리를 추가하려면  TOMCAT_HOME/bin/catalina.sh 

파일에  CLASSPATH를 추가해주거나 TOMCAT_HOME/conf/catalina.properties  에 common.loader를 추

가해 주면 된다.

레퍼런스 : https://www.mulesoft.com/tcat/tomcat-classpath