tomcat server.xml

server.xml는 다음과 같은 구조로 구성되어있습니다.

-. Top level Elements : <server>는 설정파일 전체에서 Root Element이며 반면에

    <service>는 하나의 Engine과 연관된 Connector들의 집합을 말합니다.

    top level elements에는 <server>, <service>등이 있습니다.

-. Connector : 외부 Client와 요청을 주고 응답을 받는 Interface를 말합니다.

    connector에는 <HTTP>, <AJP>등이 있습니다. 오호~ 프로토콜과 관계된 것들이군요

-. Containers : 요청을 받아 응답을 처리하는 기능들의 Component를 말합니다.

     하나의 Engine은 하나의 Service에대한 모든 요청을 처리하며,

     하나의 Host는 하나의 Virtual Host에 대한 모든 요청을 처리하며,

     하나의 Context는 하나의 Web Appliction에 대한 모든 요청을 처리합니다.

    container에는 <Context>, <Engine>, <Host>등이 있습니다.

-. Nested Component : Nested Component는  Container의 어느 Element안에 중첩될 수도

    있으며 어떤 Element들은 Container안에도 중첩될 수 있는 반면에 다른것들은

     Context안에만 중첩될 수 있다.

    <Logger>, <Realm>, <Resources>, <Loader>등이 있습니다.

위에서 보니 볼것이 생각외로 많습니다.

하지만 머니머니 해도 젤 중요한건 Context이겠죠. 요 Context만 살작 보겠습니다.

Context가 그럼 멀까요?

Context는 특별한 Viertual Host에서 작동하는 하나의 Web Application입니다.

각 Web Application은 하나의 Web Application Archive(WAR) file나,

이에 대응하는 unpacked된 Content를 가지는 directory를 말합니다.

Tomcat 4.x 대 까지만 해도 context는 server.xml에 기술할 수 있었습니다.

하지만 Tomcat 5.x대 부터는 달라졌더군요.

<Host> elements안에 contenxt를 추가할 수 있지만 xml형식의 개별적인 파일로 저장 할 수도 있습니다.

개별적으로 저장하려면 위치는 $CATALINA_HOME/conf/[enginename]/[hostname]/ directory 가 됩니다.

실제로 이 위치에 가보면 admin.xml등의 파일이 있는 것을 볼 수 있습니다.

디폴트로 된 context의 xml를 만들려면 ROOT.xml로 만드시면 됩니다.

참고로 tomcat문서에서는 <Context>를 server.xml에 직접 기술하는것을 강력히 비추천 하는군요 -ㅠ-

예제) ROOT.xml 입니다. (reloadable="true"를 추가했군요~)

<Context path="" docBase="${catalina.home}/webapps/ROOT"
        debug="0" privileged="true" reloadable="true">

  <Logger className="org.apache.catalina.logger.FileLogger"
                 directory="logs"  prefix="localhost_log." suffix=".txt"
            timestamp="true"/>

</Context>

Logger를 잠시보면 로거로 FileLogger라는 클래스를 사용할 것이며

디렉토리는 톰캣의 logs디렉토리를, 파일명은 localhost_log.yyyy-mm-dd.txt로 하겠다는 겁니다.

여기에 test라는 Context를 하나 더 추가해 봅시다.

우선 test.xml을 다음과 같이 만들어 봅시다.

<Context path="/test" docBase="${catalina.home}/webapps/test"
        debug="0" privileged="true" reloadable="true">

  <Logger className="org.apache.catalina.logger.FileLogger"
                 directory="logs"  prefix="localhost_log." suffix=".txt"
            timestamp="true"/>

</Context>

path에는 context 경로를 적습니다. 각 요청 URI의 시작부분이 context 경로와 같을 때 해당 웹어플리케이션이 그 요청을 처리하게 됩니다. docBase는 이 웹어플리케이션에 대한 파일 경로입니다

설정 끝~

http://localhost:8080/test 를 요청하게 되면 해당 /webapps/test 밑에 있는 파일을 요청하게 됩니다

그럼 Context의 속성을 알아봅시다.

