소스 구성

아래 나오는 환경 변수 $CATALINA_HOME 는 톰캣이 설치된 디렉토리의 경로를 가리킵니다. 대부분의 상대 경로를 해석하는 기준이 되는 디렉토리 입니다. 그러나, 톰캣 4 를 다중인스턴스로 설치를 해서 CATALINA_BASE 디렉토리 설정을 했다면, 각각의 참조를 위해서 $CATALINA_HOME 대신 $CATALINA_BASE 를 사용해야 합니다.

이 매뉴얼이 궁극적으로 추천하는 것은 배치되서 실행하는 어플리케이션을 포함하는 디렉토리 체계(이전 섹션에서 설명)로부터 소스코드를 포함하는 디렉토리 체계(이 섹션에서 설명)를 분리하는 것입니다. 이렇게 분리할 경우 다음의 잇점이 있습니다:

만약 어플리케이션의 "실행되는" 버전이 섞여있지 않다면 소스 디렉토리의 내용이 더 쉽게 관리, 이동, 백업할 수 있습니다.

소스 코드 제어가 보다 쉬워집니다. 소스코드 파일들만 있기 때문이죠.

배치 체계가 분리되어 있다면 설치 배포판을 구성할 파일들을 골라내는 것이 보다 쉬워집니다.

곧 알게 되겠지만, ant 개발 도구를 사용해서 이러한 디렉토리 체계를 노가다없이 생성하고 처리할 수 있습니다.

소스 코드가 놓일 실제 디렉토리와 파일 체계는 맘대로 정할 수 있습니다. 그러나 다음에 소개하는 구성은 보편적으로 적용할만 것이고, build.xml 예제 환경설정 파일에서 사용하게 될 것입니다. 모든 컴포넌트들은 웹 어플리케이션 의 최상위 프로젝트 소스 디렉토리에 있습니다:

docs/ - 웹 어플리케이션의 문서들, 개발팀이 사용하는 것으로 아무 형식이나 상관없습니다.

src/ - 자바 소스 파일이며 웹 어플리케이션에서 서블릿, 빈즈, 다른 자바 클래스들을 생성해냅니다. (강력히 추천하는 바) 소스 코드가 패키지로 구성되어있다면, 이 디렉토리를 기준으로 하위에 패키지 체계처럼 디렉토리 구조를 이루어 놓으면 됩니다.

web/ - 웹 사이트의 정적인 컨텐츠들 (HTML 페이지, JSP 페이지, JavaScript 파일, CSS 스타일시트 파일, 각종 이미지)이 위치하며 클라이언트가 보게 될 것들입니다. 이 디렉토리가 웹 어플리케이션의 문서 루트 document root 이며, 요청 URI 로 접근할 수 있는 자원의 서브디렉토리 구조는 이 디렉토리를 기준으로 하위에 반영되면 됩니다.

web/WEB-INF/ - 웹 어플리케이션의 특별한 환경설정 파일들이 놓이는 자리이며, 웹 어플리케이션 배치 지시자(web.xml)를 포함해서, 손수 만든 사용자 태그 라이브러리를 위한 태그 라이브러리 설명서, 웹 어플리케이션에서 사용하는 다른 자원 파일들이 놓입니다. 이 디렉토리가 웹 어플리케이션의 문서 루트 document root 아래에 위치하고 있지만, 서블릿 스펙에서는 이 디렉토리의 내용이 클라이언트의 요청에 의해 노출되는 것을 금지하고 있습니다. 때문에 웹 어플리케이션을 동작하는 데 필요한, 민감한 환경설정 정보(데이터베이스 연결에 사용되는 아이디와 패스워드 같은)를 놓아두기는 안성맞춤입니다.

개발 과정에서, 임시로 생성되는 두개의 디렉토리가 있습니다:

build/ - 기본 빌드(ant)를 실행할 때, 이 디렉토리는 이 어플리케이션의 웹 어플리케이션에서 사용하는 정확한 파일 구조의 이미지를 형성하게 됩니다. 톰캣 4에서는 $CATALINA_HOME/webapps 디렉토리에 이것을 복사하거나, "Manager" 웹 어플리케이션을 통해서 설치 함으로 이처럼 펼쳐진 형태로 배치를 할 수 있습니다. 후자는 개발기간동안 매우 유용하며, 아래에서 설명할 것입니다.

dist/ - ant dist 타켓을 실행할 때, 이 디렉토리가 생성됩니다. 웹 어플리케이션의 바이너리 배포판의 정확한 이미지를 생성합니다. 라이센스 정보, 문서, README 파일 등 준비한 것들이 포함됩니다.

이 두 개의 디렉토리가 소스코드 관리 시스템에 포함되지 않도록 주의하십시오. 왜냐하면 개발하는 동안 필요에 따라 임시로 생성되고 제거되기 때문입니다. 이러한 이유로, 이 디렉토리에 있는 소스파일을 수정하는 것은 부질없는 짓입니다. 빌드를 할 때 변경된 것이 다 소실되기 때문입니다.

외적인 의존 External Dependencies