속성	설명
backgroundProcessorDelay	이 값은 컨텍스트와 그 자식 컨테이너에서 background process method가 invoke되는 delay 시간을 나타낸다. 이 값을 양수로 설정하면 어떤 쓰레드가 분기되어 일정 시간 후에 이 쓰레드가 해당 host와 자식 컨테이너에서 background process method를 실행시킵니다 만약 설정하지 않으면 디폴트값인 -1을 가지며 음수의 값은 부모 host의 background processing 정책을 사용한다는 것입니다. 참고로 컨텍스트는 세션을 종료하거나 클래스 리로딩을 위한 모니터링등을 위해 background processing을 사용합니다.
className	사용할 Java 구현체 클래스의 이름. 이 클래스는 반드시 org.apache.catalina.Context 인터페이스를 구현해야 합니다. 지정하지 않으면 표준값 (아래에 정의됩니다)이 사용됩니다
cookies	true (디폴트)로 지정하면 클라이언트가 쿠키를 지원하는 경우 세션확인의 통신수단(session identifier communication)으로 쿠키를 사용합니다. false로 지정하면 세션확인의 통신수단으로 쿠키 사용을 하지 않고, 어플리케이션에 의한 URL 다시쓰기(URL rewriting)에만 의존한다는 의미입니다.
crossContext	true 로 지정하면 이 어플리케이션에서 ServletContext.getContext() 호출을 통해, 이 가상호스트에서 실행중인 다른 웹어플리케이션에 대한 요청디스패쳐(request dispatcher)를 성공적으로 얻을 수 있습니다. 보안상의 이유로 false(디폴트)로 지정하면 getContext()는 언제나 null을 반환하게 됩니다.
docBase	이 웹어플리케이션에 대한 Document Base (Context Root로도 알려져 있습니다) 디렉토리, 또는 웹어플리케이션 아카이브 파일의 경로명(웹어플리케이션을 WAR 파일로 직접 실행하는 경우)을 나타냅니다. 이 디렉토리나 WAR 파일에에 대한 절대경로명을 지정할 수도 있고, 이 Context가 정의된 Host의 appBase 디렉토리에 대한 상대경로명을 지정할 수도 있습니다
override	true로 설정하면 DefaultContext element를 관련된 host에서 명백하게 상속받아 사용합니다 기본값으로 Defaultcontext element가 사용됩니다
privileged	true로 설정하면 이 컨텍스트는 관리자서블릿(manager servlet) 같은 컨테이너 서블릿을 사용할 수 있습니다.
path	이 웹어플리케이션의 컨텍스트 경로(context path)를 나타내며, 각 요청 URI의 시작부분이 컨텍스트 경로와 같을 때 해당 웹어플리케이션이 그 요청을 처리하게 됩니다. 하나의 특정 Host 내의 컨텍스트 경로들은 모두 각각 유일해야 합니다. 만약 컨텍스트 경로를 빈 스트링("")으로 지정하면, 이 Context는 이 Host에 대한 디폴트 웹어플리케이션으로 정의된 것입니다. 디폴트 웹어플리케이션은 다른 Context 들에 해당되지 않는 모든 요청을 처리할 것입니다.
reloadable	true 로 지정하면, Catalina는 /WEB-INF/classes/와 /WEB-INF/lib 안 클래스 들의 변경여부를 감시하다가, 변경이 발견되면 웹어플리케이션을 자동으로 재적재(reload)합니다. 이 기능은 개발중에는 매우 유용하지만 얼마간의 실행부하(runtime overhead)가 발생하므로, 실제 운영할 용도로 어플리케이션을 배치(deploy)할 때는 사용하지 않도록 합니다. 그러나 이미 배치가 끝난 어플리케이션이라도 Manager 웹어플리케이션을 이용하면 필요할 때 재적재 하도록 할 수 있습니다
wrapperClass	이 Context로 관리할 서블릿 들에 대해 사용할 org.apache.catalina.Wrapper 구현체 클래스의 Java 클래스명입니다. 지정하지 않으면 표준값이 사용됩니다

from http://jakarta.apache.org