외부의 프로젝트나 패키지에 있는 JAR 파일(또는 자원파일)을 웹 어플리케이션에서 사용하려면 어떻할까요? 일반적인 예로는 웹 어플리케이션에서 JDBC 드라이버를 포함해야 할 경우가 되겠습니다.

개발자마다 이에 대한 접근 방식이 다릅니다. 어떤 이들은 이러한 JAR 파일들을 각각의 웹 어플리케이션마다 소스 코드 제어 창고에 복사해서 사용하도록 합니다. 그러나, 이럴 경우 많은 어플리케이션에서 같은 JAR 파일을 사용할 때 중대한 관리 문제가 대두됩니다. 특히 다른 버전의 JAR 파일로 업그레이드 할 경우 그렇습니다.

그러므로, 이 매뉴얼에서 권하는 것은 웹 어플리케이션의 소스 코드 제어 창고 내에 각각의 패키지를 복사해서 관리하지 않도록 하는 것입니다. 대신, 웹 어플리케이션 빌드하는 과정에 외부 의존을 통합시키는 것입니다. 이렇게 하면 필요한 JAR 파일의 버전이 바뀌어도 웹 어플리케이션의 업데이트에 대해 걱정할 필요없이, 개발 시스템 관리자가 설치하는 대로 JAR 파일의 적당한 버전을 사용할 수 있습니다.

예제 ant build.xml 파일에서, 어떻게 build properties 를 정의해서 build.xml 파일을 수정하지 않고, 필요한 파일들의 위치를 설정하는지 보여줄 것입니다. 특정한 개발자가 사용하는 빌드 프로퍼티는 어플리케이션 마다 따로 작성거나 또는 개발자의 홈 디렉토리에 저장된 "표준" 빌드 프로퍼티를 기본으로 사용할 수 있습니다.

많은 경우, 개발 시스템 관리자는 이미 필요한 JAR 파일들을 톰캣 4의 common/lib 이나 shared/lib 디렉토리에 설치해 놓았을 것입니다. 이런 경우라면, 아무것도 안해도 괜찮습니다. 예제 build.xml 파일에는 자동으로 이 디렉토리에 있는 JAR 파일들을 자동으로 classpath 에 포함시 키도록 되어 있습니다.

소스 코드 제어 Source Code Control

앞에서 얘기한대로, 웹 어플리케이션의 모든 소스 파일을 버전 관리 시스템(CVS; Concurrent Version System) 과 같은 도구를 사용해서 관리하는 것을 강력히 추천합니다. 이것을 사용하기로 결정했다면, 소스 체계를 구성하는 각각의 디렉토리와 파일은 모두 등록되고 저장되어야 됩니다 -- 생성된 파일들은 제외됩니다. 만일 바이너리 형식 파일 을 등록한다면(이미지나 JAR 라이브러리 같은), 소스 코드 제어 시스템에 이것을 지정 해줘야 됩니다.

(지난 섹션에서) 개발과정의 생성물인 build/ 와 dist/ 디렉토리의 내용은 소스 코드 제어 시스템에 등록하지 않아야 된다고 말했습니다. CVS가 이들 디렉토리를 무시하도록 지정하는 쉬운 방법이 있는데, .cvsignore (파일명이 . 으로 시작됨)파일을 만드는 것입니다. 이 파일을 최상위 소스디렉토리에 놓아두고, 내용은 다음과 같습니다:
build
dist
build.properties
build.properties 파일이 여기에 들어있는 이유는 Processes 섹션에서 설명하겠습니다.

소스 코드 제어 환경의 자세한 내용은 이 매뉴얼의 범주를 벗어납니다. 그러나, 커맨드 기반 CVS 클라이언트 사용할 때 다음의 단계를 밟아나갈 것입니다:

소스 저장소에 있는 새로 변경된 소스를 먼저 받아오기 위해서 프로젝트의 소스 디렉토리로 이동한 후에 다음 명령을 실행합니다. cvs update -dP

소스 코드 체계에 새로운 하위 디렉토리를 만들었다면, 다음 명령으로 CVS 에 그 디렉토리를 등록합니다. cvs add {subdirname}

새로 소스코드 파일을 만들었을 경우, 그 파일이 있는 디렉토리로 가서, 다음 명령으로 새로운 파일을 등록합니다. cvs add {filename}

어떤 소스 코드가 더이상 필요없을 경우, 그 파일이 있는 디렉토리로 이동한 후 파일을 삭제합니다. 그리고나서, CVS 에 등록된 것도 다음 명령으로 제거합니다. cvs remove {filename}

소스 파일들을 생성, 수정, 삭제하는 동안에는 변경사항은 서버 저장소에 반영 되지 않은 상태입니다. 현재 상태를 저장하려면, 프로젝트 소스 디렉토리로 가서 cvs commit 을 실행합니다. 방금 완료한 변경사항에 대한 짧은 설명을 적게 됩니다. 이것은 새로 갱신되는 소스 파일의 새 버전과 함께 저장됩니다.

CVS 나 이와 같은 소스 코드 제어 시스템은 부가적인 기능들이 많이 있습니다. (예를 들면 특정 버전을 구성하는 파일들에 태그를 달아 놓는 기능과 나중에 합쳐질 다중 개발 서브프로젝트의 지원 등). 더 자세한 내용은 소개 Introduction에 있는 링크와 참고사이트를 보십시오.

BUILD.XML 환경설정 파일 Configuration File

ant를 사용해서 자바 소스 코드 파일들을 컴파일하는 것과 배치 체계의 생성을 관리하려고 합니다. 필요한 처리 단계를 정의한 build.xml 빌드 파일의 설정대로 Ant 는 동작합니다. 이 파일은 소스 코드 체계의 최상위 디렉토리에 있어야 되고, 소스 코드 제어 시스템에 등록해야 됩니다.

Makefile 처럼 build.xml 파일에는 여러개의 "targets" 가 있습니다. 각각의 target 은 선택적인 개발 동작을 지원합니다(예를 들면 관련 javadoc 문서 생성, 갱신을 위해서 자동 생성된 배치 홈디렉토리 제거, 어플리케이션 배포판 만들기 위해서 웹 어플리케이션 압축 파일 생성 등). 잘 만들어진 build.xml 파일에는 내부에서 사용되는 target 에 대해서, 개발자가 사용하도록 설계된 target 을 설명하는 내부 주석을 포함하고 있습니다. ant 에서 지원하는 프로젝트 문서를 보기 위해서는 build.xml 파일이 있는 디렉토리에서 다음과 같이 타이핑하면 됩니다:
ant -projecthelp
처음 사용하는 분들을 위해서, basic build.xml 파일을 제공합니다. 이 파일을 각자의 어플리케이션 프로젝트 소스 디렉토리에 맞게 수정해서 사용할 수 있습니다. 이 파일에는 다양한 target의 기능에 대해서 주석으로 설명합니다. 요약하면, 다음 target 이 일반적으로 제공됩니다:

clean - 이 target 은 기존의 build 와 dist 디렉토리를 삭제하고, 재 생성할 수 있게 만듭니다. 변경된 클래스를 확실히 재컴파일해서 수정된 사항이 확실히 반영될 수 있도록 합니다.

compile - 이 target 은 마지막 컴파일 이후로 변경된 소스파일만 컴파일하는데 쓰입니다. 결과로 생성된 클래스 파일은 build 디렉토리의 WEB-INF/classes 하위 디렉토리, 즉 웹 어플리케이션 구조에서 있어야 될 위치에 놓이게 됩니다. 이 명령은 개발 중에 아주 자주 실행되기 때문에, 보통 "default" 기본으로 지정해서 단지 ant 명령어만으로도 실행 하도록 합니다.

all - 이 target 은 clean target 을 실행하고, 곧바로 compile target 을 실행하도록 합니다. 때문에, 전체 어플리케이션을 재컴파일하도록 보장하기 때문에 모든 변경사항이 확실히 반영됩니다.

javadoc - 이 target 은 웹 어플리케이션의 자바 클래스들의 Javadoc API 문서를 생성합니다. 예제 build.xml 파일은 웹 어플리케이션 배포판에 API 문서를 포함하는 것으로 가정했고, dist 디렉토리의 하위 디렉토리에 docs 디렉토리를 생성하게 됩니다. 매번 컴파일할 때마다 문서를 만들 필요가 없기 때문에 compile target이 아닌 dist target 에 의존적으로 되어있습니다.

dist - 이 target 은 웹 어플리케이션의 배포 디렉토리를 만들고, 필요한 문서와 자바 클래스의 javadoc 그리고, 시스템 관리자가 설치하는데 사용할 웹 어플리케이션 압축(WAR) 파일을 포함합니다. 이 target은 deploy 에 의존하기 때문에, 배치할 때 필요한 외부의 파일들도 WAR 파일 안에 포함을 시켜야됩니다.

톰캣 4 에서 웹 어플리케이션을 상호작용하면서 개발을하고 테스트를 하기위해서, 다음의 추가 target들이 정의되어야 됩니다:

install - 운영중인 톰캣 4가 개발중인 어플리케이션의 실행과 테스트를 즉시 적용하도록 설치를 지시합니다. 이 동작은 톰캣 4를 재시동할 필요가 없습니다만, 톰캣 재시동 시에는 기억되지 않습니다.

reload - 일단 어플리케이션이 설치되면, compile target을 사용해서 변경하고 재 컴파일할 수 있습니다. 톰캣 4는 자동으로 JSP 페이지의 변경을 인지하지만, 서블릿과 자바빈즈 클래스는 그렇지 않습니다. 이 target은 톰캣이 현재 설치된 어플리케이션을 재시작해서 그러한 변경사항을 반영하도록 합니다.

remove - 개발과 테스트를 완료했을 때, 선택적으로 이 어플리케이션을 서비스에서 제거하도록 톰캣에 지시할 수 있습니다.

개발과 테스트 target은 다음 페이지에서 설명할 부가적인 일회성 설정이 필요합니다.