webtob web container guide - tmaxsoftkr.tmaxsoft.com/img/service/pdf/manual/webtob_3.1_web...구동...

WebtoB Web Container Guide

저작권 Copyright (c) 2000 Tmax Soft Co., Ltd. All Rights Reserved. 본 서의 일부나 전체의 내용은 어떠한 형태로든 무단 복제를 금하며 전기적, 물리적, 사진, 기록 또는 다른 매체로의 복제를 위해서는 반드시 Tmax Soft 의 사전 동의를 얻어야 합니다. 본 제품 사용 중 일어난 특정한, 우발적, 비직접적, 필연적인 손실을 책임지지 않습니다. 그러나 특수한 목적에 적합하고 유통가능하며 규정사항에 위배되지 않을 경우에는 제외됩니다. 본 서에는 기술적인 오류나 인쇄상의 오류가 있을 수 있습니다. 본 서의 내용 중 수정된 부분은 정기적으로 제품의 개정본에 추가 될 것입니다. 본 문서에 포함된 내용은 별도의 사전 통보 없이 내용을 보강하기 위해서 수정되어질 수 있습니다. 상표 Tmax, WebT, WebtoB, JEUS, Host-Link, WebInOne 은 Tmax Soft Co., Ltd.의 상표입니다. 업체 정보 ㈜ Tmax 소프트 135-708 서울시 강남구 대치동 946-1 글라스타워 18 층 Tel: +82-2-6288-2114, 2006 Fax: +82-2-6288-2115 E-Mail: [email protected]

서 문

WebtoB Web Container 는 WebtoB Administration Guide 에 언급된 WebtoB Servlet Engine 을 일컬은 말이다. 이 책은 WebtoB Web Container 에 대한 설명을 하기 위해 WebtoB Web Container 의 관리와 이를 이용한 Servlet, JSP 개발에 대한 내용을 포함하여 WebtoB Web Container 관리에 대해서는 모든 내용을 빠짐없이 기술하였다. 개발 측면에 대해서는 Servlet 과 JSP 의 기본적인 요소에 대한 설명과 각각의 구현 요소에 대해 간략히 설명하였고 개발 과정에서 요긴한 팁들을 다루었다.

WebtoB Web Container 는 JEUS Web Container 와 Architecture 가 유사하

고 WebtoB Web Container 의 기능이 JEUS Web Container 에 모두 포함되

기 때문에 이 책에서 언급되는 내용에 대부분이 JEUS Web Container Guide 의 내용과 동일하게 구성되어 있다.

[이 책의 구성]

이 책은 크게 Ⅰ~Ⅴ장 까지 WebtoB Web Container 의 관리 part 와 Ⅵ~Ⅹ장 까지 Web Application 의 개발 part 로 나누어져 있다. 다음은 이 책을 구성하고 있는 각 장에 대한 설명이다.

1 장 WebtoB Web Container 시작하기

여기에서는 처음 WebtoB Web Container 를 사용하는 사람을 위해 Container 를 실행하는 것부터 시작해서 Container 를 설치하면 기본으로 들어가 있는 servlet 과 JSP 예제들을 실행해 본다.

2 장 Container 의 이해

이 장에서는 WebtoB Web Container 에 대한 기본적인 설명을 한다. 그래서 처음 WebtoB Web Container 를 접하는 사람들이 Web Container 에 대한 개념을 가질 수 있도록 하였다.

WebtoB Web Container Guide 1

3 장 Container 의 설정

이 장에서는 WebtoB Web Container 를 관리할 때 여러 가지 필요한 설정 주제에 대해서 다루었다. container.xml 태그의 설명은 reference 가 따로 있으므로 여기서는 Container 설정의 개념과 간단한 설정 방법들을 다루었다.

4 장 container.xml Reference

이 장에서는 WebtoB Web Container 의 동작을 설정하는 파일인 container.xml 의 각 태그에 대한 자세한 설명을 담고 있다. 따라서 Ⅲ장 Container 의 설정의 reference 로 사용할 수 있도록 하였다.

5 장 Container 의 관리

이 장에서는 WebtoB Web Container 를 관리하는 어떻게 사용하는지에 대해 설명하고 있다.

6 장 Web Application 의 개발

여기에는 Web Application 의 개념을 설명하고 Web Application 의 설정을 하는 web.xml 에 대해서 중점적으로 살펴 보기로 한다. 이 장은 WebtoB Servlet Engine 에서 servlet 이나 JSP 문서 같은 Web Application 들을 관리하기 위해서도 필요하고 개발한 servlet 이나 JSP 문서에 대해서 설정하기 위해서도 필요하다.

7 장 Servlet 의 개요

여기서는 Servlet 의 개념과 대략적인 모습을 살펴 보고 있다.

8 장 Servlet 의 구현

이 장에서는 Servlet 을 구현하는 기본적인 요소들을 설명하고 servlet 으로 구현하는 각각의 주제에 대해 다루어 보았다.

9 장 JSP 의 개요

여기서는 JSP 의 개념과 대략적인 모습을 살펴 보고 있다.

10 장 JSP 의 구현


이 장에서는 JSP 를 구성하는 기본적인 요소들을 설명하고 JSP 를 이용한 개발에 거의 필수적으로 사용되는 JavaBeans 와 custom tag 에 대해서 간단히 살펴 보고 있다.

[누가 이 책을 읽어야 하는가]

이 책은 WebtoB 를 이용해 Web Application 을 개발하고 관리하는 사람에게 필요한 정보를 담고 있다. 다음은 각각의 장의 내용이 필요한 사람들을 나타낸 것이다.

WebtoB Web Container 관리자 : I, III, IV, V, WebtoB Web Container 의 관리

Web Application 개발자 : II~ X, Web Application 의 개발

[글씨체에 대해]

다른 대부분의 책과 같이 java 의 클래스 이름이나 소스 코드에서는 Courier New 글씨체를 사용하였다. 또한 주의할 사항은 Note : 와 같이 표시해 두었다.

또한 각각의 태그를 설명할 때에 필수 요소는 required, 필수 요소는 아니지만 명시적으로 설정해 주는 게 좋은 요소는 recommend, 꼭 사용할 필요가 없는 옵션 요소는 optional 로 표시해 두었다.

[WebtoB 제품별 기능]

Edition 기 능

WebtoB3.1@Base HTML, CGI, PHP, SSI, SSL, Basic WBAPI WebtoB3.1@Standard WebtoB@Base + Multi-Node +

Load Balancing + JSP/Servlet + WBAPI WebtoB3.1@Enterprise WebtoB@Standard + TP-Service + Fail over

[매뉴얼의 예제에 대해서]

이 매뉴얼에 실린 예제에서 운용 환경에 대한 별도의 설명 없이 “예제 환경” 이라고만 언급되었다면 다음과 같은 운용 환경을 가정하는 것이다.


운영 체제 : Windows 2000

WebtoB Servlet Engine 설치 디렉토리 : c:\webtob\jeus

W2B_JEUSHOME 환경변수(%W2B_JEUSHOME%) : c:\webtob\jeus

노드 이름(node name) : webdev

서블릿홈(%W2B_SERVLETHOME%환경변수)

: %W2B_JEUSHOME%\web_home\servlet_home

서블릿 엔진 이름(enginename) : webdev_servlet_engine1

컨텍스트 그룹 documentbase(GroupDocBase) : webapps


컨텍스트 그룹 이름 (GroupName) : MyGroup

차 례

서 문 ............................................................................................... 1

1 WebtoB Web Container 시작하기 ......................................... 11

1.1 Web Container의 구동과 종료 ............................................................................ 11

1.1.1 콘솔툴(admin)을 이용한 Container 실행...................................................... 11

1.2 Example 실행 ....................................................................................................... 13

1.2.1 Servlet 예제 ................................................................................................... 13

1.2.2 JSP 예제 ........................................................................................................ 14

2 Container의 이해 ..................................................................... 17

2.1 Web Application이란?......................................................................................... 17

2.2 Container의 구성 ................................................................................................. 18

2.3 WebtoB Servlet Engine의 디렉토리 구조 .......................................................... 19

2.4 Application의 구성 .............................................................................................. 23

2.4.1 Container에서의 Application 디렉토리 설정 ................................................ 24

2.4.2 컨텍스트 내의 디렉토리 ................................................................................ 25

2.4.3 jspwork 디렉토리 ........................................................................................... 28

2.5 Container의 설정 방법 ........................................................................................ 30

3 Container의 설정 ..................................................................... 31


3.1 Application의 배치와 실행.................................................................................. 31

3.2 Session의 설정 .................................................................................................... 34

3.2.1 Application 단위의 session 설정 .................................................................. 35

3.2.2 컨텍스트 그룹 단위의 session 설정 ............................................................ 35

3.2.3 분산 세션(Distributed Session)...................................................................... 36

3.3 데이터베이스 연결 풀링 ....................................................................................... 48

3.3.1 Web Container에서의 데이터베이스 연결 풀링 ........................................... 48

3.3.2 데이터베이스 연결 풀링의 설정 ................................................................... 49

3.3.3 데이터베이스 연결 풀링의 사용 ................................................................... 51

3.4 웹 서버의 WebtoB Servlet Engine 연결 설정................................................... 51

3.4.1 웹서버 연결이란?........................................................................................... 51

3.4.2 WebtoB와의 연결........................................................................................... 52

3.5 Application 권한부여 설정.................................................................................. 62

3.5.1 Security 관련 container.xml의 설정.............................................................. 64

3.6 Naming 설정......................................................................................................... 65

3.7 그 외의 설정 ......................................................................................................... 66

4 Container.xml Reference ........................................................ 67

4.1 container.xml의 구성........................................................................................... 67

4.2 ContextGroup....................................................................................................... 69

4.2.1 <Context> 태그 – 컨택스트 설정................................................................. 74

4.2.2 <JSPEngine> 태그 – JSP 엔진 설정 ........................................................... 83

4.2.3 <Logging> 태그 – 로그 설정........................................................................ 85

4.2.4 <Connection> 태그 – 웹서버 연결 설정 ..................................................... 89


4.2.5 <DistributedSession> 태그 ............................................................................ 94

4.2.6 <ResponseHeader> 태그 .............................................................................. 96

4.2.7 <ActiveManagement> 설정 ........................................................................... 98

4.3 DB 연결 풀링 설정 ............................................................................................ 102

4.4 Startup/Shutdown Class ................................................................................... 107

5 Container의 관리 ................................................................... 108

5.1 webadmin을 이용한 Container 관리 ............................................................... 108

5.1.1 Container의 상태를 알려 주는 명령들 ........................................................111

5.1.2 Container의 설정 정보에 관한 명령들 ....................................................... 117

5.1.3 Application 조절(Control)............................................................................. 121

5.2 JSP Batch Compiler의 사용.............................................................................. 123

6 Web Application의 개발 ........................................................ 127

6.1 Web Application이란?....................................................................................... 127

6.2 Web Application 작성 ....................................................................................... 128

6.2.1 WAR란?........................................................................................................ 128

6.2.2 설명자(Web Application Descriptor)란? ....................................................... 129

6.2.3 WAR 파일 만들기........................................................................................ 130

6.3 WebtoB Servlet Engine에 Web Application 등록하기 ................................... 143

7 Servlet의 개요 ........................................................................ 144

7.1 Servlet이란? ....................................................................................................... 144

7.2 WebtoB Servlet Engine에서 지원하는 HTTP Servlet ..................................... 144


8 Servlet의 구현 ........................................................................ 146

8.1 Servlet 시작하기 ................................................................................................ 146

8.1.1 Servlet의 Life cycle...................................................................................... 146

8.1.2 Servlet API의 구성 ....................................................................................... 147

8.1.3 간단한 servlet 작성 ..................................................................................... 151

8.2 Servlet의 요구 경로(Request Path) ................................................................. 155

8.3 Servlet의 session tracking............................................................................... 157

8.3.1 Cookie의 사용.............................................................................................. 157

8.3.2 HttpSession 객체를 사용한 세션 추적....................................................... 159

8.4 동적 컨텐트 생성 ................................................................................................ 160

8.4.1 MIME 타입 ................................................................................................... 160

8.4.2 이진 데이터(Binery data)를 보내기............................................................. 160

8.4.3 GIF 이미지 만들기 ...................................................................................... 161

8.4.4 Off-screen 이미지 만들기 ........................................................................... 161

8.4.5 이미지 인코딩(Encoding)............................................................................. 161

8.4.6 “Hello World” 이미지 생성하기.................................................................... 162

8.5 Connection Pooling의 사용 .............................................................................. 163

8.6 Servlet에서의 쓰레드(Thread)........................................................................... 165

8.7 다른 servlet으로 요청 전달............................................................................... 166

8.8 필터(Filter) .......................................................................................................... 166

8.8.1 필터 생존 주기(Filter LifeCycle) .................................................................. 168

8.8.2 간단한 필터 예제......................................................................................... 169

8.9 이벤트 처리기(Event Listener) .......................................................................... 170


8.9.1 간단한 이벤트 처리기 예제 ........................................................................ 172

9 JSP의 개요 ............................................................................. 174

9.1 JSP란? ................................................................................................................ 174

9.2 JSP는 어떻게 동작하는가?................................................................................ 174

9.2.1 JSP의 동작 개요 ......................................................................................... 174

9.2.2 버퍼 출력 기능(Buffered Output) ................................................................ 176

9.2.3 세션(session) 관리....................................................................................... 178

10 JSP의 구현 ........................................................................ 180

10.1 JSP Reference ................................................................................................... 180

10.1.1 JSP tags ....................................................................................................... 180

10.1.2 내부 객체들(예약어)..................................................................................... 181

10.1.3 지시자(Directives)......................................................................................... 184

10.1.4 선언문(Declaration) ...................................................................................... 184

10.1.5 표현식(Expression) ...................................................................................... 185

10.1.6 액션(Action) .................................................................................................. 186

10.2 자바빈즈(JavaBeans)의 사용 ............................................................................ 189

10.2.1 자바빈즈의 개요........................................................................................... 190

10.2.2 자바빈즈 객체의 생성 ................................................................................. 190

10.2.3 자바빈즈 객체의 사용 ................................................................................. 191

10.2.4 자바빈즈의 scope ........................................................................................ 191

10.2.5 자바빈즈의 구현........................................................................................... 192

10.3 Custom tag의 사용 ............................................................................................ 197

10.3.1 Custom tag library ........................................................................................ 198

10.3.2 Custom tag의 구현에 필요한 API들 ........................................................... 203


10.3.3 Tag의 상호작용(Interacting)......................................................................... 211

10.3.4 간단한 Custom tag 만들기 .......................................................................... 212

10.4 에러 처리............................................................................................................. 214

10.4.1 파싱 에러(JSP parsing error) ....................................................................... 215

10.4.2 컴파일 에러(Compilation errors).................................................................. 215

10.4.3 런타임 에러(Run-time errors) ...................................................................... 215


1 WebtoB Web Container 시작하기

여기서는 WebtoB 와 WebtoB Servlet Engine 을 처음 연동하는 사람을 위

해 WebtoB Servlet Engine 를 설치한 뒤에 Web Container 를 실행하고 설

치 시에 제공되는 기본 Application 들을 실행해 본다.

1.1 Web Container 의 구동과 종료

Web Container 를 구동 시키는 방법은 admin 이라는 콘솔 툴을 이용하는 것이다. 먼저 WebtoB 가 구동이 되어야 WebtoB Servlet Engine 도 구동 될 수 있다.

여기서 WebtoB Servlet Engine 서버라는 것은 WebtoB Web Container 들을 구동 시켜주고 관리 시켜주며 네이밍 서비스, fault-tolerance 등을 관리

해 주는 역할을 한다. 이 WebtoB Servlet Engine 의 개념은 WebtoB Web Container 에 똑같이 적용되었다.


1.1.1 콘솔툴(admin)을 이용한 Container 실행

가장 먼저 WebtoB Servlet Engine 서버를 실행시킨다. bin 디렉토리 아래 라는 실행파일을 실행시킨다. 실행이 성공하면 다음과 같은 메시지가 출력된다. 만약 WebtoB 와 WebtoB Servlet Engine 을 같이 설치하는 경우 WebtoB Servlet Engine 의 default 설치 경로는 $WEBTOBDIR/jeus 이다.

C:\webtob\jeus\bin>jeus

[ErrorMsgManager] Message Manager is initialized

[2001.10.02 14:45:57] [LocalSecurityService] Loading File Realm

from C:\webtob\jeus\config\webdev\file_realm.xml

[2001.10.02 14:45:57] [LocalSecurityService] JEUS Security Realm

Initialized

[2001.10.02 14:45:57] [JRSMAcceptThread] Exported at port 9837

[2001.10.02 14:45:57] [JeusServer] JeusServer is Ready

그리고 나서 Web Container 를 구동하기 위해서는 같은 디렉토리에 있는 jeusadmin 이라는 실행파일을 다음과 같은 인수를 사용하여 실행시킨다.

C:\webtob\jeus\bin>jeusadmin webdev

[ErrorMsgManager] Message Manager is initialized

[JeusCommander] Jeus 3.0 Jeus Manager Controller

[JeusCommander] Login

>

위의 명령어에서 jeusadmin 이 실제 구동하는 명령어이고, node name 은 WebtoB Servlet Engine 이 설치되어 JeusMain.xml 에 기입된 Machine 의 이름을 말한다. 우선 로그인 과정을 거쳐서 실제 사용자임을 인증받아야 하는데 실제 사용자임이 인증되면 다음과 같이 명령을 수행할 수 있는 상태가 된다.

[JeusCommander] [administrator] login successful

webdev>boot

[JeusCommander] webdev boot done

webdev_container1

여기서 인수들은 다음과 같은 의미이다.

webdev : 노드 이름

boot : 명령의 종류 (부트)

종료시키는 명령은 다음과 같다.

webdev>down

Note : WebtoB Web Container 에서 jeus, jeusadmin 과 같은 실행파일에 설정되어 있는 중요한 환경변수들을 보여준다.

W2B_JEUSHOME : WebtoB Web Container 가 설치된 디렉토리

예) W2B_JEUSHOME = /usr/local/webtob/jeus

W2B_SERVLETHOME : Web Application(서블릿이나 JSP, HTML, 이미지 파일들 등)이 위치할 경로


W2B_S_BASEPORT : WebtoB Web Container 가 사용할 Port 의 시 작 번 호 . WebtoB Servlet Engine 들은 W2B_S_BASEPORT 로부터 Port 번호를 채번해서 사용하게 된다.

1.2 Example 실행

WebtoB Servlet Engine 를 처음 설치하고 나면 Examples 라는 컨텍스트가 설치된다. 이 Examples 라는 컨텍스트 안에는 servlet API 들을 이용해서 작성한 예제 servlet 들이 있다. 또한 jsp 디렉토리 아래에는 JSP 예제들이 있다. 이 예제들은 어떤 API 들이 있고 어떻게 사용하는지 잘 나와 있다. 또한 JSP 문서를 작성할 때 어떤 식으로 작성하고 JavaBeans 나 custom tag 를 어떻게 써야 되는지에 대한 예가 나와 있다.

이 컨 텍 스 트 의 실 제 path 는 WebtoB Servlet Engine 디 렉 토 리 의 /webhome/ servlet_home/webapps/examples 안에 있다.


1.2.1 Servlet 예제

examples context는 context만 URL에 포함시키면 Container에서 띄워주는 welcome file을 가지고 있다. 그래서 WebtoB Servlet Engine를 실행시키고 브라우저에서 http://localhost:8080/examples를 치면 다음과 같은 화면이 나온다. 이때 8080 은 WebtoB 포트 번호이다.

그림 1-2 servlet 예제 화면

이 링크들을 클릭하면 각각에 연결되어 있는 servlet 들이 실행되어 브라우저에 결과를 출력해 준다. 각각의 servlet 들을 살펴 보면 다음과 같다.

ServletContext and ServletConfig APIs : 이 servlet 은 ServletContext 객체와 ServletConfig 객체의 API 들을 이용하여 알아낼 수 있는 정보들을 화면에 출력한다. 여기에는 주로 설정된 초기화 매개 변수들과 컨텍스트에 관련된 변수들의 값들이 해당된다.

Request information APIs : 이 servlet 은 request 객체로부터 알

아낼 수 있는 정보들을 화면에 출력한다.

Request Header Info APIs : 이 servlet 은 들어온 요청의 헤더에 포함된 정보를 화면에 출력한다.

Session APIs : 이 servlet 은 HttpSession 객체의 정보들과 이 객체를 사용하는 예제를 담고 있다. 이 예제는 session 에 특정한 문자열을 저장하고 다시 불러올 수 있게 구현되어 있다.

Cookie APIs : 이 servlet 은 브라우저에서 오는 cookie 에 담긴 정보들을 화면에 표시한다. 그리고 cookie 에 어떤 정보를 넣고 읽어들일 수 있게 만들어져 있다.

Forward Test 1 : 이 servlet 은 RequestDispatcher() 메소드를 이용

해서 다른 servlet 에 요청을 넘기는 것을 보여 준다.

Forward Test 2 : 이 servlet 은 NamedDispatcher() 메소드를 통해 다른 servlet 에 요청을 넘기는 것을 보여 준다.

Include Test 1 : 이 servlet 은 RequestDispatcher() 메소드를 이용해서 다른 servlet 의 출력을 현재의 servlet 의 출력에 포함시키는 것을 보여 준다.

Include Test 2 : 이 servlet 은 NamedDispatcher() 메소드를 통해 다른 servlet 의 출력을 현재의 servlet 의 출력에 포함시키는 것을 보여 준다.

이 servlet들의 소스 코드는 examples 디렉토리의 WEB-INF 안에서 찾아볼 수 있다. 그리고 이 소스 코드에서 사용한 API들은 http://java.sun.com/ 의 servlet 페이지에서 API document 들을 통해 자세한 설명과 사용법을 알 수 있을 것이다.


1.2.2 JSP 예제

examples context에는 JSP 문서의 예제도 포함되어 있는데, 이 예제들은 jsp 디렉토리 아래에 있다. 따라서 이 예제들의 index 페이지를 열려면

WebtoB Servlet Engine을 실행시키고 브라우저에서 http://localhost:8080/examples/jsp를 치면 index 페이지가 열린다. 이 각각의 예제에 대한 설명은 다음과 같다.

Directives & Basic JSP tags Test : 이 JSP 문서는 JSP 의 지시자

(directive)들과 기본적인 JSP tag 들을 test 한 것이다.

Request Information Test : 이 JSP 문서는 request 객체에서 여러 가지 요청 정보를 JSP 문서에서 얻는 과정을 보여 준다.

Error Page Test : 이 JSP 문서는 page directive 의 errorpage 속성

을 이용하는 것을 보여 준다. 세가지 과일 중에서 orange 외에 다른 것들을 선택하게 되면 연결되는 JSP 문서에서 null pointer exception 이 발생하게 되어서 지정된 error page 로 자동으로 forwarding 된다.

Query Information Test : 이 JSP 문서는 HTML 문서의 checkbox 의 결과를 어떻게 JSP 문서에서 이용할 수 있는지에 대해 나타나 있다. 즉, 맨 처음 페이지에서 check 한 항목들이 다음 페이지에서 request 를 분석해서 다시 표시하는 것이다. 이때 request 객체를 직접 액세스하는 것과 request 를 JavaBeans 와 연관해서 액세스 하는 방법 두 가지를 모두 사용하고 있다.

Include Page Test : 이 JSP 문서는 include directive 와 include action tag 를 사용하는 예를 보여 준다.

Forward Page Test : 이 JSP 문서는 forward action tag 를 사용하는 예를 보여 준다. 먼저 처음 요청 받는 JSP 문서에서는 가상 메모리의 전체 용량과 남아있는 용량을 비교해서 남아 있는 용량이 50% 이상인가 이하인가에 따라 각각 다른 문서로 forwarding 하는 것이다.

Plugin Test : 이 JSP 문서는 JSP 문서 내에서 applet 을 사용할 수 있게 하는 plugin action tag 를 사용하는 예를 보여준다. 이 문서에 포함되어 있는 applet 은 원과 삼각형, 사각형을 그리고 지울 수 있는 간단한 applet 이다.


JavaBeans Test : 이 JSP 문서는 간단한 JavaBeans 를 이용하는 것을 보여 준다. StatBean 이라는 평균을 구해주는 빈을 통해 주어진 값들의 평균을 계산해 준다.

JavaBeans Test – session scope : 이 JSP 문서는 JavaBeans 를 session scope 로 지정해서 간단한 쇼핑백을 구현한 것이다. 다른 페이지를 보고 있다가 다시 돌아와도 예전에 넣어 두었던 물건들이 그대로 있음을 볼 수 있다.


Custom tag Test : 이 JSP 문서는 간단한 custom tag 를 사용하는 예를 보여준다. 여기서 사용한 tag 는 text 를 HTML code 로 인코딩하는 tag 이다.

2 Container 의 이해

여기서는 WebtoB Web Container 에 대한 전반적인 설명을 한다. 따라서 처음 WebtoB Web Container 를 사용하는 사람이 빠른 시간 내에 WebtoB Web Container 의 구성을 이해할 수 있게 되어 있다.

2.1 Web Application 이란?

“Web Application”이란 말은 Java Servlet Specification 2.3 에서 정의된 것으로 online Application 의 각종 interface 를 만드는 server 쪽의 자원들의 모임을 말한다. 즉, 간단히 말해서 여러 가지 자원들을 이용해서 client 의 요청에 응답하는 server 에서 운영되는 일종의 프로그램이라고 할 수 있다. 이 자원들에는 다음과 같은 것들이 포함된다.

Servlets

JavaServer Pages

HTML pages

Server side classes

특정한 Web Application 에 포함되는 여러 가지 자원들


이 specification 에서는 이런 자원들이 옮기기 좋은 “Web Application archive”(WAR) 파일로 어떻게 묶는지 정해 놓아서 이 war 파일들이 WAR 표준을 지원하는 Application server 에 설치(deployment)될 수 있다. 하나의 Web Application 은 server 에서 돌아가는 다른 Web Application 과 분리된 환경인 servlet context 안에서 운영된다. 각각의 Web Application은 자신 안의 자원들을 묶어주고 WebtoB Servlet Engine 에 어떻게 설치

되었는지를 나타내 주는 deployment descriptor 를 가지고 있다.

J2EE specification 에서는 Web Application 이 어떻게 EJB 같은 다른 server 쪽의 자원들과 작용하는지를 정의하고 있어서 전체적인 J2EE specification 을 따르는 Application 을 구성할 수 있다.

Servlet 과 JSP 에 대해 더 자세히 알고 싶다면 Ⅶ장 Servlet 의 개요와 Ⅸ장 JSP 의 개요를 참고하기 바란다.


2.2 Container 의 구성

J2EE specification 에서는 servlet 과 JSP 를 같은 단위로 취급한다. 이는 JSP 문서를 결국에는 servlet 으로 변환해서 실행하기 때문이다. 그리고 컨텍스트(context)라는 단위를 두어 여러 개의 servlet 과 JSP 문서를 한 단위로 취급한다. 이 context 단위의 servlet 과 JSP 문서에서는 ServletContext 객체(JSP 에서는 Application 내부 객체)를 공유한다. 그리고 session 을 사용하는 servlet 이나 JSP 문서들은 HttpSession 객체(JSP 에서는 session 내부 객체)를 공유한다. 이때 context 단위는 물리적으로 어떤 하나의 디렉토리 아래의 모든 servlet 과 JSP 문서에 해당된다. 이 디렉토리는 container.xml 에서 정하게 되어 있다.

이러한 컨텍스트 단위를 J2EE 에서는 Web Application 이라고 한다. 이 Application 은 독립적으로 자체 내의 설정 파일을 가지고 있다. 이 파일이 바로 web.xml 이다. 여기에는 여러가지 Application 의 설정을 할 수 있는데, 자세한 내용은 Ⅵ장 Web Application 의 개발에서 다루고 있다.

WebtoB Web Container 에서는 하나의 더 큰 단위를 두고 있다. 이는 ContextGroup 이라는 단위로 여러 개의 context 를 하나의 ContextGroup 으로 묶을 수 있다. ContextGroup 내의 context 들은 여러 가지 Web Container 설정을 공유하게 되는데, 문자 집합(character set)이나 logging 에 관한 설정, 다른 웹 서버와의 연동이나 session clustering 의 설정 등을 예로 들 수 있다. 이 외에 ContextGroup 안에 있는 context 들은 설정에 따라서 HttpSession 객체를 공유할 수도 있다.

각각의 ContextGroup 은 다른 ContextGroup 과 공유 하지 않는 전용의 웹 서버를 설정하여 가지고 있다. 각 웹 서버 설정에는 client request 를 받아 처리하는 worker thread pool 설정을 가지고 있다. 이에 관한 자세한 내용은 IV 장을 참조하기 바란다.

지금까지 설명한 것을 정리하면 J2EE specification 에 있는 context 외에 WebtoB Servlet Engine 에는 ContextGroup 이라는 단위를 더 두어서 이 단위를 중심으로 Container 와 Web Application 사이의 설정을 한다. 또

한 context 단위로 Container 의 설정도 할 수 있는데 이러한 설정들은 모 두 container.xml 에 서 이 루 어 진 다 . WebtoB Web Container 에 ContextGroup 이 여러 개 있을 수 있다. 사실 ContextGroup 단위로 Container 의 설정이나 웹서버와의 연결 등 대부분의 설정이 다르게

지정될 수 있으므로 ContextGroup 이 다르면 다른 Web Container 에서 실행되고 있는 것과 같은 효과를 내게 된다. 지금까지 알아본 Container 의 구성을 그림으로 나타내면 다음과 같다.

그림 2-1 Container 의 구성화면

2.3 WebtoB Servlet Engine 의 디렉토리 구조

WebtoB Servlet Engine 설치되어 만들어진 디렉토리 구조는 WebtoB Servlet Engine 의 디렉토리와 다음과 같이 차이가 있다. (아래에서 이탤릭체와 밑줄이 그어진 디렉토리들이 개발자와 관리자들이 직접 사용하는 디렉토리가 된다)

${W2B_JEUSHOME} : WebtoB Servlet Engine 이 설치된 디렉토리를 가리

킨다.

bin : WebtoB Servlet Engine 실행파일들

classes : WebtoB Servlet Engine 클래스 파일들


config : 설정파일들

dtds : XML descriptor 파일들

nodename : 해당 노드의 설정파일들

lib : WebtoB Servlet Engine 에서 사용하는 라이브러리 파일들

system : WebtoB Servlet Engine Container 들이 사용하는 라이

브러리 파일들

datasource : 데이터베이스 연결과 관련된 라이브러리 파일들 (예. 데이터베이스 드라이버)

Application : Application에서 사용하는 라이브러리들 (모든 Container에 적용)

logs : 로그 파일들

container_name : 해당 Container 의 로그 파일들

webhome : Application 디렉토리

servlet_home : servlet, JSP Application 디렉토리

workspace : WebtoB Web Container 가 내부적으로 사용하는 working 디렉토리

위의 디렉토리 구조에서 Web Container 와 관련된 디렉토리의 상세한 설명은 다음과 같다.

bin 디렉토리 : WebtoB Web Container 의 실행과 관련된 파일들은 다음과 같다.

jeus : WebtoB Servlet Engine 서버를 실행시키는 것으로 jeusadmin 을 사용하여 Container 를 실행시킬 때 먼저 실행해야 한다.

jeusadmin : WebtoB Servlet Engine 서버를 실행환경에서 GUI 툴을 사용하지 않고 터미널에서 Container 를 실행할 때 사용한다.

webadmin : Web Container 를 명령모드에서 관리한다.


config 디렉토리 : WebtoB Servlet Engine 에서는 설정파일 들을 노드별로 관리를 한다. config 디렉토리 아래에는 노드이름과 같은 디렉토리가 있는데 여기에 해당 노드의

모든 Container 들의 설정 파일들이 위치한다. 각 Container 들의 설정 파일들은 Container 들의 이름으로 된 디렉토리 아래에 놓인다.

Note: 예를 들어 디렉토리와 Container 가 다음과 같은 상황이라고 하자.

W2B_JEUSHOME : c:\webtob\jeus

노드 이름 : webdev

노 드 에 존 재 하 는 Container 들 : Web Container : webdev_servlet_engine1, ebdev_servlet_engine2. 이 때 각 Container별로 설정파일의 위치는 다음과 같다.

webdev_servlet_engine1

c:\webtob\jeus\config\webdev\webdev_servlet_engine1\

webdev_servlet_engine2

c:\webtob\jeus\config\webdev\webdev_servlet_engine2\

각 Web Container 의 설정파일 디렉토리에는 디폴트로 다음과 같은 세 개의 설정파일이 있다. 모두 XML 형식이며 해당하는 디스크립터 파일은 config 아래 dtds 라는 디렉토리에 있다.

container.xml : Web Container 관련된 모든 설정을 담당하고 있는 가장 중요한 설정파일이며 반드시 Web Container 별로 하나 존재해야 한다. dtd 파일은 web-container_3_0.dtd 이다. (뒤 숫자부분은 버전으로 3.0 을 의미한다)

webcommon.xml : 모든 컨텍스트(일종의 작업단위)는 각각 web.xml 이라는 설정파일을 가지고 있는데 이 설정파일 들에서 공통된 사항들이 있을 때 webcommon.xml 에 설정하면 각 web.xml 에서는 다시 설정할 필요 없이 모든 컨텍스트에 적용된다. 이 파일은 썬의 servlet 스펙에 기술된 사항은 아니며 필요 없으면 설정하지 않아도 된다. 만약 이 파일에 설정된 내용이 다시 컨텍스트의 web.xml 에 설정되어 있을 때는 web.xml 의 것을 우선한다. dtd 파일은 web.xml 의 dtd 파일과 동일한 web-app_2_3.dtd 이다.


Note : 보통 mime-mapping, welcome-file-list, session-timeout, error-page 등

의 설정은 모든 컨텍스트에서 동일하다 . 따라서 이런 것들은 webcommon.xml 에 한번만 설정하면 작업을 줄일 수 있다.

web.xml : 모든 context 들은 자신만의 web.xml 을 가지고 있다. 만약 context 가 자신의 web.xml 을 가지고 있지 않다면 이 web.xml 을 자신의 web.xml 로 간주한다. 또, 각 ContextGroup 의 DefaultContext (Web Container 기동시 자동 생성되는 내장 context)의 web.xml 로 사용된다. dtd 파일은 web-app_2_3.dtd 이다.

lib 디렉토리 : WebtoB Web Container 들이 사용하는 라이브러리 파일들을 가지고 있는 디렉토리이다. 모든 context 들의 classloader 및 jsp 파일로부터 class 파일을 생성할 때 필요한 자바 컴파일러의 classpath 옵션에 이 디렉토리에 있는 모든 라이브러리들이 포함된다. 라이브러리의 형태는 jar 나 zip 형태의 아카이브 파일 또는 디렉토리 형태도 가능하다. 디렉토리 형태인 경우 그 하위 디렉토리는 포함하지 않는다. 이 디렉토리는 세 가지 하위 디렉토리로 구성된다.

system : WebtoB Web Container 가 내부적으로 사용하는 시스템 라이브러리들을 담고 있다.

datasource : 데이터베이스와 관련된 라이브러리들을 담고 있는 것으로 보통 데이터베이스 드라이버 등이 여기에 속한다.

Application : Application 에서 사용하는 라이브러리들을 가지고 있다. 사용자가 작성한 라이브러리를 이 디렉토리에 넣을 수 있다.

여기에 있는 라이브러리들은 Web Container 의 모든 컨텍스트에서 적용된다. 반면 특정한 컨텍스트에서만 사용하는 라이브러리가 있을 때는 이 디렉토리에 두지 않고 컨텍스트의 DocBase 디렉토리 아래 WEB-INF/lib 이라는 디렉토리에 두면 다른 컨텍스트에서는 이 라이브러리를 사용할 수 없게 된다.

logs 디렉토리 : 로그파일 들을 저장하는 디렉토리로 Container 의 이름으로 디렉토리가 생기고 로그 파일들이 저장된다. 예를 들어 webdev_servlet_engine1 이라는 Web Container 의 로그 파일들은 다음과 같은 디렉토리에 저장된다. Web Container 의 경우, 이 디렉토리 아래 ContextGroup 이름으로 또 하나의 하위 디렉토리가 생기고 그 아래 로그파일 들이 저장된다.


%W2B_JEUSHOME%\logs\webdev_servlet_engine1

webhome 디렉토리 : 설치시 디폴트로 Application 이 놓이는 디렉토리로서 그 아래 servlet_home 디렉토리가 있다. 여기서 Web Container 에서 사용할 Application 들은 그 아래 servlet_home 이라는 디렉토리에 위치한다. 이 디렉토리의 변경은 WebtoB Servlet Engine 설치시 설정되는 W2B_SERVLETHOME 이라는 환경변수를 변경함으로써 강제로 변경할 수 있다.


2.4 Application 의 구성

Web Container 에서 실행이 되는 Application 을 Web Application 이라 한

다. 이러한 Web Application 을 구성하고 있는 것으로는 servlet, JSP, HTML 파일, 이미지 파일, 기타 클래스들 등이다.

Servlet specification 2.3 이후로 관련된 일을 하는 servlet, JSP 와 그와 관련된 자원들을 하나로 묶어 Web Application 을 구성하고 Container 에서는 하나의 컨텍스트를 할당해서 운영하도록 되어 있다. WebtoB Web Container 는 servlet specification 2.3 을 준수하여 모든 Application 과 자원들을 context 단위로 관리를 한다.

그리고 WebtoB Web Container 에서는 이러한 컨텍스트들을 하나로 묶어 주는 컨텍스트 그룹이라는 것을 두어 관리한다. 하나의 Web Container 는 하나 이상의 컨텍스트 그룹을 가질 수 있으며 이런 컨텍스트 그룹은 하나의 가상서버로 간주할 수 있다. 이러한 구조를 그림으로 보면 다음과 같다.

그림 2-2 Container 의 구조화면

2.4.1 Container 에서의 Application 디렉토리 설정

실제 Web Application 이 위치하는 디렉토리와 그 구조는 다음과 같다. 우선 중요한 세 가지 Base 디렉토리를 설정하여야 한다.

W2B_SERVLETHOME : 모든 Web Application 이 있는 가장 상위의 디렉토리 경로. WebtoB Servlet Engine 설치시에 환경변수로 등록하도록 되어있다. 그러나 W2B_SERVLETHOME 은 container.xml 에 의해서도 원하는 위치로 수정할 수 있는데 그것은 ContextGroup 태그에서 값을 설정하면 된다.

예 를 들 어 W2B_SERVLETHOME 을 c:/webtob/jeus/webhome/servlet_home 으로 지정하려 하면 다음과 같이 container.xml 의 ContextGroup 태그에 설정하면 된다.

ServletHome=” c:/webtob/jeus/webhome/servlet_home”

컨텍스트 그룹의 Base 디렉토리 : 컨텍스트 그룹의 모든 Application 과 자원들이 놓이게 될 디렉토리로서 그룹내의 모든 컨텍스트는 이 디렉토리의 아래에 놓이게 된다. 이것은 W2B_SERVLETHOME 과 container.xml 의 ContextGroup 태그에서 GroupDocBase 속성값에 의해 결정된다.

(컨텍스트 그룹의 Base 디렉토리 = W2B_SERVLETHOME+ GroupDocBase)

예 를 들 어 W2B_SERVLETHOME 이 c:/webtob/jeus/webhome/servlet_home 이고 ContextGroup 태그에서 GroupDocBase 속성값을 webapps 라고 설정하면 컨텍스트 그룹

의 Base 디렉토리는 다음과 같다.

컨텍스트 그룹의 Base 디렉토리 =

c:/webtob/jeus/webhome/servlet_home/webapps


컨텍스트의 Base 디렉토리 : 컨텍스트의 Application 과 자원들이 놓이게 되는 디렉토리로서 컨텍스트 그룹의 GroupDocBase 디렉토리 아래에 위치한다. 이것은 컨텍스트 그룹의 Base 디렉토리와 container.xml 의 Context 태그에서 DocBase 속성값에 의해 결정된다.

컨텍스트의 Base 디렉토리 = 컨텍스트 그룹의 GroupDoc Base 디렉토리

+ DocBase

예를 들어, 컨텍스트 그룹의 Base 디렉토리가 c:/webtob/jeus/webhome/servlet_home/webapps 이고 Context 태그에서 DocBase 속성값을 examples 라고 설정하였다면 컨텍스트의 Base 디렉토리는 다음과 같다.

컨텍스트의 Base 디렉토리 =

c:/webtob/jeus/webhome/servlet_home/webapps/examples

지금까지 살펴본 디렉토리 구조를 정리해 보면 다음 그림과 같다. 다음의 디렉토리는 실제 Application 이 있는 디렉토리를 절대 경로로 나타낸 것이다.

c:/webtob/jeus/webhome/servlet_home/webapps/examples

SERVLET_HOME

컨텍스트 그룹의 GroupDocBase 디렉토리

2.4.2 컨텍스트 내의 디렉토리

위의 세 가지 Base 디렉토리가 설정되어 있다면 컨텍스트의 Base 디렉토리 아래에는 실제 Application 과 자원들이 존재한다. 컨텍스트 Base 디렉토리 아래의 구조는 다음과 같다.

{컨텍스트 Base 디렉토리}

정적 자원들의 디렉토리들

JSP 파일들과 디렉토리들

WEB-INF : 어플리케이션들과 관련된 클래스 파일들


classes : servlet 파일들과 관련 클래스 파일들, 자바빈 파일들, filter 구현 클래스 파일들, listener 구현 클래스 파일들

Web Archive

Containerdirectories

WEB-INF

classes

Package directoies

tlds

JSP pagesHTML documents Image files

JSP pagesHTML documents Image files

web.xml

Class files

Class files

JAR files

TLD files

lib

그림 2-4 컨텍스트내의 디렉토리 화면

이 디렉토리들에 대한 자세한 설명은 다음과 같다. 더 자세한 설명은 Ⅵ장 Web Application 의 개발의 2.Web Application 작성의 WAR 파일의 내용 항목을 참조하기 바란다.


자원 디렉토리들 : HTML 파일, 이미지 파일, 스크립트 파일 등을 저장한다. 만약 웹브라우저에서 이러한 파일들을 가져 오게 하려면 다음과 같이 URL 을 설정하면 된다. 여기서 ContextPath 라는 것은 브라우저에서 컨텍스트의 Application 을 실행하거나 자원들을 가져 오려고 할 때 요청하는 경로로서 container.xml 의 Context 의 ContextPath 항목에서 지정한 경로이다.

URL = domain_name / ContextPath / 자원 디렉토리 이름 / 요청 파일

예를 들어 이미지 파일들을 images 라는 디렉토리에 저장하였다고 할 때 이 디렉토리의 home.gif 를 요청하기 위한 URL 은 다음과 같다.

( domain_name : www.foo.com, ContextPath : /examples 라고 가정)

http://www.foo.com/examples/images/home.gif

JSP 파일들과 디렉토리들 : JSP 파일들을 저장하는 디렉토리들로서 이 디렉토리 구조는 JSP의 실행과 관련하여 중요한 역할을 한다. 먼저 브라우저에서 JSP 문서를 요청할 때는 URI 경로로서 컨텍스트 Base 디렉토리 아래부터의 디렉토리 구조를 그대로 사용한다. 그리고 JSP 문서를 servlet 소스로 바꾸고 이를 컴파일해서 클래스 파일을 만드는 과정에서 생성되는 servlet 소스 파일과 클래스 파일의 이름과 패키지가 원래의 JSP 문서가 존재하는 디렉토리의 경로와 연관되어 있다. 물론 브라우저에서 요청하는 경로는 web.xml에서 <servlet-mapping>이라는 태그를 설정함으로써 바꾸어 줄 수 있다. 예를 들어 /examples 라는 디렉토리가 컨텍스트의 Base 디렉토리라고 할 때 그 아래 jsp/hello/hello.jsp라는 파일이 있다고 가정하자. 그리고 도메인 이름이 www.foo.com이라고 할 때 위의 JSP 파일을 실행하기 위해서는 다음과 같이 요청해야 한다.

http://www.foo.com/examples/jsp/hello/hello.jsp

또한 생성되는 servlet 소스 파일과 클래스 파일은 각각 다음과 같다(자세한 설명은 아래의 4.3 jspwork 디렉토리 설명을 참조하기 바란다).

_jsp302_hello_Impl.java

_jsp302_hello_Impl.class

WEB-INF : 개발된 모든 servlet, JSP 와 같은 Application 들과 그것들에서 사용하는 클래스 파일들이 있는 디렉토리이다. 여기에는 하위에 두 개의 디렉토리가 있는데 그것들은 다음과 같다.


classes 디렉토리 : servlet 클래스 파일들과 관련 클래스들, 자바 빈 등이 있다. 이 디렉토리는 java 의 classpath 항목에서 설정하지 않더라도 Container 내부적으로 classpath 에 등록하여 사용한다. 단 이 디렉토리는 단지 클래스 파일만 classpath 에 자동으로 등록이 되고 jar, zip 과 같이 클래스 파일들을 압축한 라이브러리 파일은 명시적으로 servlet 소스 등을 컴파일 하거나 JSP 문서에서 라이브러리를 사용할 때 classpath 를 지정해 주어야 사용할 수 있다. 그리고 만약 하위의 디렉토리에 servlet 을

두었다면 servlet 은 이 디렉토리의 이름을 패키지 이름으로 가져야 한다. 예를 들어 하위에 hello 라는 디렉토리가 있고 그 아래 HelloServlet.java 라는 servlet 소스 파일이 있을 때 이 servlet 은 다음과 같이 패키지 선언이 되어 있어야 한다. package hello; 만약 그 하위에 또 test 라는 디렉토리가 있고 그 아래 HellpServletTest.java 라는 servlet 소스 파일이 있을 때 이 servlet 은 다음과 같은 패키지 선언이 되어 있어야 한다. package hello.test;

lib 디렉토리 : 컨텍스트에서 사용하는 라이브러리 파일들을 저장하는 디렉토리로 여기에 포함되어 있는 파일들은 Container 가 내부적으로 자동으로 classpath 에 추가해 주므로 명시적으로 classpath 에 파일들을 추가하는 작업이 필요 없다. 여기 들어가는 라이브러리들은 jar 나 zip 과 같은 압축파일의 형태로 되어 있어야 한다. 또한 이런 압축파일의 형식 외에 이 압축 파일을 풀어 놓은 상태로도 사용 가능하다. 단 여기에 포함된 라이브러리들은 컨텍스트 내에서만 유효하게 되므로 다른 컨텍스트에서는 로드할 수 없다. 이것이 W2B_JEUSHOME(WebtoB Servlet Engine 이 설치된 디렉토리) 아래의 lib 디렉토리와의 차이점이다. 따라서 컨텍스트에 무관하게 적용되어야 하는 라이브러리인 경우 W2B_JEUSHOME 의 lib/Application 이라는 디렉토리에 추가시키면 된다.

2.4.3 jspwork 디렉토리

Web Container 가 JSP 페이지 서비스를 수행하려면 JSP 파일을 파싱하여 그 결과물인 java 파일과 class 파일을 특정 장소에 저장하여 동적 로딩을 할 수 있어야 한다. jspwork 디렉토리는 JSP 파일을 파싱한 결과물을 저장하는 디렉토리이다. 개발자 또는 관리자는 디버깅 목적을 제외하고는 특별히 이 디렉토리 밑의 파일들을 참조할 필요가 없다. 기본 설정을 이용하는 경우 JSP 파일을 파싱한 결과 파일들은 다음과 같은 디렉토리 구조 밑에 저장된다.

servlet_home/jspwork/engine_name/ctxgrp_docbase/ctx_docbase/pack

agename/


servlet_home : W2B_SERVLETHOME 환 경 변 수 나 container.xml 에서 <ServletHome> 태그로 지정된 디렉토리. 기본 설정의 경우 W2B_JEUSHOME 환경 변수에 의해 지정된

WebtoB Servlet Engine 설 치 디 렉 토 리 아 래 에 webhome/servlet_home 디렉토리이다.

jspwork : jspwork 디렉토리

engine_name : JeusMain.xml 에서 지정한 engine name 과 node name 의 조합된 이름의 디렉토리. 예를 들어 node name 이 webdev 이고 JeusMain.xml 에 이 Web Container 엔진의 이름을 engine1 이라고 지정하였다면 webdev_servlet_engine1 이

라는 이름의 디렉토리가 되겠다.

ctxgrp_docbase : 해당 context 가 속한 context group 의 group document base 이름. container.xml 의 <ContextGroup> 태

그의 GroupDocBase 속성으로 지정된 이름이다.

ctx_docbase : 해당 context 의 context document base 이름. container.xml 의 <Context> 태그에 DocBase 속성으로 지정된 이름이다.

packagename : 해당 jsp 파일을 파싱하여 생성할 java 파일에 지정된 package name 을 디렉토리 이름 형태로 바꾼 이름이다. 예를 들어 package name 이 pkg.myjsp 라면 pkg/myjsp 디렉토리가 되겠다.

한가지 주의 할 것은 jspwork 디렉토리의 위치가 ContextGroup document base 와 같기 때문에 ContextGroup document base 의 이름을 “jspwork”이라고 하면 관리하기가 불편하므로 ContextGroup document base 이름으로서 “jspwork”를 사용하지 말 것을 권장한다. 이 디렉토리에 저장될 java 및 class 파일의 이름 규칙은 다음과 같다.

_jsp + jeus jsp compiler version + _ + jsp 파일 이름 + _Impl.java

jeus jsp compiler version : 현재 버전 이름은 “30” 이다.

Jsp 파일 이름: jsp 파일 이름에서 확장자 “.jsp”를 제거한 이름


예를 하나 들면 다음과 같다.

- servlet_home : c:\webtob\jeus\webhome\servlet_home

- node 이름 : webdev

- JeusMain.xml 에서 지정한 engine 이름 : engine1

- context group document base : webapps

- context document base : examples

- jsp 파일 : pkg/myjsp/hello.jsp

- jeus jsp compiler version : 30

생성될 java 및 class 파일의 이름은 다음과 같다.

c:\webtob\jeus\webhome\servlet_home\jspwork\webdev_servlet_engin

e1\webapps\examples\pkg\myjsp\_jsp30_hello_Impl.java

c:\webtob\jeus\webhome\servlet_home\jspwork\webdev_servlet_engin

e1\webapps\examples\pkg\myjsp\_jsp30_hello_Impl.class


2.5 Container 의 설정 방법

WebtoB Servlet Engine 에서 Web Application 을 담당하는 Web Container는 주로 servlet 과 JSP 문서를 관리하고 실행하는 일을 한다. 따라서 개발자가 만든 Web Application 을 WebtoB Servlet Engine 에서 실행시키

려면 WebtoB Web Container 에 Web Application 을 등록하고 관리하는 과정이 필요하다. 이를 위해서는 WebtoB Web Container 의 구성이 어떻

게 되어 있고, 이 Container 를 어떻게 조절하는지를 알아야 한다. 그리

고 Container 를 직접 설정하는 container.xml 파일에 대한 이해도 필요

하다. 이 모든 구성들은 JEUS Web Container 와 동일하다.

따라서 Container 를 설정하기 위해서는 직접 WebtoB Servlet Engine 디

렉토리 아래의 config/(nodename)/(nodename)_servlet_(엔진이름) 디렉토

리에 있는 container.xml 을 에디터로 수정해야 한다.

3 Container 의 설정

WebtoB Web Cotnainer 를 관리하는 것은 Container 의 설정들을 조절해서 최적의 성능을 낼 수 있도록 하는 것이다. 여기서는 Container 에서 설정할 수 있는 항목들을 소개하고 간단한 설정법을 소개하고 있다.

이를 위해 먼저 Container 가 어떻게 구성되어 있는지를 알아보고, 이 구성에 대한 각각의 항목들을 살펴보기로 한다.

여기에서는 대부분 각각의 설정 항목에 대해서 container.xml 을 어떻게 수정해야 하는가에 대해 다루고 있다. 따라서 container.xml 의 태그에 대한 자세한 정보는 Ⅳ장 Container.xml Reference 를 참조하기 바란다.

3.1 Application 의 배치와 실행

여기서는 실제 예를 들어 Application 을 배치하고 실행하는 전체과정에 대해서 설명한다. 이를 위해 Container 에서의 Application 의 구성에 대해서 먼저 알아보자. 여기서 설명하고 있는 container.xml 의 <ContextGroup> 이나 <Context> 태그에 대한 자세한 설명은 5 장 Container.xml Reference 를 참조하기 바란다.

여기서 예를 들고 있는 것은 WebtoB Servlet Engine 을 설치하였을 때 기본적으로 들어가 있는 MyGroup 이라는 컨텍스트 그룹의 examples 라는 컨텍스트이다. 예에서는 다음과 같이 Base 디렉토리들에 대한 가정을 한다.

컨텍스트의 Base 디렉토리 : c:\webtob\jeus \webhome\servlet_home

컨텍스트 그룹의 GroupDocBase : webapps

컨텍스트의 DocBase : examples


따 라 서 컨 텍 스 트 의 Base 디 렉 토 리 는 c:\webtob\jeus \webhome\servlet\webapps\examples 가 되고 이 아래의 파일들과 하위 디

렉토리는 다음과 같다.

index.html

images : 이미지 파일들의 디렉토리

jsp : JSP 파일들의 디렉토리

WEB-INF : Application 들의 디렉토리

web.xml : Container 설정 XML 파일

web.conf : Container 설정 serialized object 파일

classes : servlet 과 자바빈들의 디렉토리

다음은 위와 같이 컨텍스트의 Application 과 자원들이 배치되어 있을 때 필요한 설정파일을 어떻게 설정하는지 알아보자.

container.xml 에서 <ContextGroup> 태그 설정 : 우선 컨텍스트 그룹과 관련된 사항들을 <ContextGroup> 태그에 설정한다.

<ContextGroup GroupName=”MyGroup”

GroupDocBase=”webapps”

….>

컨텍스트 그룹의 이름은 MyGroup 로, 컨텍스트 그룹의 Document base 는 webapps 라고 설정하였다.

container.xml 에서 <Context> 태그 설정 : 컨텍스트와 관련된 사항들은 <Context> 태그에 설정한다.


<Context ContextName="examples"

ContextPath="/examples"

DocBase="examples"

AutoReload="false"/>

여기서 컨텍스트의 이름(ContextName 속성)은 내부적으로 각 컨텍스트를 구분하는데 사용하고 컨텍스트 패스(ContextPath 속성)는 클라이언트에서 해당 컨텍스트를 요청하기 위한 패스가 된다. 컨텍스트 Document base(DocBase 속성)는 examples 로 컨텍스트의 기본이 되는 디렉토리 이름이며 EnableJSP 는 Web Container 내의 JSP 엔진을 사용할지 여부로서 현재 사용하는 것으로 설정되어 있고 AutoReload 는 servlet 이나 자바빈이 변경이 되었을 때 자동으로 새로운 클래스를 로딩할 것인지를 설정하는데 여기서는 false 로 되어 자동으로 로딩되지 않는다.

컨텍스트의 설정을 위해 web.xml 작성 : container.xml 에서의 컨

텍스트 설정은 servlet specification 에서 정해진 표준이 아니라, 특정 Web Application 을 WebtoB Servlet Engine 시스템에 배치할 때 필요한 WebtoB Servlet Engine 만의 설정이다. 반면 web.xml은 servlet specification 에서 정해진 Web Application(context) 설정 표준이다 . 이에 대한 자세한 사항은 7 장 Web Application 의 개발을 참조하기 바란다. 위 디렉토리들에서 servlet, JSP 를 각각 하나씩 예를 들어 web.xml 에 등록하는 방법을 알아보자.

servlet : servlet 은 ServletContextTest 로 WEB-INF/classes 디렉

토리 아래에 있으며 web.xml 에 이 servlet 에 관한 설정이 다음과 같다고 하자.

<servlet>

<servlet-name>ServletContextTest</servlet-name>

<servlet-class>ServletContextTest</servlet-class>

</servlet>

<servlet-mapping>


<url-pattern>/context</url-pattern>

</servlet-mapping>

<servlet-name>은 web.xml 내에서 각 servlet 을 구별하기 위한 이름이고 <servlet-class>는 servlet 클래스의 이름이다. 이 때 완전한 패키지 이름과 함께 설정해 주어야 한다. <servlet-mapping>은 이 servlet 을 요청하기 위해서 URL 에 어떻게 표기해야 할 지를 지정한다. <servlet-mapping>이 설정이 되어 있지 않더라도 servlet 이름으로 요청하면 그 servlet 이 실행된다. 자세한 설명은 7 장 Web Application 의 개발을 참조하기 바란다. 위와 같이 설정하였을 때 클라이언트로부터 요청은 다음과 같이 할 수 있다.

http://www.foo.com/examples/context : web.xml에서 servlet-mapping에 의해

http://www.foo.com/examples/ServletContextTest : 디폴트

JSP : JSP 파일로는 hello.jsp 로서 jsp/hello 아래에 있다. 우선 web.xml 에 다음과 같이 설정하였다고 가정하자.


<servlet>

<servlet-name>HelloJsp </servlet-name>

<jsp-file>/jsp/hello/hello.jsp</jsp-file>

</servlet>

<servlet-mapping>

<servlet-name>HelloJsp</servlet-name>

<url-pattern>/hello</url-pattern>

</servlet-mapping>

servlet 의 설정과 다른 부분은 단지 <servlet-class> 태그 대신 <jsp-file> 태그를 사용하는 것이다. 이 태그는 컨텍스트의 Base 디렉토리로부터 JSP 파일이 위치한 경로를 설정해 주면 된다. 단 시작은 “/”로 하여야 한다. <servlet-mapping>에 의해서 JSP 파일을 요청할 수도 있지만 만약 JSP 설정을 하지 않았다면 디폴트로 <jsp-file> 태그에 설정된 것과 같이 컨텍스트의 Base 디렉토리로부터 JSP 파일이 위치한 경로를 요청하면 된다. 위와 같이 설정하였을 때 클라이언트로부터 요청은 다음과 같이 할 수 있다.

http://www.foo.com/examples/hello: web.xml에서 servlet-mapping에 의해

http://www.foo.com/examples/jsp/hello/hello.jsp: 디폴트


3.2 Session 의 설정

기본적으로 specification 에서 session 은 각 Web Application 의 단위인 컨텍스트 단위로 관리된다 . 따라서 session 에 대한 설정은 각각의 Application 의 설정 파일인 web.xml 에서 설정한다.

하지만, WebtoB Web Container 에서는 컨텍스트 그룹 내의 컨텍스트 간의 세션 공유를 지원한다. 따라서 container.xml 에서 컨텍스트 그룹 내의 세션 공유를 지정하면 web.xml 의 설정은 무시되고 container.xml 의 설정이 유효해진다.

또한 여러 Web Container 간의 세션 클러스터링을 설정하게 되면 컨텍스트 그룹에서 세션 공유를 설정하지 않았어도 자동으로 컨텍스트 그룹 내의 세션 공유가 활성화 된다. 이는 세션 클러스터링이 컨텍스트 그룹간에 이루어지기 때문이다.

3.2.1 Application 단위의 session 설정

web.xml 의 <session-config>는 Application 의 servlet 과 JSP 페이지에서 생성된 세션의 디폴트 타임 아웃 값을 설정할 때 사용한다. 이 태그 안에는<session-timeout> 태그가 필수로 들어가야 하며, 이 태그의 몸체에 분 단위로 세션 타임 아웃 값이 들어간다. 이 경우의 예는 다음과 같다.

<web-app>

…

<session-config>

<session-timeout>30</session-timeout>

</session-config>

</web-app>

이 경우의 타임 아웃 값은 30 분이 된다.

3.2.2 컨텍스트 그룹 단위의 session 설정

container.xml 의 <ContextGroup> 태그의 속성에서 session 의 설정을 할수 있다. 다음은 이 속성들의 설명이다.

SharedSession [ (optional) default : false ] : servlet specification 에서 session 은 context 단위로 관리되며 서로 공유될 수 없다. 즉 A 라는 컨텍스트에서 어떤 사용자가 만든 HttpSession 객체는 B 라는 컨텍스트에서는 동일한 사용자라 하더라도 사용할 수 없다는 것이다. 하지만 경우에 따라서는 기본적으로 컨텍스트간 세션이 공유가 되는 것이 필요할 수 있다. 이 경우, 이 속성을 true 로 설정하면 컨텍스트간 세션을 공유할 수 있게 된다. 가질 수 있는 값은 true 혹은 false 이고 기본값은 false 이다.


SessionTimeoutMinute [ (optional) default : -1 (단위 : 분) ] : 이 속성은 위의 SharedSession 속성을 true 로 할 경우, 세션 객체의 타임아웃을 정하는 것이다. 이 시간 간격 동안 세션 객체가 사용되지 않았다면 메모리에서 제거된다. Servlet specification 에 따르면 session 객체에 대한 타임 아웃값은 context 단위로 설정할 수 있게 되어 있으며 web.xml 에 <session-timeout> 태그를 이용하여 지정한다. 그러나, WebtoB Servlet Engine 에서 SharedSession 속성을 true 로 설정하면 각 context 의 web.xml 에 지정한 타임아웃 값은 무시되며 SessionTimeoutMinute 에 의해 지정된 값이 모든 context 들의 타임아웃 값으로 동일하게

지정된다. 기본값은 –1 이며, session 의 생존 시간이 무한대(즉, 타임아웃에 의한 session invalidation 이 없다)임을 뜻한다. 즉 이 값이 음수인 경우 타임아웃 체크를 하지 않는데 이 경우 Container 가 종료가 되기 전까지는 세션이 항상 메모리 내에 남아 있게 되어 필요이상의 자원을 낭비하게 된다. 따라서 적당한 시간을 주는 것이 바람직하다.

3.2.3 분산 세션(Distributed Session)

분산 세션(Distributed Session)이라는 것은 여러 개의 Web Container 가 서로의 세션 객체를 공유하기 위하여 클러스터링하는 것을 말한다. 부하조절(load balancing)이나 장애 대책을 위해 동일한 서비스를 제공하는 다수의 Web Container 를 다른 노드 혹은, 같은 노드에 여러 개 기동시킬 필요가 있다. 이러한 환경에서는 동일한 클라이언트에 의한 요청일지라도 서로 다른 Web Container 에서 서비스될 수가 있다.

이 때, Web Container 사이에 세션 객체가 공유되지 않는다면 세션 객체를 사용하는 서비스에서 세션을 지속적으로 유지할 수 없기 때문에 원하는 서비스를 제공할 수 없다. WebtoB Web Container 에서는 이러한 분산 환경에서도 세션 객체를 공유할 수 있게하여 세션을 계속 유지시킬 수 있는 기능을 제공하며 이를 세션 클러스터링(session clustering)이라 한다.

WebtoB Web Container 에서는 다음과 같은 3 가지 방식의 session clustering 기법을 제공한다.

Session routing 기법

Session server 에 의한 session clustering

위의 두 가지 방식을 결합한 session clustering


3.2.3.1 Session routing

Session routing 기법은 세션 객체를 최초로 생성한 WebtoB Web Container 는 session 구분자인 Cookie 에 자신의 구분자(servlet engine identifier)를 삽입한다. 웹 서버는 이 Cookie 값을 조사하여 세션 객체가 생성된 WebtoB Web Container 로 클라이언트 요청을 routing 해 준다. 이러한 방법의 장점은 알고리즘이 간단하고 시스템 리소스(처리 시간, 메모리등)를 적게 소비한다는 것이다. 단점으로는 Web Container 장애 발생 시 세션 객체를 복구할 수 없다는 것이다. 해당 세션을 처리할 Web Container 가 장애로 인하여 더 이상 서비스할 수 없다고 판단되는 경우, 웹 서버는 정상 동작하고 있는 다른 Web Container 로

클라이언트 요청을 routing 해준다. 이전에 서비스하던 세션 객체는 장애가 발생한 Web Container 와 함께 사라졌기 때문에, 대신 서비스하는 Web Container 는 새로운 세션 객체를 생성한다. 따라서, 일시적으로 세션이 깨지는 현상을 막을 수는 없다.

그림 3-1 은 session routing 을 통하여 session clustering 을 수행하는 모습

을 나타낸 것이다. 웹 서버 2 대와 WebtoB Web Container 3 대가 동일한 서비스를 제공하고 있다.

클라이언트가 최초의 요청 request1 을 요청한다. Load balancer 는 자신의 load balancing 방법에 의해 서비스를 제공할 웹서버를 선택한다. 여기에서는 Web server 1 이 선택되었다.

Web server 1 은 역시 자신의 load balancing 방법에 따라 Web container 1,2,3 중 하나를 선택한다. 여기에서는 WebtoB Web Container1 이 선택되었다.

최초의 요청(즉, 요청에 첨부된 Cookie 값이 없다)이므로 container 1 은 새로운 세션 객체를 생성한다. 서비스에 대한 응답을 송신하면서 세션 객체에 대한 Cookie ID 를 같이 보내는데, 이 Cookie ID 에 미리 약속한 container 구분자(여기에서는 engine1)을 붙혀 보낸다.

같은 클라이언트가 두번째 요청 request2 를 요청한다. Load balancer 가 이번에는 Web server 2 를 선택하였다. 클라이언트의 요청에는 앞에서 서버로부터 받은 Cookie ID 가 첨부되어 있다.


Web server 2 는 클라이언트가 보낸 요청에서 Cookie ID 를 검사하여 어떤 Web container 가 이 Cookie ID 를 생성하였는지를 판단한다. Web container 1 이 생성하였음을 알고 이 요청을 WebtoB Web Container 1 으로 routing 한다.

그림 3-1 session routing 에 의한 session clustering

session routing 기능을 이용하려면 container.xml 을 비롯해 Web Server 에 여러가지 설정을 추가 해야 한다. 이에 대한 자세한 내용은 4.2.3.5 절 설정 부분에서 다루기로 하겠다.

Note : WebtoB 에서 session routing 은 버전 3.1.2 이상에서 지원한다.


3.2.3.2 Session server

Session server 에 의한 session clustering 기법을 이용하면 부하 조절 기

능은 물론, 장애 발생 시 세션 객체를 복구하여 장애 발생 전의 세션 정보를 그대로 유지해 줄 수가 있다. 또한, Session server 는 자신의 backup session server 를 설정할 수가 있어서 session server 에 장애가 발

생한 경우에도 완벽한 세션 정보 복구가 가능하다.

세션 서버를 사용하면 Web Server 는 현재 요청된 클라이언트 요청을 어떤 Web Container 로 보내야 할지를 생각하지 않아도 된다. 자신의 routing 방법에 따라 서비스할 Web Container 를 선택하여 요청을 보내면 된다.

백업 세션 서버는 선택적으로 사용할 수 있다. 백업 세션 서버는 주 세션 서버가 동작하는 동안은 주기적으로 세션 서버에 저장된 세션 정보를 백업 하는 역할을 하다가 주 세션 서버에 장애가 발생하여 Web Container 들이 자신에게 세션 정보를 요청하면 그 때, 주 세션 서버 처럼 동작하게 된다. 백업 세션 서버는 동작중에 동적으로 지정해 줄 수도 있으며 주 세션 서버가 다시 동작할 수 있게 되었을

때 세션 서버의 역할을 주 세션 서버로 넘기고 자신은 다시 백업 기능을 수행하게 된다.

다음 그림은 Session Server 를 이용하여 세션 클러스터링하는 모습을 나타낸 것이다.

클라이언트가 첫번째 요청 request1 을 요청한다.

Load balancer 가 Web server 1 이 선택한다.

Web server 1 은 자체적인 load balancing 알고리즘에 따라 WebtoB Web container 1~3 중 하나를 선택한다. 여기서는 WebtoB Web container 1 을 선택하였다.

WebtoB Web container 1 은 request1 에 대해서 세션 객체를 새로 생성한다 . Request1 에 대한 처리를 마친 후 WebtoB Web container 1 은 세션 객체를 cookie ID 와 함께 Session server 에 저

장한다. 서비스 결과를 클라이언트로 전송한다.

클라이언트가 두번째 요청 request 2 를 요청한다.

Load balancer 가 이번에는 Web server 2 를 선택하였다.

Web server 2 를 WebtoB Web container 1~3 중 하나를 선택한다. 여기서는 WebtoB Web container 3 를 선택하였다.

WebtoB Web container 3 를 요청 메시지에 함께 온 cookie ID 를 이용하여 session server 에 이전에 사용하였던 세션 객체가 있는지를 조사한다. request 1 을 처리할 당시 저장되었던 세션 객체를 session server 로부터 가져온다. request 2 를 처리한다. 세션 객체가 업데이트 되었는지를 확인하여 업데이트되었으면 session server 에 업데이트한다. 서비스 처리 결과를 클라이언트에게 전송한다.


backup session server 는 JeusMain.xml 에 설정된 주기에 따라 정기적으로 session server 에 저장된 세션 객체 정보를 백업 받는다. Session server 에 의한 session clustering 을 하기 위해서는 세션 객체 및 세션 객체 내부의 멤버 인스턴스들이 serializable 해야 한다. 그렇지 않으면 세션 객체를 세션 서버로 전송할 때 java.io.NotSerializableException 이 발생하여 전송에 실패하게 된다. Serializable 하기 위해서는 해당 객체가 java.io.Serializable 을 implement 해야 한다. 세션 객체로서 많이 사용하는 java.lang.String 등은 java.io.Serializable 을 구현하였기 때문에 문제없이 사용할 수 있다. Java class libarary 에 있는 클래스들 중

java.io.Serializa-ble 을 implement 하지 않은 클래스들은 그 객체를 session server 로 전송할 수 없으므로 반드시 transient 로 선언 해주어야 한다. 사용자가 직접 작성한 클래스을 세션 객체로 사용하여 세션 서버에 저장되기를 원한다면 반드시 java.io.Serializable 을 구현해야 한다. 세션 객체 내부의 멤버 인스턴스 중 굳이 session server 에 저장하지 않아도 된다면 transient 로 선언해주기를 권장한다. 그 만큼 네트워크 부하가 감소하기 때문이다.

그림 3-2 session server 에 의한 session clustering

Session Server 구조


이해를 돕기 위하여 session server 의 내부 동작 방식에 대해서 설명해 보기로 하겠다.

다음 그림에 WebtoB Servlet Engine 의 session server 의 구조를 나타내었다. Session server 내부에 세션 객체를 위한 저장 공간은 두 곳이 있다. 하나는 메모리에 위치한 cachedSession 공간이고 다른 하나는 하드 디스크 공간에 파일로서 존재하는 SessionStorage 이다. WebtoB Web Container 에서 생성된 새로운 객체는 일단 cachedSesion 에 저장된다. CachedSession 에 저장된 세션 객체중 passivationTO 시간 동안 엑세스 되지않은 객체들은 메모리 절약과 빠른 검색을 위해 SessionStorage 공간으로 옮겨진다. SessionStorage 에 저장된 세션 객체에 한해서 removalTO 시간동안 엑세스 되지 않은 객체들은 영구히 제거된다. 따라서, session server 설정시 removalTO 시간은 session timeout 시간보다는 같거나 길어야 한다.


그림 3-3 session server 구조

WebtoB Web Container 로부터 세션 객체를 요청받으면 (getSession) session server 는 일단 cachedSession 공간을 검색하여 발견된 세션 객체

를 리턴한다. 이곳에서 찾지 못하면 SessionStorage 를 검색하여 발견된 세션 객체를 리턴하게 된다 . BackupManager 의 기능은 일정주기

(checkTO)로 session server 에 저장된 세션 객체를 BackupSessionServer에 백업하는 역할을 한다 . 만일 session server 에 장애가 발생하여 WebtoB Web Container 가 session server 를 사용하지 못하게 되면 BackupSessionServer 로 자동으로 failover 하게 되는데 이 경우 checkTO 값에 따라 일부의 세션 객체가 유실될 수도 있다. SessionStore 가 저장 공 간 으 로 서 사 용 할 파 일

은 %W2B_JEUSHOME%\workspace\serverName\serverName.fdb(유닉스의 경우 $W2B_JEUSHOME/workspace/serverName /serverName.fdb)이다 . 예

를 들 어 session server 의 이 름 이 “mySessionServer” 이

고 %W2B_JEUSHOME%이 c:\webtob\jeus 이라면 세션 객체가 저장될 파일이름은 c:\webtob\jeus\workspace\mySessionServer.fdb 이다 . 그러나 ,

이 파일의 위치 및 이름은 사용자가 설정을 통해 별도로 지정할 수도 있다.

3.2.3.3 혼합 방식

앞서 설명한 두가지 방식을 혼합하여 사용할 수도 있다. Session routing 에 의한 방식은 세션 객체를 Web Container 내부에서 관리하기 때문에 실행 속도가 빠르나 장애가 발생할 경우 세션이 진행중이 세션 객체를 모두 잃어버려 복구가 불가능한 단점이 있다.

Session server 에 의한 방식은 모든 세션 객체를 중앙 session server 에 저장하기 때문에 특정 Web Container 에 장애가 발생하더라도 세션 객체를 잃어 버리는 경우가 발생하지 않는다. 특정 Web Container 에 장애가 발생하더라도 Web Container 에 의해 세션을 지속시킬 수 있다. 그러나, 서비스 요청때마다 세션 객체를 session server 로부터 가져오고 세션 객체가 업데이트될 경우 다시 session server 에 저장해야 하므로 session routing 에 의한 방법보다 실행 속도가 느리다는 단점이 있다.

혼합 방식은 이 두방식의 단점을 보완할 수 있는 방식이다. 두가지 방식으로 혼합할 경우 세션 객체는 중앙 session server 와 해당 세션 객체를 생성한 Web Container 에도 존재한다. 정상적인 경우 가장 최근에 업데이트된 세션 객체는 그 세션 객체를 생성시킨 Web Container 에 존재하므로 session server 로부터 세션 객체를 가져올 필요가 없다. 서비스 처리 종료 후 세션 객체가 업데이트된 경우만 session server 에 업데이트하면 된다. 따라서, session server 방식만 사용하는 경우에 비해서 네트워크 사용량이 약 절반으로 감소한다. Session server 에는 가장 최근의 세션 객체가 저장되어 있으므로 특정 Web Container 에 장애가 발생하더라도 세션 복구가 가능하다.

3.2.3.4 장애 대책

혼합 방식을 사용하였을 때 특정 Web Container 에 장애가 발생하여 더 이상 서비스를 할 수 없을 경우 WebtoB Web Container 시스템이 어떻게 대처하는지를 예를 들어 설명해보기로 하겠다.

다음 그림은 하나의 웹 서버 Web server 에 3 개의 WebtoB Web Container 1~3 이 연결된 모습이다. 각 Web Container 에는 session routing 및 session server 설정이 되어 있다. 웹서버에도 session routing 을 지원

할 수 있는 설정이 되어 있다(WebtoB 인 경우는 session routing 을 위해

서 별도의 설정이 필요하지 않다).


클라이언트가 첫번째 요청 request1 을 요청하였다.

Web Server 는 request1 을 WebtoB Web Container 1 에 routing 하였

고 WebtoB Web Container 1 은 이를 정상적으로 처리하여 “xxx”라는 새로운 cookie ID 를 생성하였다. Session routing 을 지원해

야 하므로 cookie ID 의 끝에 자신의 ID 인 engine1 을 삽입하였

다. 모든 처리가 끝난 후에 WebtoB Web Container 1 은 자신이 생성한 Cookie ID 와 세션 객체를 session server 에 저장한다. 이

때 cookie ID 은 자신의 ID “engine1”이 제거된 “xxx”로서 저장된

다.

request1 이 정상 처리된 후 클라이언트는 request2 를 요청한다. 이때 request header 에는 이전에 WebtoB Web Container 1 으로부

터 받은 cookie ID “xxx.engine1”이 실려 있다.

Web Server 는 cookie ID 를 조사한다. Cookie ID 끝에 “engine1”이라고 되어 있으므로 request1 을 다시 WebtoB Web Container 1 으

로 routing 하려 한다.

그러나, 이 떄 WebtoB Web Container 1 에 장애가 발생하여 서비스를 처리할 수 없는 상태이다. Web Server 는 이를 알고 나

머지 Web Container 중 하나를 선택하여 request2 를 보낸다. 아

래 그림에서는 WebtoB Web Container 3 가 선택되었다.

WebtoB Web Container 3 는 자신이 캐싱하고 있는 cookie ID 중에 ID 가 “xxx”인 것을 찾아본다. 현재 상황에서는 캐싱 데이터 중에 “xxx”라는 것이 없을 것이다. WebtoB Web Container 3 는 session server 에 “xxx” cookie ID 로 저장된 세션 객체가 있는지

를 알아 본다.

WebtoB Web Container 1 이 장애가 발생하기 전에 session server에 저장한 cookie ID=”xxx”의 세션 객체가 있으므로 session server 는 WebtoB Web Container 3 에게 해당 세션 객체를 넘겨준

다.


WebtoB Web Container 3 는 session server 로부터 받은 세션 객체를 가지고 정상적인 서비스 처리를 한다. 서비스 처리 후 업데이트된 세션 객체는 cookie ID=”xxx”의 이름으로 다시 session server 에 저장한다. 클라이언트에게 응답을 보내기 전에 cookie ID 의 끝에 자신의 ID 인 “engine3”를 삽입하여 이후의 클라이언트 요청이 모두 WebtoB Web Container 3 로 올 수 있도록 한다.

그림 3-4 혼합 방식을 사용하였을 때 장애 복구

3.2.3.5 설정

session routing 또는 session server 에 의한 session clustering 은 WebtoB Web Container 단독으로 이루어지는 일이 아니기 때문에 Web Container 설정외에 웹 서버의 설정, WebtoB Servlet Engine Server 의 설정등이 부

가적으로 필요하다.

container.xml 의 설정


<DistributedSession SessionRouting="true">

<SessionServer ServerName="session1"

BackupServerName=”session2”

InitCapacity="1"

MaxCapacity="3"

IncrementRate="1"

TimeoutMilliSec="10000">

</SessionServer>

</DistributedSession>

분산 세션을 설정하기 위한 태그는 <DistributedSession>이다. SessionRo- uting 속성은 이 Web Container 가 session routing 을 실시할지 여부를 결

정한다. <SessionServer> 태그는 session server 로서 사용할 서버를 결정

한다. ServerName, MaxCapacity 속성은 필수적으로 설정해야 한다.

ServerName, BackupServerName 은 JeusMain.xml 에 설정된 session server의 export name 을 기입해야한다. InitCapacity, MaxCapacity, IncrementRate, TimeoutMilliSec 는 session server 로의 socket connecti-on pool 관련 설정으

로서 각각 초기 연결수, 최대 연결수, 연결을 새로 추가할 때 한번에 맺을 연결수, connection pool 로부터 연결을 가져올때의 최대 대기 시간

을 의미한다. 위와 같이 설정하면 다음과 같은 의미가 된다.

Session routing 에 의한 세션 클러스터링이 enable 됨

Session server 에 의한 세션 클러스터링이 enable 됨

Session server 의 export name 은 “session1”이다.

백업 session server 를 사용하며 그 export name 은 “session2”이다.

Session server 로의 connection pool 의 초기 연결 개수는 1 이

다.

Connection pool 의 최대 연결 개수는 3 이다.

연결 증가 율은 1 이다.

Connection pool 로부터 연결을 가져오는데 최대 대기 시간은 10 초이다.

JeusMain.xml 의 설정

세션 서버는 WebtoB Web Container 내부에 존재하지 않고 WebtoB Servlet Engine Server 내부에 하나만 존재한다. 따라서 백업 설정을 위해서는 백업을 받을 세션 서버가 필요하고 이를 위해서는 또다른 JEUS Server 가 있어야 한다.세션 서버에의한 세션 클러스터링을 하기 위해서는 JeusMain.xml 에 세션 서버 설정을 해야하고 장애대책을 고려한다면 백업 세션 서버에 관련된 설정도 하여 JEUS Server 를 기동 시켜야 한다. JeusMain.xml 에 대한 전반적인 이해는 JEUS Administration Guide 매뉴얼을 참조하기 바란다. 여기서는 세션 서버에 관련된 부분만 설명하기로 하겠다.


Primary 를 담당하는 Session Server

<SessionServer>

<Resolution>60000</Resolution>

<SessionManager>

<SessionName>session1</SessionName>

<SessionExportName>session1</SessionExportName>

<PassivationTO>-1</PassivationTO>

<RemovalTO>-1</RemovalTO>

<FileDBPath/>

<FileDBName/>

<MinHole>1000</MinHole>

<PackingRate>0.5</PackingRate>

<CheckTO>30000</CheckTO>

<OperationTO>30000</OperationTO>

<BackupName>session2</BackupName>

<BackupTrigger>1000</BackupTrigger>

</SessionManager>

</SessionServer>

Backup 를 담당하는 Session Server

<SessionServer>


<SessionManager>





<FileDBPath/>

<FileDBName/>







</SessionManager>

</SessionServer>


Resolution(optional) : 세 션 객 체 의 passivation/removal 를 결정하는 thread 의 체크 주기. 기본 값

은 60000(60 초)이다. (milli-second 단위)

SessionName(required) : session server 의 이름

SessionExportName(required) : session server 의 export name. Container.xml 의 ServerName/BackupServerName 속성에 이 이름을 적어야 한다.

PassivationTO(optional) : cachedSession 중에 이 시

간동안 엑세스 되지 않은 세션 객체는 메모리 절약과 빠른 검색을 위해 SessionStorage 로 passivation 된다. 기본값은 –1이고 passivation 을 시도하지 않겠다는 뜻이다.(milli-second 단위)

RemovalTO(optional) : SessionStorage 에 저장된 세션 객체 중에 이 시간동안 엑세스 되지 않은 세션 객체는 영구히 제거된다. 이 시간은 session timeout 값보다 작아서는 안된다. 기본값은 –1 이고 removal 을 시도하지 않게다는 뜻이다.(milli-second 단위)

FileDBPath(optional) : SessionStorage 가 사용할 저장 파일이 위치할 디렉토리 . 설정하지 않으면 기본 값으

로 %W2B_JEUSHOME%\workspace 가 된다.

FileDBName(optional) : SessionStorage 가 사용할 저장 파일의 이름. 설정하지 않으면 기본 값으로 SessionName.fdb가 된다.

MinHole(optional) : fdb 파일 검색 속도를 향상시키기 위해 fdb 파일을 재정리하는 임계값이다. MinHole 에 지정한 숫자만큼 fdb 파일을 엑세스하게되면 fdb 파일은 다시 정리한다. 기본값은 1000 이다.

PackingRate(optional) : MinHole 과 마찬가지로 fdb 파일을 재정리하는 임계값을 나타낸다. (fdb 파일 엑세스 회수)/(fdb 파일에 저장된 세션 객체의 수)가 이 값을 넘으면 fdb 파일을 재정리한다. 기본 값은 0.5 이다. 0~1 사이의 값만 유효하다.


CheckTO(optional) : BackupName 이 지정된 경우 백업 주기를 지정한다. BackupName 이 지정된 경우 이 값은 반드시 0 보다 커야한다. 기본값은 30000(30 초)이다.(milli-second 단위)

OperationTO(optional) : session server 와 web container사이의 통신 타임 아웃 값이다. 기본값은 30000(30 초)이다. (milli-second 단위)

BackupName(optional) : backup session server 의 export name 이다.

BackupTrigger(optional) : CheckTO 시간 주기로 백업하거나 현재 백업이 이루어지지 않은 세션 객체의 수가 이 값보다 크면 백업하게 된다. 기본값은 1000 이다.

3.3 데이터베이스 연결 풀링

여기서는 DB 연결 풀링에 대한 전반적인 설명을 한다. 따라서 container.xml 의 설정에 관한 자세한 설명은 5 장 Container.xml Reference 의 DB 연결 풀링 설정 항목을 참조하고 개발에서 DB 연결 풀링을 사용하는 방법은 9 장 Servlet 의 구현에서 Connection Pooling 의 사용 항목을 참조하기 바란다.


3.3.1 Web Container 에서의 데이터베이스 연결 풀링

데이터베이스 연결 풀링은 Application(servlet 이나 JSP)에서 데이터베이스에 요청을 할 때마다 데이터베이스와 연결을 맺고 인증을 하는 과정에서 발생하는 부담을 줄이기 위해 미리 테이터베이스와 연결을 맺어 풀에 넣어 두고 Application 이 요청할 때 꺼내 주고 사용이 끝난 후에는 다시 풀에 넣어 다음에 재사용하도록 하는 기법이다.

WebtoB Web Container 에서는 두 가지 DB 연결 풀링 방법이 있다. 하나는 WebtoB Servlet Engine 서버에서 제공하는 naming server 기능을 이용한 방법이고, 다른 하나는 Web Container 에서 제공하는 DB 연결 풀링이다. 이 중 첫번째 것은 WebtoB Servlet Engine 서버의 설정 파일인 JeusMain.xml 에서 설정하며 JNDI specification 에 따라 사용할 수 있다. 따라서 여기서는 container.xml 에서 설정해서 Web Container 단독으로 사용하는 DB 연결 풀링의 설정에 대해 알아보자.

이 설정은 <Container> 태그 안에서 설정하지만 <ContextGroup> 바깥에 있다. 이 말은 하나의 컨텍스트 그룹에 종속된 DB 연결 풀링이 아니라, 어느 컨텍스트 그룹에서도 사용할 수 있는 DB 연결 풀링이라는 뜻이다. 이 설정은 <DBConnectionPool> 태그가 담당한다.

Container 에서 제공하는 데이터베이스 연결 풀링은 shared 와 non-shared 두 종류가 있다. shared 방식은 여러 개의 컨텍스트 그룹 내의 쓰레드들이 DB 연결을 필요로 할 때, DB 연결 풀에서 하나씩 가져다 쓰는 방법이다.

non-shared 방식은 데이터베이스 풀의 DB 연결들이 쓰레드들에 의해 공유되지 않고 각 쓰레드에 할당되는 방식으로 쓰레드 수만큼의 DB 연결이 이루어진다. 하지만 이 방식은 DB 연결을 얻기 위해 다른 쓰레드와 경쟁을 할 필요가 없으므로 성능이 향상될 수 있다. 하지만 DB 시스템에서 설정한 쓰레드 수만큼 DB 연결을 맺을 수 없도록 제한되어 있을 경우에는 non-shared 방식을 사용할 수 없다. 이때는 shared 방식을 사용해야 한다.

3.3.2 데이터베이스 연결 풀링의 설정

데이터베이스 연결 풀링을 사용하기 위해서는 container.xml 에 <DBConnectionPool> 태그를 설정해야 한다. 이 때 shared 방식과 non-shared 방식 두 가지가 약간의 차이를 지닌다. 각 방식에서의 설정에 대해 알아 보자.

3.3.2.1 shared 방식

container.xml 에 설정된 예는 다음과 같다.

<DBConnectionPool ConnectionPoolID="sharedOraclePool"

ConnectionPoolType="shared"

ConnectionURL="jdbc:oracle:thin:@111.111.111.111:1521:ORA815"

DriverClassName="oracle.jdbc.driver.OracleDriver"

ConnectionArguments="user=system;password=manager"

CloseLongActiveConnection="true"

MaxActiveTimeSecs="60">

<DBPoolControl InitCapacity="2"

MaxCapacity="10"

IncrementRate="2"

MaxIdleTimeSecs="300"/>

</DBConnectionPool>

위의 설정에서 각 속성은 다음과 같은 역할을 한다.


ConnectionPoolID (required): 데이터베이스 풀 구분자. 유일한 값이어야 한다.

ConnectionPoolType (required): shared 또는 non-shared.

ConnectionURL (required): 실제 물리적 데이터베이스 연결을 얻을 때 사용하는 URL.

DriverClassName (required): 사용할 JDBC 드라이버 클래스의 이름.

ConnectionArguments (optional): 연결을 맺을 때 사용되는 유저 이름과 패스워드 등을 지정한다.

CloseLongActiveConnection (optional): 일정 시간 이상 계속 사용 중인 연결을 강제로 끊어 줄 것인지를 설정한다. 여러가지 이유로 DB operation 중 블록킹 현상이 발생할 수 있으며 이러한 블록킹 현상이 일어난 연결을 강제로 종료하고 풀에 반환할 수 있게 한다. 기본값은 false 이다.

MaxActiveTimeSecs (optional): CloseLongActiveConnection 속성이 true 일 때 허용하는 최대의 active 시간을 설정한다. 기본값은 –1 이다.

InitCapacity (optional): 처음 연결의 개수이며 최소한으로 유지해야 하는 연결의 개수이기도 하다. 기본값은 1 이다.

MaxCapacity (required): 최대 연결의 개수. InitCapacity 보다 작지 않아야 한다.

IncrementRate (optional): 증가하는 연결의 단위

MaxIdleTimeSecs : 사용되지 않고 있을 수 있는 최대 idle 시간이다. 이 시간이상 idle 상태인 연결은 종료된다. 단, InitCapacity 개수 만큼의 연결은 유지한다. 기본값은 –1 이며 idle 상태를 검사하지 않는다는 뜻이다.


3.3.2.2 non-shared 방식

container.xml 설정은 다음과 같다.

<DBConnectionPool ConnectionPoolID="nonSharedOraclePool"

ConnectionPoolType="non-shared"

ThreadPoolPort="8088"





MaxActiveTimeSecs="60">

</DBConnectionPool>

shared 방식과 다른 부분은 ConnectionPoolType 과 ThreadPoolPort, 그리고 <DBPoolControl> 태그의 설정이 없다는 것이다. 여기서 ThreadPoolPort 는 데이터베이스 연결 풀링을 설정할 쓰레드 풀의 포트번호를 지정하는 것이다 (쓰레드 풀은 포트번호로서 구별된다).

3.3.3 데이터베이스 연결 풀링의 사용

DB 연결 풀링은 앞에서도 말했듯이 2 가지 종류가 있다. 이 DB 연결 풀링을 사용하는 방법은 9 장 Servlet 의 구현에서 Connection Pooling 의 사용 항목을 참조하기 바란다.

3.4 웹 서버의 WebtoB Servlet Engine 연결 설정

WebtoB Web Container 는 WebtoB 웹서버와 연동할 수 있다. WebtoB 와의 연동을 위해서는 container.xml 외에 웹서버 자체의 설정이 별도로 추가되야 한다. 여기서는 WebtoB 웹서버의 설정파일에서 WebtoB Web Container 와의 연결을 설정하는 방법을 살펴 보기로 한다.


3.4.1 웹서버 연결이란?

클라이언트(웹 브라우져)가 WebtoB Web Container 가 제공하는 서비스를 제공받을 수 있으려면 HTTP 프로토콜을 이해할 수 있는 웹서버가 WebtoB Web Container 의 전면부에 존재해야 한다. 웹서버의 역할은 클라이언트가 요청한 HTTP 헤더를 분석하여 서비스를 수행할 서버를 결정해 해당 서버로 라우팅해주는 것이다. 만약 클라이언트의 요청이 WebtoB Web Container 가 수행할 서비스라고 판단되면 WebtoB Web Container 로 라우팅될 것이다.

웹서버에 대해서 요청을 받고 처리하기 위해서는 웹서버에서 오는 요청을 받아 줄 리스너(Listener)가 있어야 한다. 이 리스너는 연결할 웹서버에 따라 동작이 달라진다.

하나의 Web Container 에서 웹서버와의 연결은 다중으로 설정할 수 있다. 다만 각각의 설정마다 포트번호만 달리 지정해 주면 된다. 예를 들어 9999 번 포트로는 WebtoB 와의 연결을 설정할 수 있다. 또한

같은 종류의 웹서버와의 연결이라도 다른 포트로 여러 개도 가능하다. 예를 들어 WebtoB 웹서버와의 연결 설정을 8080 번과 8089 번 두 개로 할 수도 있다.

각 웹서버와의 연결 설정에는 반드시 하나의 쓰레드 풀 설정이 포함되어야 한다. 여기서 설정하는 쓰레드 풀은 해당 포트로 요청이 들어 왔을 때 실제 요청을 처리해 주는 worker 쓰레드를 담고 있는 것으로 이 쓰레드 풀의 동작에 필요한 여러 가지 변수들을 설정해 주어야 한다.

각각의 웹서버에 대해 좀더 살펴 보도록 하자.


3.4.2 WebtoB 와의 연결

WebtoB 는 정적인 페이지의 전송, CGI, SSI, PHP 등 일반적인 웹서버의 작업을 처리해 줄 수 있으며 WebtoB Web Container 와 연동할 경우 servlet/JSP 의 서비스를 제공한다. WebtoB 와 WebtoB Web Container 사이에 연결이 설정되면 WebtoB Web Container 는 WebtoB 의 CGI 서버나 PHP 서버처럼 servlet 이나 JSP 서비스를 제공하는 JSV 서버로서 동작하게 된다.

WebtoB 의 경우 반드시 WebtoB 가 먼저 기동이 되어 있어야 한다. 그것은 연결을 처음 설정하는 과정에서 WebtoB 가 기다리는 역할을 하기 때문이다. 하지만 연결이 설정된 이후에는 다른 것과 마찬가지로 WebtoB 가 Web Container 의 클라이언트 역할을 해서 요청을 넘겨 주고 결과를 받는다.

또한, WebtoB 와 WebtoB Web Container 와의 연결은 persistent connection 이라서 중간에 내트워크 오류나 서버의 문제가 생기지 않는 이상은 연결을 끊지 않고 재사용한다.

WebtoB 와의 연결 설정을 위해서는 두 가지 설정 파일이 필요하다. 하나는 WebtoB 의 설정파일인 http.m 이고 또 다른 하나는 Web Container 의 설정파일인 container.xml 이다. 다음은 container.xml 과 http.m 에 대한 설정의 예이다. Container.xml 에서 <Connection> 태그에 대한 자세한 설명은 5 장 container.xml Reference 에서 다루고 있다. 단 쓰레드 풀의 설정에 있어서는 MinThread 만을 지원한다. 이것은 WebtoB 와의 연결이 영구적(persistent)이어서 다른 설정이 필요없기 때문이다.

< container.xml >

<Connection ListenerType="WebtobListener"

Port="9900"

WebServerAddress="111.111.111.111"

RegistrationID="MyGroup"

ConnectionPortNum="2"

ServerAccessControl="false">

<ThreadPool MinThread="2"

MaxThread="10"

ChangeRate="2"

MaxIdleTime="300"

MaxWaitQueue="4" />

</Connection>

<< http.m >>

*NODE

foo …

HTH = 2,

JSVPORT = 9900,

…

*SVRGROUP

jsvg NODENAME = foo, SVRTYPE = JSV

*SERVER

MyGroup SVGNAME = jsvg, MinProc = 2, MAXProc = 10

*URI

uri1 Uri = "/examples/", Svrtype = JSV

uri2 Uri = "/test/", Svrtype = JSV

*EXT

jsp MimeType = "Application/jsp", SvrType = JSV


3.4.2.1 container.xml

WebtoB 와 연결을 관리할 리스너의 종류는 WebtobListener 이고 포트는 9900 번으로 설정되어 있는데 이것은 http.m 에 설정된 JSVPORT 와 일치해야 한다. WebServerAddress 에는 연결을 맺을 WebtoB 의 어드레스를 지정해 준다. 그리고 RegistrationID 의 값은 WebtoB 와

처음 연결을 맺을 때 등록과정 중 사용할 등록 ID 로서 http.m 의 SERVER 부분의 서버이름과 같아야 한다. 이 값을 “default”라고 하면 이 Connection 태그가 속한 ContextGroup 의 ContextGroupName 속성 값이 RegistrationID 로 사용된다.

ConnectionPortNum 은 WebtoB 와 연결할 포트의 개수로서 http.m 에서 NODE 부분의 HTH 설정값과 일치해야 한다. 예에서는 양쪽 다 2 개로 설정되어 있다. 쓰레드 풀 설정(ThreadPool 태그)에서는 최소한 유지해야 할 worker 쓰레드의 개수가 2 개 이고(MinThread 속성) 최대한으로 늘일 수 있는 쓰레드의 개수가 10 개이다(MaxThread 속성). 그리고 쓰레드가 일정시간 사용되지 않고 있다면 쓰레드를 종료시키는데 이 때, 이 시간을 설정하는 것이 MaxIdleTime 으로 위에서 설정된 값은 300 초(5 분)이다. 이렇게 쓰레드를 증가시키고 감소시키는 단위는 2 개로서 한꺼번에 2 개씩 증가 혹은 감소를 시키게 된다.

그리고 마지막으로 쓰레드를 증가시키기 전에 대기시켜 놓을 수 있는 요청의 개수를 설정하는 것이 MaxWaitQueue 이다. 현재 4 개로 설정되어 있으므로 4 개 이하의 요청이 대기 중이라면 쓰레드를 증가시키기 보다는 작업 중인 쓰레드 중 하나가 대기 중인 요청을 처리하기를 기다리게 된다.


3.4.2.2 http.m

우선 먼저 용어상 유의해야 할 부분은 WebtoB 에서 사용하는 ‘서버’라는 단어는 특정 작업을 처리할 프로세스를 말한다. 예를 들어, HTML 페이지들을 처리하는 서버는 HTML 서버, servlet/jsp 요청을 처리하는 서버는 JSV 서버, CGI 를 처리하는 서버는 CGI 서버라고 부른다. NODE 부분에서 JSVPORT 는 Web Container 와 연결을 맺을 포트로서 실제 웹브라우저로터 요청을 받는 포트와는 무관하다. 실제 웹브라우저와 연결을 맺는 포트는 HTTPPORT 라는 속성으로 설정한다. 그리고 HTH 에 설정된 값은 WebtoB 에서 HTH 라는 프로세서의 개수로서 이 값과 container.xml 의 ConnectionPortNum 은 반드시 일치하여야 한다.

SVRGROUP 부분에서는 Web Container 와 연결을 맺어 작업을 할 서버들의 그룹에 대한 설정으로 예에서는 서버그룹의 이름으로 jsvg, 노드 이름으로 foo, 서버의 종류로서 JSV 를 설정하였다. 여기서 JSV 라는 것이 Java Servlet 에 대한 요청을 처리함을 나타낸다.

SERVER 부분에서는 실제로 Web Container 와 연결하여 작업을 할 서버를 설정하는데 위의 예에서 서버의 이름으로 MyGroup 이고 서버그룹의 이름은 SVRGROUP 부분에서 설정한 jsvg 이다. MinProc 은

서버와의 최소 연결 개수이고 MaxProc 은 서버와의 최대 연결의 개수이다. Web Container 가 서버인 경우 MinProc 과 MaxProc 값은 같게 설정하며 Web Container 쓰레드 풀의 MinThread 값과 일치하거나 커야 한다.

URI 부분은 어떤 URI 가 요청이 되었을 때 어떤 서버를 수행시킬지를 지정하는 것으로 위의 예에서 /examples/와 /test/ 두 가지 URI 에 대해 JSV 서버, 즉 MyGroup 이라는 서버를 수행시키도록 설정되어 있다.

EXT 부분에서는 어떤 확장자를 가진 파일의 요청에 어떤 서버를 수행시킬지를 지정하는 것으로 위의 예에서는 jsp 라는 확장자에 대해 JSV 서버를 실행시키도록 설정되어 있다.

완전한 http.m 의 설정은 WebtoB Administration Guide 를 참조하기 바란다.


3.4.2.3 백업 서버의 설정

WebtoB 와 연결하여 사용 중에 네트워크의 장애나 어떤 문제로 인해 연결이 끊어져 버렸을 때는 Web Container 에서 재연결을 시도한다. 하지만 모든 연결이 다 끊어지고 재연결 시도조차 모두 실패하였을 경우에도 지속적인 서비스를 제공하고 싶다면 백업 서버를 설정한다. 주 서버로의 연결이 끊어지고 재연결 시도에 실패하였을 때 백업 서버가 설정되어 있는 경우 WebtoB Web Container 는 백업 서버와의 연결을 시도한다. 다음은 백업 서버의 설정을 위한 container.xml 이다.


Port="9900"


….

<BackupWebServer Port="9900"



RegistrationID="BackupServer"/>

</Connection>

중간의 생략된 부분은 위의 예에서와 같다. 백업 서버 설정을 위해 추가되는 것이 <BackupWebServer> 태그이다. 여기에서는 위와 같이 4 가지 속성을 설정하여야 한다.

우선 백업 서버의 어드레스는 111.111.111.112 로 설정되어 있고 포트는 9900 으로 설정되었으며 백업 WebtoB 와의 연결 포트 개수는 2 개, 등록 ID 는 BackupServer 로 되었다.

여기서 설정을 하지 않고 생략된 항목은 <Connection> 태그에 설정된 값을 그대로 사용하게 된다. 그 예로 위에서 백업 서버의 쓰레드 풀은 설정하지 않았으므로 원래 WebtoB 서버를 위한 쓰레드 풀 설정과 같은 값들을 사용한다. 이런 백업 서버의 설정은 다중으로 가능하므로 몇 개의 WebtoB 를 설정하여도 된다. 따라서 다중 노드 구성에서는 WebtoB 와 WebtoB Web Container 상의 다양한 구성이 가능하다.

3.4.2.4 WebtoB 를 사용한 WebtoB Web Container Clustering

대규모의 웹 사이트에서 대용량의 클라이언트 요청을 원할히 수행하기 위해서는 여러대의 서버 머신을 클러스터링 할 필요가 있다. 여기서는 다수의 WebtoB 와 다수의 WebtoB Web Container 를 어떻게 클러스터링하는지에 대해서 알아보기로 하겠다. Web Application 이 세션 객체를 사용하는 경우 이러한 클러스터링 환경에서 어떻게 세션 객체를 공유할 것인지도 고려해야 한다. 우선은 세션 객체의 공유는 없는 것으로 클러스터링을 설명하고 그 환경에서 세션 객체를 공유하는 방법에 대해서 기술하기로 한다.

웹 서버에 전용 Web Container 를 할당하는 방식


이 방식은 하나의 WebtoB 서버에 하나 이상의 전용 서블릿 엔진(Web Container 와 같은 개념)을 할당하는 방식이다. 서블릿 엔진은 물리적으로 다른 노드에 있거나 하나의 WebtoB Servlet Engine 서버에 의해 관리되는 서블릿 엔진들일 수 있다. 아래에 이 방식의 예를 그림으로 나타내었다. WebtoB Web Container 는 한 노드에 두개씩 기동되고 있다.


그림 3-5 WebtoB 를 이용한 서블릿 엔진 클러스터링

이 방식을 사용하면, Web Container 는 하나의 WebtoB 에 대한 thread pool 만 가지고 있으면 되므로 pool 관리가 간편하다. 또한, 다음 절에 설명할 방식에 비해서 WebtoB 와 Web Container 사이의 연결 수를 상대적으로 작게 할 수 있다. 이 방식에서 Web Container 사이에 세션 객체를 공유하려면 Session Server 에 의한 방식을 사용해야 한다. WebtoB 가 서비스를 제공하는 모든 서블릿 엔진과 연결을 가지고 있지 않기 때문에 session routing 에 의한 세션 객체 공유는 불가능하다. WebtoB 가 다수의 서블릿 엔진과 연결을 맺기 위해서는 다음과 같은 조건을 만족해야한다.


WebtoB HTH = H

WebtoB MinProc = MaxProc = P

Number of Servlet Engines Per WebtoB = S

WebContainer MinThread = MaxThread = T

WebContainer ConnectionPortNum = H

Number of WebContainer Connections Per HTH = T/H

Total WebContainer Connections Per HTH = S * (T/H)

T%H must be 0(zero)

P must be greater than or equal to S * (T/H)

HTH, MinProc, MaxProc 은 WebtoB 의 설정 파일인 http.m 에 설정해주는 파라메터 이름이다. MinThread, MaxThread, ConnectionPortNum 은 Web Container 설정 파일인 container.xml 에 WebtobListener 태그 내부에 존

재하는 속성이다. HTH 는 WebtoB 의 주요 프로세스인 HTH 의 개수를 설정하는 파라메터이다. HTH 는 클라이언트 요청과 각종 서버를 연결 해주는 일종의 라우터로 클라이언트 요청 처리 능력에 따라 그 개수를 달리할 수 있다. 이에 대한 자세한 내용은 WebtoB Administration Guide 매뉴얼을 참조하기 바란다. MinProc 과 MaxProc 은 WebtoB 와 연동하는 서버 프로세스 개수 또는 서버와의 연결 개수를 설정하는 파라메터이다. 서버가 Web Container 인 경우 Web Container 와 hth 사이의 연결 개수를 결정한다. 서버가 Web Container 인 경우 MinProc 값과 MaxProc 값은 같게 설정한다. WebtobListener 태 그 의 ConnectionPortNum 속 성 은 HTH 값 과 같 게 설 정 하 면 된 다 . WebtobListener 의 ThreadPool 속성인 MinThread, MaxThread 의 값은 같

은 값으로 설정한다. MinThread, MaxThread 값을 결정할 때는 다음과 같은 조건을 만족하도록 결정해야 한다. MinThread, MaxThread 값을 T 라 하면,

T 를 H 로 나눈 값은 0 이어야 한다. 즉, T 는 H 의 배수여야 한다.

S*(T/H)는 P 보다 작거나 같아야 한다.

여기서 H 는 WebtoB hth 개수, S 는 WebtoB 에 연결될 서블릿 엔진의 수 는 WebtoB 환경 파일에 설정된 JSV 서버 MaxProc 의 값이다. 이렇게 T 값을 결정하는데 제약이 있는 이유는, WebtoB 의 hth 당 MaxProc 개까지만 연결을 맺을 수 있고 Web Container 가 모든 hth 로 연결을 가져야 하기 때문이다. WebtobListener 의 경우 worker thread 하나당 하나의 WebtoB 연결을 가지고 있다.

아래에 간단한 예제를 나타내었다.


그림 3-6 Web Container 의 MaxThread(MinThread) 값을 구하는 예제

WebtoB 에는 2 개의 hth 가 기동되고 서블릿 엔진은 3 개가 이 WebtoB 와 연동한다. 만약 T(MaxProc) 값을 H 의 배수인 4 라고 결정하였다면 WebtoB 의 MaxProc 값은 S*(T/H) = 3 * (4/2) = 6 으로 6 이상이어야 한다. 위와 같은 예제에서 WebtoB 의 설정 파일인 http.m 과 Web Container 의 설정 파일인 container.xml 을 작성한 예를 아래에 나타내었다.

< container.xml >

<Connection ListenerType=”WebtoBListener” Port=”9900”

WebServerAddress=”111.111.111.111”

RegistrationID=”MyGroup”

ConnectionPortNum=”2”

ServerAccessControl=”false”>

<ThreadPool MinThread=”4” />

</Connection>

<<http.m>>

*NODE

foo …

HTH = 2,

JSVPORT = 9900,

…

*SVRGROUP


*SERVER


*URI



*EXT


웹 서버가 Web Container 를 공유하는 방식


이 방식은 WebtoB 서버가 모든 서블릿 엔진과 하나이상의 연결을 맺는 방식이다. 서블릿 엔진은 물리적으로 다른 노드에 있거나 하나의 WebtoB Servlet Engine 서버에 의해 관리되는 서블릿 엔진들일 수 있다. 아래에 이 방식의 예를 그림으로 나타내었다. 편의상 WebtoB Web Container 는 한 노드에 하나씩만 기동되는 것으로 나타내었다.

WebtoB 가 서비스를 제공하는 모든 서블릿 엔진과 연결을 맺고 있기 때문에 세션 객체를 공유하는 방법으로 session routing 을 사용하는


것이 가능하다. Session Server 는 장애가 발생하는 경우를 대비하기 위해 선택적으로 사용할 수 있다. 서블릿 엔진이 모든 WebtoB 와 연결을 맺어야 하므로 WebtoB 개수 만큼 WebtobListener 태그를 설정해야 한다.

그림 3-7 WebtoB 를 이용한 서블릿 엔진 클러스터링 2

먼저, 설정 파일의 파라메터를 계산해 보자. WebtoB 의 HTH 파라메터 값은 2 라 하자. 그러면 서블릿 엔진의 MaxThread(MinThread) 값 T 는 2 의 배수에 해당하는 값을 가질 수 있다. T 를 8 이라 하자. WebtoB 의 MaxProc(MinProc)값은 S*(T/H) 보다 커야하고 서블릿 엔진의 수가 3 이므로 MaxProc 값은 3*(8/2) = 12 보다 커야한다. 이 값을 이용하여 container.xml 과 http.m 을 작성하면 아래와 같다.

< container.xml >


Port="9900"





<ThreadPool MinThread="8" />

</Connection>


Port="9900"





<ThreadPool MinThread="8" />

</Connection>

< http.m >

*NODE

foo …

HTH = 2,

JSVPORT = 9900,

…

*SVRGROUP


*SERVER


*URI



*EXT



3.5 Application 권한부여 설정

Web Container 에는 servlet specification 2.3 사양의 보안 기능이 구현이 되어 있으므로 이 기능을 설정하여 사용자에 따라 Application 의 실행을 제한하는 권한을 부여할 수 있다.

보안 절차는 크게 인증(authentication) 과정과 권한 부여(authorization) 과정으로 구성된다. Servlet specification 2.3 PFD2(proposed final draft2)에는 Basic Authentication, Digest Authentication, HTTPS Client Authentication, Form Based Authentication 과 같은 4 가지 인증 방법을 제시하고 있는데,

WebtoB Web Container 는 이 중 필수적 요소인 Basic Authentication 을 지원하고 있다.

권한 부여를 하기 위해서는 Application 설정 파일(web.xml)에 권한 부여 관련 설정을 해 주어야 한다. 다음은 특정 URL 형태의 모든 요청에 대한 실행 권한을 제한하는 예이다.

<security-role>

<role-name>manager</role-name>

</security-role>

<security-role>

<role-name>developer</role-name>

</security-role>

<security-constraint>

<web-resource-collection>

<url-pattern>/jsp/*</url-pattern>

<http-method>GET</http-method>

<http-method>POST</http-method>

</web-resource-collection>

<auth-constraint>

<role-name>manager</role-name>

</auth-constraint>

</security-constraint>

위의 예에서 <security-role> 태그를 사용하여 Web Container 에서 권한을 부여할 롤 이름을 설정한다. 여기서는 manager 와 developer, 두 가지의 롤 이름을 설정하였다. 그리고 <security-constraint> 태그를 설정함으로써 특정 Application 들의 사용을 제한할 수 있다. <security-constraint> 태그의 각 요소에 대한 설정은 다음과 같다.

<url-pattern> : 실행을 제한하고자하는 Application 의 URL 형태를 설정한다. 예와 같이 ‘*’를 사용하여 특정 URL 을 포함하는 모든 Application 의 실행을 제한할 수도 있다.

<http-method> : HTTP method 들 중에 어떤 method 들에 대해서 제한을 가할 것인지 결정한다. 하나 이상 설정 가능하다.


<auth-constraint> : <role-name> 요소에 권한이 부여된 롤 이름을 설정한다. <role-name> 요소는 하나 이상 설정 가능하다.

위의 예와 같은 설정에서는 manager 라는 롤 이름을 가진 사용자만이 /jsp/ 아래의 모든 Application 에 대한 GET 이나 POST method 들을 실행시킬 수 있는 권한을 가지게 된다.

이와 같이 <security-constraint> 태그를 여러 개 설정함으로써 실행을 제한하고자 하는 Application 들을 설정할 수 있다.


3.5.1 Security 관련 container.xml 의 설정

위의 예제에서 보인 web.xml 에는 role name 인 manager, developer 를 명시하였으나 이 role 에 어떤 사용자(user)가 속하는지를 설정하지는 않는다. web.xml 은 그 자체로 다른 Web Application 서버 환경에서도 운용해야하므로 사용자 설정과 같은 사이트 종속적인 요소는 결정할 수 없다. 따라서, role 에 속할 사용자의 설정은 Web Application 을 배치(deployment)할 때 정해주어야 한다. container.xml 의 <Context>의 구성 요소인 <RoleMapping> 태그를 사용하여 이를 설정할 수 있다. 아래에 manager, developer role 에 사용자(user)를 할당하는 예를 나타내었다.

<Context ContextName=”examples”

ContextPath=”/examples”

DocBase=”examples”>

….

……

<RoleMapping>

<Role RoleName=”manager”>

<UserName>jeus</UserName>

<UserName>tmax</UserName>

</Role>

<Role RoleName=”developer”>


<UserName>travis</UserName>

<UserName>group1</UserName>

</Role>

</RoleMapping>

….

……

</Context>

role 에 사용자를 할당하는 태그는 <RoleMapping> 태그이다. 이 태그는 <Context> 태그의 하위 구성 요소이다. RoleMapping 태그는 한 개 이상의 <Role> 태그로 구성된다. 예제에는 “manager” role 과

“developer” role 을 위해 두개의 <Role> 태그가 존재한다. <Role> 태그에는 이 role 에 속할 user 를 설정하는데 한 개 이상의 <UserName> 태그로 구성된다.


3.6 Naming 설정

Web Container 에서는 J2EE specification 을 따르는 외부 자원에 접근할 수 있도록 여러 가지 설정을 가지고 있다. web.xml 에 설정하는 <resource-env-ref>, <resource-ref> 태그가 이러한 목적에 사용하기 위해 설정하는 태그이다.

Web Application 을 배치(deploy)할 때 이러한 외부 자원에 대한 레퍼런스(reference)를 이용하기 위해서는 JNDI 에 등록된 실제 자원의 export name 과 web.xml 에 등록된 레퍼런스 이름(reference name)을 링크(link)해 주어야 한다.

container.xml 의 <Context> 택그의 하위 구성 요소인 <ResourceEnvRef>, <ResourceRef> 태그를 이용하여 web.xml 의 자원 레퍼런스와 실제로 JNDI 에 등록된 자원을 링크시킬 수 있다.

예를 들어 web.xml 에 다음과 같이 자원 레퍼런스가 등록되었다고 하자.

<resource-ref>

<res-ref-name>jdbc/EmployeeAppDB</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-auth>Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

<resource-env-ref>

<resource-env-ref-name>jms/StockQueue</resource-env-ref-name>

<resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>

</resource-env-ref>

위의 web.xml 설정을 배치(deploy)시에 WebtoB Servlet Engine 시스템의 실제 등록 자원으로 링크시키려면 container.xml 의 해당 <Context> 태그에 아래와 같이 등록한다. 각 태그 내부의 <JndiName>은 WebtoB Servlet Engine 시스템의 JNDI 에 등록된 자원의 export name 이다.

<ResourceRef>

<ResourceRefName>jdbc/EmployeeAppDB</ResourceRefName>

<JndiName>MyEmployeeAppDB</JndiName>

</ResourceRef>

<ResourceEnvRef>

<ResourceEnvRefName>jms/StockQueue</ResourceEnvRefName>

<JndiName>MyStockQueue</JndiName>

</ResourceEnvRef>

3.7 그 외의 설정

앞에서 다룬 설정 외에도 Container 에서 설정할 수 있는 것들은 다음과 같은 것들이 있다.

Logging : Container 에서 error 나 access, user log 들을 남기는 것

을 설정한다.

ResponseHeader : Container 가 client 로 보내는 응답의 헤더를 설정한다.

ActiveManagement : Container 에 어떤 이벤트가 발생했을 때 Container 가 취하는 행동을 설정한다.


이 각각에 대한 설정은 5 장 container.xml Reference 를 참조하기 바란다.

4 Container.xml Reference

container.xml 에서는 여러 가지 Container 의 설정을 할 수 있다. 이 파일은 WebtoB Servlet Engine 디렉토리의 config 디렉토리 내에 (node 이름)_servlet_(엔진 이름) 디렉토리 내에 있다(엔진 이름은 Web Container 의 이름을 말한다). 이 파일들은 지정된 node 와 Container 에 대한 설정을 담당하고 있다. 여기서는 각각의 Container 설정에 대해서 알아 보기로 한다.

여기서 각각의 태그 설명시 필수 요소는 required, 필수 요소는 아니지만 명시적으로 설정해 주는 게 좋은 요소는 recommend, 꼭 사용할 필요가 없는 옵션 요소는 optional 로 표시한다.


4.1 container.xml 의 구성

container.xml 은 web.xml 과 마찬가지로 XML 파일이므로 XML 의 형식을 따른다. 따라서 DTD 도 가지고 있다. 이 DTD 는 WebtoB Servlet Engine 이 설치된 디렉토리의 /config/dtds/web-container_3_0.dtd 이다. 그리고 container.xml 의 처음 부분은 다음과 같은 문구로 시작한다. 이 예에서는 WebtoB Servlet Engine 가 D 드라이브의 Jeus 라는 디렉토리에 설치되어 있다.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE Container PUBLIC '-//Tmax Soft., Inc.//DTD Web

Container//EN' 'file:/// d:/jeus/config/dtds/web-

container_2_0.dtd'>

Container 의 설정을 담당하는 모든 태그는 <Container> 태그의 하위 요소로 <Container> 태그 안에 존재한다. 즉, web.xml 이 <web-app> 태그 안에 모든 태그들을 담고 있는 것과 마찬가지로 container.xml 에서는 <Container> 태그 안에 모든 태그가 존재한다. 이 태그를 사용한 예는 다음과 같다.

<Container MonitoringIntval="300"

RedirectStdOut="false"

RedirectStdErr="false">

…

</Container>

<Container> 태그의 속성은 다음과 같이 세가지가 있다.

MonitoringIntval [ (recommand) default : 300 (단위 : 초) ]: Container 에서는 사용하고 있는 많은 자원들(쓰레드나 세션 객체 등)을 주기적으로 관리하고 있다. 이때 관리하는 시간간격을 조절하는데 이 속성이 사용된다. 먼저 Container 에서 주기적으로 수행되는 작업에는 다음과 같은 것들이 있다.

쓰레드 풀에 정해진 시간(MaxIdleTime) 이상 사용되지 않은 쓰레드가 있는지 확인하여 제거시켜 준다.

세션 객체 중 정해진 시간(session timeout)이상 접근되지 않은 객체를 메모리 상에서 제거시킨다.

데이터베이스 연결 풀링(DB connection pooling)을 할 경우 정해진 시간(maxIdleTime) 이상 사용되지 않은 연결은 물리적인 연결을 종료한다.

파일에 기록이 되지 않고 로그버퍼에 남아 있는 내용을 파일에 써 준다.

위와 같이 주기적으로 사용되지 않는 자원들을 해제함으로써 Container 가 필요 이상의 자원을 가지고 시스템의 자원을 낭비하는 것을 막을 수 있다. 단위는 초(seconds)이고 디폴트 값은 300 초, 즉 5 분이다.

이 시간 간격을 짧게 할 경우에는 더 많은 빈도로 자원들이 체크됨으로써 필요없는 자원들이 빨리 제거가 되는 장점이 있는 반면 위의 작업들을 자주 수행하기 위해 Container 의 성능이 저하시키는 원인이 될 수 있다. 따라서 이 시간 간격을 적절히 조절하는 것이 필요한데 대략 2 ~ 7 분 정도 사이로 하면 적당하다.


RedirectStdOut [(recommand) default : true] : servlet 이나 JSP 에서 Systemout 객체를 사용하여 어떤 내용을 출력하면 기본적으로 표준 출력, 즉 화면으로 출력이 된다(System.out.println()). 하지만 경우에 따라서는 이러한 출력이 파일로 되기를 원할 수 있다. 예를 들어, 개발시에 디버깅을 목적으로 System.out 객체를 많이 사용하는데 여러 개발자가 동시에 Container 를 사용할 경우 화면으로 출력되면

디버깅에 사용하기가 어렵다. 이런 경우 파일로 저장하면 디버깅에 용이하다. 이 속성에서 가질 수 있는 값은 true 와 false, 두 가지이고 디폴트값은 true 이다. 이 값이 false 로 설정할 경우 보통처럼 화면으로 출력하는 것이다. 반면 true 로 설정할 경우 화면으로 가는 출력이 파일로 전환(redirection)된다. 이 때 파일은 %W2B_JEUSHOME%\enginename 디렉토리에 stdout_날짜.log 라는 이름으로 생성이 되고 기록된다(%W2B_JEUSHOME%은 WebtoB Servlet Engine 이 설치된 디렉토리를 가리키고 enginename 은 실행되고 있는 Web Container 의 이름을 가리킨다). 예를 들어 % W2B_JEUSHOME %이 “c:\webtob\jeus”이고 enginename 이 “webdev_servlet_engine1” 이며 W2B_JEUSHOME 를 기동시킨 날짜가 2001 년 10 월 1 일이라면 로그파일의 위치 및 이름은 c:\webtob\jeus\logs\webdev_servlet_engine1\stdout_10012001.log” 이다.

RedirectStdErr [ (recommand) default : true ] : 위의 RedirectStdOut 와 거의 같은 기능을 하는 속성으로 다만 System.out 이라는 객체 대신 System.err 이라는 표준 에러 출력에 관련된 내용이다(System.err.println()). 보통 자바에서 exception 객체의 printStackTrace() 함수를 실행시키면 System.err 로 출력이 된다. 따라서 이 속성을 true 로 할 경우는 파일로 출력이 된다. 이 속성이 가질 수 있는 값은 true 와 false, 두 가지이고 디폴트값은 true 이다. 이 값이 true 로 설정할 경우 RedirectStdOut 과 같은 디렉토리에 파일로 저장되며 파일의 이름은 “stderr_날짜.log”이다. RedirectStdOut 에서 보인 예제 환

경 에 서 이 값 을 true 로 하 면 “c:\webtob\jeus\logs\webdev_servlet_engine1\stderr_10012001.log” 라

는 파일에 저장된다.

4.2 ContextGroup

컨텍스트 그룹은 <Container> 태그 안에서 <ContextGroup> 이라는 태그로 설정한다. ContextGroup 에 관한 부분이 사실상 거의 모든 Container 의 중요한 설정을 포함하고 있다.

ContextGroup 태그는 하위에 다음과 같은 태그들을 포함하고 있다.

JSPEngine : Web Container 내의 JSP 엔진에 관한 설정


Logging : 로깅에 관한 설정

Context : 컨텍스트에 관한 설정

Connection : 웹서버와의 연결에 관한 설정

DistributedSession : 세션 클러스터링에 관한 설정

ResponseHeader : 응답헤더에 관한 설정

ActiveManagement : 능동적 관리에 관한 설정


이 태그를 설정한 예는 다음과 같다.

<Container MonitoringIntval="60"

RedirectStdOut="false"

RedirectStdErr="false">

<ContextGroup GroupName="MyGroup"

GroupDocBase="webapps"

SharedSession="true"

SessionTimeoutMinute="20"

PrintErrorToBrowser="false">

<JSPEngine KeepGenerated="false" />

<Logging ErrorLog="default"

ErrorLogLevel="warning"

ErrorLogBufferSize="0"

ErrorLogValidDays="2"

UserLog="default"

UserLogBufferSize="512"

UserLogValidDays="2"

AccessLog="default"

AccessLogBufferSize="1024"

AccessLogValidDays="1"

AccessLogFormat="Default"/>

<Context ContextName="Examples"


DocBase="examples"

AutoReload="true">

<AllowIndexing>

<Directory>/</Directory>

<Directory>/images/</Directory>

</AllowIndexing>

<DenyDownload>

<File>/a.dat</File>


<Extension>java</Extension>

<Extension>class</Extension>

<Extension>jsp</Extension>

<Directory>/WEB-INF/classes/</Directory>

</DenyDownload>

<Aliasing>

<Alias AliasName="/data/"

RealPath="c:\webcontents\data/"/>

<Alias AliasName="/images/" RealPath="

c:\webcontents\images\"/>

</Aliasing>

<FileCaching MaxIdleTime="300" MaxCacheMemory="1">



</FileCaching>

</Context>


Port="9900"





MaxThread="10"

ChangeRate="2"

MaxIdleTime="300"

MaxWaitQueue="4" />

</Connection>




InitCapacity="1"

MaxCapacity="3"

IncrementRate="1"


</SessionServer>


</ContextGroup>

</Container>

<ContextGroup> 태그 자체의 예를 다시 나타내면 다음과 같다. 여기서 나타나는 여러가지 속성들은 다음과 같다.

<ContextGroup GroupName="MyGroup"

GroupDocBase="webapps"

SharedSession="true"

SessionTimeoutMinute="20"

DefaultCharset="8859_1"

PrintErrorToBrowser="false"

ServletHome="/webcontents/">

GroupName [ (required) default : null ] : 이 속성의 값은 ContextGroup 의 이름으로서 Container 내부적으로 다른 그룹들과의 구별을 위해서 사용되며 관리 툴에서 특정 그룹에 명령을 내리기 위해 사용된다. 이 속성의 값이 될 수 있는 것은 스트링 값이고 반드시 설정해야 한다. GroupName 은 Container 태그 내에서 유일한 값이어야 한다.

GroupDocBase [ (required) default : null ] : 이 속성에는 ContextGroup 의 document base 로서 ContextGroup 에 속한 컨텍스트들이 놓이게 될 디렉토리를 지정한다. 이것은 아래에서 설명할 SERVLET_HOME 속성에 지정된 디렉토리(기본값 %W2B_JEUSHOME%\webhome\servlet_home 아래 디렉토리의 이름을 지정한다. 이 속성의 값은 스트링 값이고 반드시 설정해야 한다. 이 값을 webapps 라고 지정하였다면 예제 환경에서 c:\webtob\jeus\webhome\servlet_home\webapps 가 ContextGroup 의 document base 가 된다.

ServletHome [ (optional) default : null ] : 위에서 설명한 것과 같이 WebtoB Web Container 에서는 일반적으로 servlet 이나 JSP 등이 놓이는 디렉토리의 상위 디렉토리, 즉 W2B_SERVLETHOME 을 install 과정이나 환경변수에서 지정하면 된다. 하지만 위의 설정과 상관없이 container.xml 에서 설정하길 원할 때 이 속성을 사용한다. 이 속성이 지정되면 Web Container 실행 스크립트 파일에서 지정된 것보다 우선한다.

Note: 이 속성에는 스트링 값을 넣어야 하고 절대경로를 설정해야 하며 마지막은 디렉토리 구분자(‘/’ 혹은 ‘\’)로 끝나야 한다.


SharedSession [ (optional) default : false ] : 기본적으로 세션 객체는 Web Application(컨텍스트) 단위로 관리하기 때문에 다른 컨텍스트의 세션 객체는 참조할 수 없다. 즉 A 라는 컨텍스트에서 어떤 사용자가 만든 HttpSession 객체는 B 라는

컨텍스트에서는 동일한 사용자라 하더라도 사용할 수 없다. 하지만 경우에 따라서 컨텍스트간 세션이 공유가 되는 것이 필요할 수 있다. 이 경우 이 속성을 true 로 설정하면 컨텍스트간 세션을 공유할 수 있게 된다. 가질 수 있는 값은 true 혹은 false 이고 기본값은 false 이다.

SessionTimeoutMinute [ (optional) default : -1 (단위 : 분) ] : 이 속성은 위의 SharedSession 속성을 true 로 할 경우 세션 객체의 타임아웃을 정하는 것이다. 이 시간 간격동안 세션 객체가 사용되지 않았다면 메모리에서 제거된다. servlet specification 에 의하면 세션 객체의 타임아웃은 web.xml 에 <session-timeout> 태그로 설정하게 되어 있다. SharedSession 속성을 true 로 하여 컨텍스트간 세션 객체를 공유하게 될 떄에는 동일한 타임 아웃을 적용해야 하므로 web.xml 에 설정된 타임 아웃 값을 무시되고 이 값이 이 컨텍스트 그룹에 속한 모든 컨텍스트의 세션 타임 아웃 값이 된다. 단위는 분이고 기본값은 –1 로서 타임아웃이 없다는 것을 의미한다. 즉, 이 값이 음수인 경우 타임아웃 체크를 하지 않는데 이 경우 Container 가 종료가 되기 전까지는 세션이 항상 메모리 내에 남아 있게 되어 필요이상의 자원을 허비하게 된다. 따라서 적당한 시간을 주는 것이 바람직하다.

SessionTimeoutMinute [ (optional) default : -1 (단위 : 분) ] : 이 속성은 위의 SharedSession 속성을 true 로 할 경우 세션 객체의 타임아웃을 정하는 것이다. 이 시간 간격동안 세션 객체가 사용되지 않았다면 메모리에서 제거된다. servlet specification 에 의하면 세션 객체의 타임아웃은 web.xml 에 <session-timeout> 태그로 설정하게 되어 있다. SharedSession 속성을 true 로 하여 컨텍스트간 세션 객체를 공유하게 될 떄에는 동일한 타임 아웃을 적용해야 하므로 web.xml 에 설정된 타임 아웃 값을 무시되고 이 값이 이 컨텍스트 그룹에 속한 모든 컨텍스트의 세션 타임 아웃 값이 된다. 단위는 분이고 기본값은 –1 로서 타임아웃이 없다는 것을 의미한다. 즉, 이 값이 음수인 경우 타임아웃 체크를 하지 않는데 이 경우 Container 가 종료가 되기 전까지는 세션이 항상 메모리 내에 남아 있게 되어 필요이상의 자원을 허비하게 된다. 따라서 적당한 시간을 주는 것이 바람직하다.


ForcedRequestEncoding [ (optional) default : null ] : 이 항목이 설정되어 있으면 웹 클라이언트가 보내는 request 정보(헤더 및 데이터)는 무조건 이 값을 문자셋으로 하여 변환된다.

URLConnection 을 이용한 클라이언트가 있을 경우 유용하다. WebContainer version 2.5.11 이하에서 사용하는 DefaultCharset 과는 호환되지 않는다. 2.5.11 이하 버전과 호환되는 것은 DefaultRequestEncoding 이다.

DefaultRequestEncoding [ (optional) default : null ] : WebContainer version 2.5.11 이하 버전에서의 DefaultCharset 과 동일한 설정이다. 2.5.11 이하 버전에서 업그레이드 하는 경우 DefaultCharset 은 설정하면 안되며 대신 이 값을 설정한다. 이 설정을 삭제하여도 업그레이드시 문제가 거의 없을 것이다.

DefaultResponseEncoding [ (optional) default : null ] : 서블릿에서 HttpServletResponse.setContentType(“text/html”) 로 만 설 정 하 거 나 JSP 의 page directive 에서 contentType=”text/html”이라고만 설정

하였지만 서블릿 이나 JSP 작성시 한글을 사용한 경우에 한글

을 깨지지 않게 web client 로 전달하고 싶을 때 사용한다.

PrintErrorToBrowser [ (optional) default : false ] : 이 속성은 servlet 이나 JSP 를 수행 중 에러가 발생했을 때 자세한 에러 내용을 웹브라우저에게도 보여줄 것인지를 설정하는 것이다. 이 속성에서 가질 수 있는 값은 true 혹은 false 이며 디폴트는 false 이다. 기본적으로 에러가 발생했을 때 그 내용은 에러 로그파일에 기록이 된다. 하지만 개발기간 중에는 여러 명의 개발자가 한 Container 를 공유하기 때문에 에러가 발생했을 때 에러 로그파일에 기록되는 내용을 자신의 브라우저로 보여주는 것이 좋다. 이 속성을 true 로 할 경우 에러에 대한 자세한 정보를 자신의 브라우저로 볼 수 있다. 하지만 실제환경에 적용시킬 경우에는 false 로 하여 만약 에러가 발생했을 때 일반 사용자들에게는 간단한 에러 내용만 보이도록 하는 것이 좋다. 이렇게 하는 방법은 JSP page 에서 errorpage 를 사용하거나 web.xml 에서 error page 를 설정하는 방법이 있다.


4.2.1 <Context> 태그 – 컨택스트 설정

<context> 태그는 이 컨텍스트 그룹으로 지정된 디렉토리(GroupDocBase) 내에 존재하는 servlet 이나 JSP 문서의 모임인 Web Application 을 WebtoB Web Container 에 등록하기 위해 사용한다. <context> 태그로 지정되어 있지 않은 Application 은 WebtoB Web Container 에서 그 존재를 알지 못하므로 WebtoB Servlet Engine 에서 실행될 수가 없다. 따라서 모든 Web Application 은 <context> 태그로


등록해야 WebtoB Servlet Engine 에서 사용할 수 있다. 이 태그의 속성을 모두 사용한 예는 다음과 같다.

<Context ContextName="Examples"


DocBase="examples"

AutoReload="true"

UserLog="default"


UserLogValidDays="1" >

<AllowIndexing>



</AllowIndexing>

<DenyDownload>

<File>/product.dat</File>

<Extension>exe</Extension>

<Extension>dat</Extension>

<Directory>/store/</Directory>

</DenyDownload>

<Aliasing>

<Alias

AliasName="/images/"RealPath="c:\webcontents\images\"/>

<Alias AliasName="/data/"

RealPath="c:\webcontents\data\"/>

</Aliasing>




</FileCaching>

<AddedClassPath>

<ClassPath>c:\mylib\lib1\</ClassPath>


</AddedClassPath>

<RoleMapping>

<Role RoleName=”manager”>

<UserName>tmax</UserName>


</Role>

</RoleMapping>

<ResourceRef>

<ResourceRefName>jdbc/EmployeeAppDB</ResourceRefName>

<JndiName>MyEmployeeAppDB</JndiName>

</ResourceRef>

<ResourceEnvRef>

<ResourceEnvRefName>jms/StockQueue</ResourceEnvRefName>

<JndiName>MyStockQueue</JndiName>

</ResourceEnvRef>

</Context>

이 태그의 속성들을 살펴 보면 다음과 같다.

ContextName [ (required) default : null ] : 이 속성은 Container 내부적으로 각 컨텍스트들을 구별하기 위해 사용하고 관리 툴을 사용하여 컨텍스트들에 명령을 내리고자 할 때 사용된다. 위의 예에서는 Examples 로 지정이 되어 있다.

ContextPath [ (required) default : null ] : 이 속성에는 컨텍스트가 불려지는 URI 를 지정하는 것이다. 위의 예에서처럼 만약 /examples 라고 지정하였을 경우 URI 가 /examples 로 시작하는 경우 Examples 라는 컨텍스트의 자원들에 대한 요청으로 인식한다.

Note : 이것은 ‘/’로 시작하여야 한다.

DocBase [ (required) default : null ] : 컨텍스트의 document base 로서 컨텍스트에 속한 servlet 이나 JSP 와 같은 자원들이 놓여지는 디렉토리를 지정한다. 이 디렉토리는 컨텍스트가 속한 컨텍스트 그룹의 document base 아래의 하위 디렉토리가 된다. 예를 들어 위의 예에서 컨텍스트 그룹의 document base 가 c:\webtob\jeus\webhome\servlet_home\webapps 이고 이 속성이 examples 라고 지정되어 있는 경우 이 컨텍스트에 속한 servlet 이나 JSP 들은 모두 c:\ webtob\jeus\webhome\servlet_home\webapps\examples 아래에 놓이게 된다.

Note : 이 경로는 반드시 GroupDocBase 에 대한 상대경로로 지정해야 한다 (“/”로 시작해서는 안된다).


AutoReload [ (recommand) default : false ] : servlet 의 클래스들이나 JSP 의 자바빈(JavaBeans)이나 커스텀 태그(Custom tag)의 클래스들이 변경이 되었을 때 자동으로 변경된 클래스를 재로딩할 것인지를 설정한다. 이것은 servlet 이나 JSP 의 요청이 있을 때 그 파일들의 소스와 클래스 파일의 마지막 수정

날짜를 비교하여 소스가 더 최근에 변경이 되었다면 원래 메모리에 있던 클래스는 제거해 버리고 새로운 클래스를 메모리로 로딩시키는 것이다. 하지만 매번 request 가 들어 올 때마다 변경여부를 체크해야 하기 때문에 응답시간에 약간의 지연이 생기게 된다. 따라서 개발기간에는 이 속성을 true 로 하고 개발이 완료되어 적용이 되는 상황에서는 false 로 두는 것이 바람직하다. 하지만 servlet 과는 달리 JSP 문서는 이 속성의 값과 무관하게 소스가 변경이 되면 바로 변경된 것이 적용이 된다. 가질 수 있는 값은 true 혹은 false 이고 디폴트는 false 이다. 클래스 리로딩시 컨텍스트 내부의 모든 클래스들이 같이 리로딩된다. 따라서, 내부의 세션 객체들이 모두 제거됨을 주의해야 한다. 단 JSP 클래스가 변경된 경우는 해당 JSP 클래스만 리로딩된다.

UserLog [ (optional) default : null ] : 이 속성은 <ContextGroup> 태그 내의 하위 요소인 <Logging> 태그에 포함되어 있는 UserLog 속성과 같은 것으로 WebtoB Web Container 에서 제공하는 3 가지 로그(에러 로그, 유저 로그, 액세스 로그)중 유저 로그는 각 컨텍스트마다 다른 파일을 지정할 수 있다. UserLog 의 자세한 설정은 Logging 태그에서 UserLog 를 설정하는 부분에서 설명되어 있다. 다만 Logging 태그에서의 UserLog 설정과 차이점이라고 한다면 “default”라고 설정하였을 경우, user.log 라는 파일에 기록이 되는 것이 아니고 컨텍스트의 이름과 같은 로그 파일이 생성되고 기록된다. 예를 들어 위의 Examples 컨텍스트에서는 Examples.log 라는 로그 파일이 된다. 개발 중이나 운영 중에 특정 컨텍스트의 로그를 구분해서 볼 필요가 있을 때 이 속성을 설정하여 독립적인 로그 파일에 기록이 되게 한다. 디폴트는 설정하지 않는 것으로 Logging 태그에 설정된 유저 로그를 함께 사용하게 된다.

UserLogBufferSize [ (optional) default : 512 ] : 유저 로그의 버퍼 사이즈를 설정하는 것으로 자세한 내용은 Logging 태그의 UserLogBufferSize 속성을 참조하기 바란다.


UserLogValidDays [ (optional) default : -1 ] : 유저 로그 파일을 몇 일마다 새로 만들 것인가 설정하는 것으로 자세한 내용은 Logging 태그의 UserLogBufferSize 속성을 참조하기 바란다.

4.2.1.1 <Context> 태그의 하위 요소들

<Context> 태그는 여러 개의 하위 요소를 가지고 있다. 이 태그들은 다음과 같다.

<AllowIndexing> [ (optional) default : null ] : 브라우저에서 요청하는 URI 가 servlet 이나 JSP, 정적인 파일들을 요청하는 것이 아니고 ‘/’로 끝나는 경우에는 Web Container 는 가장 먼저 web.xml 의 welcome-file-list 태그에 설정되어 있는 파일들이 있는지 찾아 본다. 보통 welcome-file-list 에는 index.htm, index.html, index.jsp 등을 설정해 두는데 만약 요청한 디렉토리에 이러한 파일들이 있으면 그 파일을 보내 주고 없을 경우에는 디렉토리 이름만 표시한다. 하지만 경우에 따라서는 디렉토리를 요청하는 경우 그 디렉토리 아래의 파일들과 하위 디렉토리들을 리스트해 보여 주는 것이 필요할 수 있다. 이 때 이 태그를 사용하여 그렇게 해 주기를 원하는 URI path 를 설정하면 된다. 여기서 URI path 라는 것은 ContextPath 로 설정해 놓은 URI path 다음에 올 path 를 말하는 것이다.

예제 환경에서 컨텍스트의 ContextPath 가 /examples 이고 그 아래의 html 과 images 라는 디렉토리의 파일들이 리스팅되는 것을 허용하고자 할 때 다음과 같이 설정하면 된다.

<AllowIndexing>

<Directory>/html/</Directory>


</AllowIndexing>

주의할 점은 path 의 처음과 끝이 ‘/’이어야 한다는 것과 실제 물리적인 디렉토리의 경로가 아니고 브라우저로부터 요청되어 오는 URI path 의 일부라는 것이다 (즉, windows 환경에서 file seperator 인 “\”를 사용해서는 안된다).

이 태그를 설정하지 않는 경우 기본적으로 모든 디렉토리는 인덱싱이 되지 않는다.


<DenyDownload> [ (optional) default : null ] : 컨텍스트에 포함된 servlet 이나 JSP 문서 같은 자원들 중에서 브라우저에서 오는 요청으로 파일이 다운로드 될 수 있는 것을 막고 싶을 때 이 태그를 사용한다. 여기에 설정할 수 있는 것은 세 가지 종류가 있다.

File 태그 : 특정 파일이 다운로드되는 것을 막는다.

Extension 태그 : 특정한 확장자를 가지는 파일들의 다운로드를 막는다.

Directory 태그 : 특정한 디렉토리 아래의 파일들의 다운로드를 막는다.

위에서 File 과 Directory 는 ContextPath 아래부터의 상대적인 URI path 로 설정한다. 예를 들어 ContextPath 가 /examples 이고 그 아래의 data 디렉토리의 customer.dat 라는 파일이 있을 때 디폴트로는 다음과 같이 요청하면 customer.dat 파일이 다운로드 된다.

http://localhost:8088/examples/data/customer.dat

이 파일이 다운로드되지 않게 하려면 위의 3 가지 방법 중 하나를 선택하면 된다. 이때에 브라우저에서 해당 파일에 대한 요청이 오면 다운로드가 되지 않고 파일이 존재하지 않는다는 메시지가 출력된다. 이들 방법은 다음과 같다.

아래와 같이 customer.dat 파일만 다운로드 되지 않도록 명시하는 것이다.

<DenyDownload>

<File>/data/customer.dat</File>

<DenyDownload>

확장자로 dat 를 가지는 파일의 다운로드를 금지하도록 다음과 같이 설정할 수 있다.


<DenyDownload>

<Extension>dat</Extension>

<DenyDownload>

물론 위의 3 가지 방법은 모두 함께 설정될 수 있으며 세 가지 중 어느 하나의 조건에만 일치해도 다운로드는 되지 않는다.

Note : 디렉토리 구분자로는 “/”을 사용한다. Windows 환경의 디렉토리 구분자인 “\”을 사용하지 않도록한다.

Note : Container 에서 default 로 다운로드가 되지 않게 설정되어 있는 것이 있는데 /WEB-INF/ 디렉토리가 이에 해당한다. 이것들은 servlet 과 JSP 의 소스와 실행파일과 관련되어 있기 때문이다.

<Aliasing> [ (optional) default : null ] : 이 태그는 특정 URI path 로 결정되는 자원의 위치가 실제로는 다른 디렉토리에 존재할 때 사용하는 태그이다. Aliasing 태그를 사용하지 않는 경우, URI path 에서 요청하는 자원의 실제 위치는, URI path 에서 ContextPath 까지의 path 를 DocBase 의 실제 위치로 대체한 것이 된다. 예제 환경에서 Examples 컨텍스트의 DocBase 가 examples이고 ContextPath 가 /examples 이면 document base 의 실제 위치

는 c:\webtob\jeus\webhome\servlet_home\webapps\examples 이다.

요청된 URI가 http://localhost/examples/images/home.gif라고 하면 WebtoB Web Container 는 c:\webtob\jeus\webhome\servlet_home\webapps\examples\images\ 디

렉토리에서 home.gif를 찾는다. 하지만 home.gif가 그 디렉토리

에 있는 것이 아니고 c:\webcontents\images라는 디렉토리 아래

에 있 다 면 다 음 과 같 이 Aliasing 을 설 정 함 으 로 써 c:\webcontents\images에서 home.gif 파일을 가져 오게 할 수 있

다.

<Aliasing>

<Alias AliasName="/images/"

RealPath="c:\webcontents\images\"/>

</Aliasing>

복수개의 Aliasing 을 설정하고자 할 때는 각 Aliasing 마다 Alias 태그를 사용하면 된다. Alias 태그는 두 가지 속성을 가지는데 AliasName 은 Aliasing 을 원하는 URI path 를 지정하는 것이고 RealPath 는 실제 디렉토리의 절대 경로를 지정한다. AliasName 은 ‘/’로 시작하고 끝내야 하며 ContextPath 아래의 상대 URI path 가 된다. RealPath 는 반드시 절대 경로를 설정해야 하고 디렉토리 구분자로 끝나야 한다.


<FileCaching> [ (optional) default : null ] : HTML 문서나 이미지 파일들과 같은 정적인 자원들에 대한 캐싱을 할 것인지를 설정한다. 보통 자주 사용되는 파일들은 매번 디스크에서 읽어 오지 않고 메모리에 계속 둠으로써 성능향상을 가져 올 수 있다. 파일을 캐싱하는 단위는 디렉토리로서 만약 /images/라는 디렉토리를 설정하였다면 그 아래의 모든 파일들은 한번 사용된 후 캐싱이 되는 것이다. FileCaching 태그는 두 가지 속성을 가지는데 MaxIdleTime 과 MaxCacheMemory 이다. MaxIdleTime 은 캐싱되어 있는 파일들이 어느 시간동안 요청이 되지 않았을 경우 메모리에서 제거시킬 것인지를 설정하는 것으로 자주 사용되지 않는 파일을

캐싱에서 제거함으로써 자원을 효율적으로 사용할 수 있게 한다. 단위는 초로서 디폴트값은 –1 로 제거를 하지 않음을 뜻한다. MaxCacheMemory 는 캐싱할 메모리의 한계를 지정하는 것으로 너무 많은 파일을 캐싱함으로써 메모리를 낭비하는 것을 막을 수 있다. 단위는 MegaBytes 이고 디폴트값은 –1 로 제한이 없음을 뜻한다.

예를 들어 Examples 컨텍스트의 images 라는 디렉토리 아래의 파일들과 컨텍스트의 document base 아래의 파일들을 캐싱하고자 할 때 다음과 같이 설정하면 된다.




</FileCaching>

여기서 MaxIdleTime 은 300 초 (5 분)으로 MaxCacheMemory 는 1 MB 로 설정되었다.

<AddedClassPath>[ (optional) default : null ] : 컨텍스트의 기본 클래스 경로는 컨텍스트 DocBase 밑에 있는 \WEB-INF\classes 와 \WEB-INF\lib 및 \WEB-INF\lib 밑에 있는 jar 파일들이다. 이 경로는 ClassLoader 에 의해 동적으로 클래스를 로드하거나 JSP 파일로부터 생성된 서블릿 소스 파일을 컴파일 할 때 –classpath 옵션에 사용한다. 경우에 따라서 사용자는 위에 언급한 디렉토리 이외에 별도의 classpath 를 추가하고 싶을 경우가 있다. 이 경우 이 속성을 지정한다. AddedClassPath 는 하위 요소로 <ClassPath> 태그를 가지고 있으며 아래의 예제 처럼 설정하면 된다. 두개 이상의 클래스 경로를 추가 하고 싶으면 <ClassPath>를 수만큼 설정하면 된다.

<AddedClassPath>



</AddedClassPath>


<RoleMapping> [ (optional)] : 컨텍스트의 web.xml 에 <security-role> 태그가 존재하는 경우 사용하는 태그이다. <security-role> 태그는 이 Web Application 에서 security 목적으로 사용하는 role name 을 지정한다. 이 Web Application 을 WebtoB Web Container 에 배치(deploy)하여 사용할 때 security 설정이 제대로

동작하려면 이 role 에 사용자 또는 사용자 그룹을 등록해주어야 한다. 이 때 이 태그를 사용한다.

이 태그의 하위 요소로는 <Role> 태그가 있으면 <Role> 태그의 하위 요소로서 이 role 에 등록할 사용자 또는 사용자 그룹을 등록하는 <UserName> 태그가 있다.

Role [ (optional) ] : <RoleMapping> 태그의 하위 구성 요소이다. web.xml 에 등록된 <security-role>당 하나가 존재한다. 이 태그는 하나 이상 지정할 수 있다. 속성으로는 RoleName 이 있으며 반드시 설정해야한다. <RoleName> 태그의 값은 <security-role> 태그의 값과 일치해야 한다. 이 태그에는 다음과 같은 하위 요소가 있다.

UserName [ (optional) ] : RoleName 에 해당하는 role 에 등록할 사용자 또는 사용자 그룹을 지정하는 태그이다. 이 태그는 하나 이상 지정할 수 있다.

<ResourceRef> [ (optional)] : web.xml 에 <resource-ref> 태그로 등

록된 자원이 있을 경우 사용한다. <resource-ref> 태그 당 하나의 <ResourceRef> 태그가 존재한다 . <resource-ref>에 등록된 자원 레퍼런스를 WebtoB Web Container 의 JNDI 에 실제로 등록된 자원의 export name 으로 링크해주는 태그이다. 다음과 같은 하위 구성 요소가 있다.

ResourceRefName [ (optional)] : web.xml 에 등록된 <resource-ref> 태그내의 <resource-ref-name>의 값과 일치하는 값이다.

JndiName [ (optional)] : web.xml 에 등록된 <resource-ref> 태

그내의 <resource-ref-name>을 링크시킬 실제 자원의 이름이

다 . JNDI 에 등록된 해당 자원의 export name 으로 설정해야한다.

<ResourceEnvRef> [ (optional)] : web.xml 에 등록된 <resource-env-ref> 태그로 등록된 자원이 있을 경우 사용한다. <resource-env-ref> 태그 당 하나의 <ResourceEnvRef> 태그가 존재한다 . <resource-env-ref>에 등록된 자원 레퍼런스를 WebtoB Web Container 의 JNDI 에 실제로 등록된 자원의 export name 으로 링크해주는 태그이다. 다음과 같은 하위 구성 요소가 있다.


ResourceEnvRefName [ (optional)] : web.xml 에 등 록 된 <resource-env-ref> 태그내의 <resource-env-ref-name>의 값과 일치하는 값이다.

JndiName [ (optional)] : web.xml 에 등록된 <resource-env-ref> 태그내의 <resource-env-ref-name>을 링크시킬 실제 자원의 이름이다 . JNDI 에 등록된 해당 자원의 export name 으로 설정해야한다.

4.2.2 <JSPEngine> 태그 – JSP 엔진 설정

이 태그에서는 이 컨텍스트 그룹 내의 JSP 에 관련된 설정들을 한다. JSP 엔진과 관련된 속성을 설명하기 전에 우선 간단히 JSP 가 실행되는 과정을 설명하면 다음과 같다.

최초에 JSP 파일이 요청이 되면 우선 JSP 파일을 파싱한다. 이 때 각 JSP 태그들은 해당하는 자바 코드로 바뀌게 되고 HTML 문장들은 out.print()나 out.write()와 같은 출력함수의 인자로 넘어간다. 이렇게 하여 서블릿 소스(java)파일을 생성한다.

서블릿 소스 파일이 생성되면 자바 컴파일러를 실행시켜서 해당하는 클래스 파일을 만들어 내고 이 클래스를 실행한다. 이 과정들은 각 JSP 파일에 대해 한 번만 일어나게 되고, 이후에는 만들어진 클래스 파일을 사용하게 된다. 단, JSP 파일의 변화가 있으면 위의 과정을 다시 반복하여 새로운 클래스 파일을 만들어 낸다.

아래의 예는 이 태그의 5 가지 속성 모두를 설정한 경우의 예이다.

<JSPEngine KeepGenerated="true"

CompileEncoding="8859_1"

JavaCompiler="c:\java\bin\javac.exe"

CompileOutputDir=”c:\MyJspWork\”

JspWorkDir="c:\MyJspWork\"/>

각 속성의 의미는 다음과 같다.


KeepGenerated [ (recommand) default : false ] : JSP 파일을 파싱하여 만들어진 servlet 소스 파일을 제거할 것인지 그냥 둘 것이지를 묻는 속성이다. 이 값이 true 일 때는 그냥 남겨 두고 false 일 때는 제거한다.

생성된 servlet 소스파일을 두는 이유는 디버깅시에 이 파일을 보고 하는 것이 상당히 도움이 되기 때문이다. 또한 파싱에서는 문제가 없었지만 (즉 JSP 태그 규칙을 맞게 JSP 를 만들었지만) 컴파일에서 문제가 발생하는 경우 출력된 에러는 servlet 소스파일을 기준으로 어디에서 잘못되었는지를

표시하기 때문에 이 파일을 생성하게 하는 것이 도움이 될 수 있다.

가질 수 있는 값으로는 true 혹은 false 가 있으며 디폴트는 false 이다.

CompileEncoding [ (optional) default : null ] : Jsp 로부터 생성된 java 파일을 compile 할 때 –encoding 옵션에 지정하는 값이다. 이 속성을 지정하지 않거나 “UTF8”이 아닌 값을 지정하면 제우스 웹컨테이너가 적절한 encoding 값을 선정한다. 이 속성을 “UTF8”로 설정하면 –encoding 옵션에 “UTF8”을 지정한다.

JavaCompiler [ (optional) default : “sun.tools.javac” ] : 이 속성은 JSP 파일로부터 생성된 서블릿 소스 파일을 컴파일할 컴파일러를 지정한다. 기본값인 “sun.tools.javac”는 SUN 사의 JDK 를 설치하면 tools.jar 라는 라이브러리가 설치되는데 이 라이브러리안에 있는 컴파일러 도구이다.

새로운 프로세스를 포크하여 돌리는 방식이 아니기 때문에 javac 실행 파일보다 성능이 훨씬 좋다. 따라서, 특별한 경우가 아니면 기본값을 사용하기를 권장한다. 기본값외에 javac 실행파일을 컴파일러로 지정하려면 WebtoB Web Container 를 기동하기 전에 path 상에 javac 가 포함되어 있어야 한다.


JspWorkDir [ (optional) default : null ] : JSP 파일에 의해 생성된 servlet 소스파일과 클래스 파일들은 모두 jspwork 디렉토리 아래에 위치한다. 이 속성을 따로 지정하지 않는 경우 기본 값은 %W2B_SERVLET_HOME%\jspwork\enginename\GroupDocBase\DocBase 이다. 예제 환경에서 “Examples” 컨텍스트를 예로 들자면, Examples 컨텍스트의 DocBase 는 “examples”이므로 아래와 같다.

C:\webtob\jeus\webhome\servlet_home\jspwork\webdev_servle

t_engine1\webapps\examples

이 디렉토리는 디버깅을 제외하고는 사용자는 신경쓰지 않아도 되는 디렉토리이다. 기본값을 사용할 경우 주의 할 것은 % W2B_SERVLET_HOME % 아래에 jspwork 라는 이름의 컨텍스트 그룹 document base 를 설정하지 말아야 한다는 것이다.

Web Container 가 자동으로 만들어 주는 위치와 다른 위치를 원할 때는 이 속성을 이용하면 된다. 만약 이 값을 “c:\myJspWork\”라고 설정하였다면 “Examples” 컨텍스트의 jspwork 디렉토리는 다음과 같다.

C:\myJspWork\webapps\examples

경로는 절대 경로이어야 하고 디렉토리 구분자(‘/’, ‘\’)로 끝나야 한다.

CompileOutputDir [ (optional) default : null ] : JSP 파일에 의해 생성된 클래스 파일들을 jspwork 디렉토리가 아닌 다른 디렉토리에 둘 수 있다. 이 속성을 설정하지 않으면 클래스 파일들은 jspwork 디렉토리에 위치한다. 만약 이 값을 “c:\myJspWork\”라고 설정하였다면 “Examples” 컨텍스트의 CompileOutputDir 디렉토리는 다음과 같다.

C:\myJspWork\webapps\examples

경로는 절대 경로이어야 하고 디렉토리 구분자(‘/’, ‘\’)로 끝나야 한다.

4.2.3 <Logging> 태그 – 로그 설정

이 태그는 컨택스트 그룹에서 log 를 남기는 것에 관한 설정을 한다. WebtoB Servlet Engine 에서 지원하는 log 는 세가지가 있다. 이들은 다음과 같다.

에러 로그 (ErrorLog) : servlet 이나 JSP 를 실행하던 중 발생한 에러와 Container 에서 출력해 주는 정보등을 기록한다.

유저 로그 (UserLog) : 개발자가 로그를 남기기를 원할 때 ServletContext 의 log()라는 메쏘드를 사용하는데 이 로그들이 출력되는 방향이 유저 로그이다. JSP 에서는 Application 내장 객체의 log()를 사용한다. 다른 두 로그와는 달리 유저 로그는 각 컨텍스트마다 다른 파일로 출력하게 지정할 수 있다.

액세스 로그 (AccessLog) : Container 에 접속한 request 들에 대한 정보를 기록한다.


위의 로그 중 에러 로그와 유저 로그는 하나 이상 존재하지만 액세스 로그는 설정하지 않은 경우 로그가 남지 않는다. 그 이유는 에러 로그와 유저 로그에 비해 액세스 로그는 Container 에게 많은 부하를 줄 수 있기 때문에 원하지 않는 경우가 있을 수 있기 때문이다.

3 가지의 로그가 비슷한 방법으로 설정이 되는데, 아래의 예는 모든 속성을 다 설정한 경우의 예이다.

<Logging ErrorLog="console"

ErrorLogLevel="warning"

ErrorLogBufferSize="0"

ErrorLogValidDays="4"

UserLog="default"


UserLogValidDays="2"

AccessLog="default"

AccessLogBufferSize="1024"

AccessLogValidDays="1"

AccessLogFormat="default"/>

여기서는 이 각각의 log 에 관련된 속성들을 설명하고 예제 환경하에서 예를 들어보겠다.

ErrorLog [ (recommand) default : “default” ] : 이 속성이 4 가지 종류의 값을 가질 수 있는데 이것은 4 가지 다른 로그방향을 지정하는 것이다. 여기에는 “console”, “default”, 파일 이름, 절대 경로로 작성된 파일 이름(파일의 전체 경로) 이다.

console : 표준 출력, 즉 보통 화면으로 출력된다.

default : Container 가 지정한 디폴트 에러 로그 파일 (error.log)에 출력된다.

파일이름 : Container 의 디폴트 로그 디렉토리에 설정한 이름의 파일로 출력된다.

절대경로의 파일이름 : 설정한 디렉토리 아래 파일이름으로 출력된다.


default, 파일 이름과 같은 경우 파일들은 %W2B_JEUS_HOME%\logs\enginename\GroupName 디렉토리 아래에 생성되고 기록된다.

예를들면 c:\webtob\jeus\logs\webdev_servlet_engine1\MyGroup 이라는 디렉토리 아래에 error.log 라는 이름 혹은 사용자가 지정한 이름으로 생성된다. 이와 같이 정해진 디렉토리 아래에 로그 파일을 두지 않고 다른 위치에 두고 싶다면 절대 경로의 파일 이름을 기록하는 방법을 사용하면 된다.

예를 들어 c:\temp\logs\error_log 아래에 두고 싶다면 다음과 같이 설정하면 된다.

ErrorLog="c:\temp\logs\error_log”

ErrorLogLevel [ (recommand) default : warning ] : 로그에 기록할 에러의 단계는 다음과 같이 5 가지가 있는데 더 치명적인 에러부터 순서대로 나열되어 있다.

emergency : Container 가 정상적으로 실행되는데 문제를 일으키는 종류의 에러로 관리자의 긴급한 조치를 필요로 하는 것이다.

error : Container 의 실행에는 문제가 없지만 서비스의 응답에 문제가 있는 경우에 발생한다. 가장 대표적인 예가 servlet 이나 JSP 가 잘못 되어 예외를 발생시킬 경우이다.

warning : Container 나 서비스 실행에는 문제가 없지만 나중에 문제의 소지가 될 수 있는 것들이 이에 속한다.

information : 에러와는 상관없이 관리자에게 유용하다고 생각되는 정보들이 이에 속한다. 예로서 주기적으로 Container 를 모니터링한 결과들이 있다.

debug : 단지 디버깅을 위해 가능한 모든 정보를 기록하도록 하는 것이다.

위에서는 언급하고 있지 않지만 내부적으로 가장 치명적인 에러의 단계로서 fatal 을 두고 있다. 이것은 Container 가 다운시킬 수 있는 치명적인 에러들에 대한 단계로 container.xml 에 지정할 수 없고 어떤 단계를 지정하더라도 fatal error 는 무조건 로그에 기록된다.

어떤 단계가 설정되면 그 보다 더 치명적인 단계의 에러들은 모두 로그에 기록된다.예를 들어 warning 으로 지정이 된 경우 fatal, emergency, error, warning 단계의 모든 에러가 로그에 기록된다.

information 이나 debug 는 많은 내용을 로그하므로 필요할 때를 제외하고는 그 보다 높은 에러 레벨을 설정하는 것이 좋다.


ErrorLogBufferSize [ (optional) default : 512 (단위 : bytes) ] : 로그가 발생할 때마다 파일에 적는 것은 효율적이지 못하다. 따라서 Container 내부적으로 버퍼를 두고 버퍼에 지정된 양만큼 로그가 쌓이면 한번에 파일로 기록하게 된다. 이 속성은 그 버퍼의 크기를 설정하는 것이다.

이 값이 0 일 때는 버퍼링을 하지 않고 에러가 발생하는 즉시 로그 파일에 적게 된다. (log flushing) 실제 버퍼링을 할 경우 에러가 발생한 즉시 에러가 보이지 않을 수 있다. 따라서 에러를 바로 로그에 기록되게 하길 원할 때는 이 값을 0 으로 해야 한다. 또 하나 모아 두었던 버퍼의 내용이 로그에 기록되는 경우는 주기적인 모니터링 시간이 되었을 때이다. 0 이나 양수값을 가질 수 있으며 디폴트는 512 이고 단위는 bytes 이다.

ErrorLogValidDays [ (optional) default : -1 (단위 : days) ] : 이 속성에는 로그 파일이 유효한 기간을 설정한다. 오랜 기간동안 하나의 파일에 기록하다 보면 로그 파일이 원하는 이상 커질 수 있다. 이 값을 양의 정수로 설정할 경우 %W2B_JEUS_HOME%\logs\enginename\GroupName 아래 errorlog 라는 디렉토리가 생성되고 그 아래 로그 파일이 생성된 날짜가 포함되어 생성된다. 그리고 설정한 기간이 지나면 새로운 로그 파일이 생성된다. 예를 들어 ErrorLog=”default”이고 이 값이 1 로 설정되어 있을 때 현재 2001 년 10 월 1 일이라면 error_10012001.log 이라는 파일이 c:\webtob\jeus\logs\webdev_servlet_engine1\MyGroup\errorlog 라는 디렉토리 아래에 생성된다. 그리고 다음 날에는 error_10022001.log 이라는 새로운 파일이 생성되고 여기에 기록된다. 절대 경로의 파일 이름을 사용한 경우는 로그 파일의 상위 디렉토리에 errorlog 라는 디렉토리가 생성되고 그 아래 마찬가지로 에러 로그 파일 이름에 날짜가 포함되어 생성된다. 예를 들어 ErrorLog="c:\temp\website\logs\myerror” 라고 설정하였다면 c:\temp\logs\errorlog 라는 디렉토리에 myerror_10012001.log 이라는 파일이 생성된다.이 값을 설정하지 않거나 –1 로 설정할 경우 기간과 상관없이 하나의 파일에 기록된다. 디폴트값은 –1 이다.개발기간 동안 로그할 것이 많을 경우 이 값을 설정할 필요가 있으나 실제 운용할 때 로그에 기록될 양이 많지 않을 경우 이 기간을 크게 설정하거나 설정하지 않음으로써 필요 이상 로그 파일이 많이 생성되는 것을 막는 것이 좋다.


UserLog [ (optional) default : “default” ] : ErrorLog 설정과 같은 방법으로 설정하면 되고 다만 “default” 인 경우 파일이름이 user.log 라는 이름으로 생성된다는 차이가 있다. 만약 컨텍스트에 따로 유저 로그를 설정하였다면 여기서 설정한 유저 로그는 그 컨텍스트에서는 무시된다. 디폴트는 user.log 라는 파일이다.

UserLogBufferSize [ (optional) default : 512 ] : ErrorLogBufferSi-ze 설정과 같은 방법으로 설정하면 된다.

UserLogValidDays [ (optional) default : -1 (단위 : days) ] : Erro-rLogValidDays 설정과 같은 방법으로 설정하면 된다.

AccessLog [ (optional) default : “default” ] : ErrorLog 설정과 같은 방법으로 설정하면 되고 다만 “default” 인 경우 파일이름이 access.log 라는 이름으로 생성된다는 차이가 있다. 이 log 의 예는 다음과 같다. 즉, 요청이 들어온 시점, client 의 IP 주소, 요청한 URL 과 방법, 처리 결과로 나온 HTTP code, 처리하는데 걸린 시간 순으로 나온다.

[2000.01.01 20:22:17] 111.111.111.11 "GET /examples/context" 200

110ms

[2000.01.01 20:23:15] 111.111.111.12 "GET /examples/header" 200

70ms

[2000.01.01 20:24:29] 111.111.111.13 "GET /examples/forward2"

200 30ms

Note : ErrorLog 나 UserLog 와는 달리 이것을 설정하지 않으면 Container 에서는 액세스 로깅을 하지 않게 된다.

AccessLogBufferSize [ (optional) default : 1024 ] : ErrorLogBuffe-rSize 설정과 같은 방법으로 설정하면 된다. 자주 로깅이 일어나므로 버퍼 크기를 충분히 크게 하는 것이 좋다.

AccessLogValidDays (optional) default : -1 (단위 : days) : Error-LogValidDays 설정과 같은 방법으로 설정하면 된다. 많은 양이 로깅되므로 이 값을 작게 설정하여 로그 파일이 자주 바뀌도록 하는 것이 좋다.

AccessLogFormat [ (optional) default : “default” ] : 액세스 로그에 기록되는 로그의 형식을 설정한다. 현재는 디폴트 포맷만 지원한다.


4.2.4 <Connection> 태그 – 웹서버 연결 설정

이 태그는 이 컨텍스트 그룹에게 요청을 주는 웹 서버를 지정하는 것이다. WebtoB Servlet Engine 에서는 WebtoB 웹 서버와 연결을 지원하는데, 이는 다음과 같다.

WebtoB 웹서버 (WebtobListener) : WebtoB 웹서버와의 연결을 제공한다.

하나의 컨텍스트 그룹은 여러 개의 웹서버 연결을 가질 수 있다. 이때 지켜야 할 것은 각각의 연결마다 포트 번호가 달라야 한다는 것이다. 이렇게 여러 개의 웹서버 연결을 가지는 것은 웹서버가 여러 노드에 존재할 때나 다른 종류의 웹서버로부터 요청을 받을 때에 사용한다. WebtoB Servlet Engine 를 WebtoB 와 연결하기 위해서는 WebtoB Servlet Engine 의 container.xml 에서 지금 다루고 있는 <Connection> 태그를 설정하는 것 외에, WebtoB 의 설정도 수정해야 한다. 이들의 수정은 4 장 Container 의 설정의 웹서버의 WebtoB Servlet Engine 연결 설정 항목을 참고하기 바란다.

각 Connection 태그에는 연결을 위한 포트가 할당되고 효율적인 쓰레드 관리를 위한 쓰레드 풀 태그를 설정해야 한다.

4.2.4.1 <Connection> 태그 설정의 예

먼저 아래 예들은 웹서버의 종류에 따른 Connection 태그의 설정에 대한 예이다.

WebtoB 웹서버 : 다음의 예에서 연결할 WebtoB 의 IP 어드레스는 111.111.111.111 이고 포트는 9900 을 사용하며 등록 ID 는 ContextGroup 의 이름을 사용하고 연결할 포트의 개수는 2 개이다.


쓰레드 풀의 설정은 최소 쓰레드는 10 개, 최대 쓰레드는 50 개, 변화되는 개수는 4 개, 최대 허용 idle 시간은 300 초, 마지막으로 새로운 쓰레드를 생성시키지 않고 견딜 수 있는 최대 요청은 4 개이다.

그리고 백업 WebtoB 웹서버는 IP 어드레스로 111.111.111.112 를 사용하고 포트는 9900 을 사용하며 등록 ID 는 JeusServer 이고 연결할 포트의 개수는 4 개이며 쓰레드 풀의 설정은 위에 설정된 것을 사용한다.


Port="9900"


RegistrationID="default"




MaxThread="50"

ChangeRate="4"

MaxIdleTime="300"

MaxWaitQueue="4" />

<BackupWebServer Port="9900"



RegistrationID="JeusServer"/>

</Connection>

4.2.4.2 <Connection> 태그의 공통 속성

ListenerType [ (required) default : null ] : 이 속성에서는 어떤 웹서버와의 연결을 설정할 것인지 지정한다. 여기에 설정할 수 있는 값은 WebtobListener 가 있다.

Port [ (required) default : null ] : 이 속성에는 웹서버와 연결할 포트를 지정한다. WebtobListener 의 경우 각각 웹서버와 연결을 위한 포트이고 실제 클라이언트로 부터의 요청을 기다리기 위한 포트는 각 서버의 설정파일에서 설정해야 한다. WebtobListener 의 경우 여기에 설정된 포트는 WebtoB 설정파일에 JSVPORT 라는 항목과 일치하여야 한다. 예를 들면 9900 을 사용한다고 할 때 다음과 같이 각각 설정되어야 한다. (여기에 대해서는 4 장 Container 의 설정의 웹 서버의 WebtoB Servlet Engine 연결 설정 부분에서 자세히 다룬다.)

(container.xml)

Port=”9900”

(WebtoB 설정파일, http.m)

JSVPORT=9900

4.2.4.3 <Connection> 태그의 공통 하위 요소

<Connection> 태그에는 반드시 하나의 <ThreadPool> 태그가 포함되어야 한다. 이 태그는 다음과 같다.


<ThreadPool> 태그 [ (required) ] : 쓰레드 풀의 여러 가지 변수들 값을 설정한다. Connection 태그에는 반드시 하나의

ThreadPool 태그가 포함되어야 한다. 이 태그에서 설정해야 하는 속성에는 다음과 같은 것들이 있다.

MinThread [ (required) default : null ] : 쓰레드 풀에 최소한 유지되어야 하는 쓰레드의 개수이다. 처음 쓰레드 풀이 생성될 때 여기 설정된 만큼의 Worker 쓰레드를 생성한다. 쓰레스 풀의 쓰레드 수가 변동이 되더라도 최소한 여기 설정된 만큼의 쓰레드는 유지된다.

MaxThread [ (recommand) default : MinThread 개수 ] : 이 속성에는 쓰레드 풀에 생성될 수 있는 최대 쓰레드의 개수가 지정된다. 아무리 많은 요청이 들어 오더라도 이 개수 이상의 쓰레드는 생성하지 않는다. 반면 너무 큰 값을 설정할 경우 필요이상으로 많은 쓰레드가 생성되어 오히려 나쁜 성능을 낼 수 있다. 디폴트값은 MinThread 와 같은 개수이다.

ChangeRate [ (recommand) default : 1 ] : 쓰레드가 새로 생성이 되거나 사용되지 않는 쓰레드가 제거될 때 몇 개 단위로 할 지에 대한 설정이다. 만약 이 값을 5 로 하였다면 쓰레드가 모자라서 새로운 쓰레드를 생성해야 할 때 단지 하나만 하는 것이 아니고 5 개를 한꺼번에 생성해서 클라이언트로 부터의 요청이 많이 몰리는 상황에 더 잘 맞추어 나가도록 하는 것이다. 또한 일정 시간동안 사용되지 않는 쓰레드가 있을 경우 한꺼번에 모두 제거하는 것이 아니고 최대 5 개까지만 제거하고 나머지는 다음 모니터링 때까지 기다리도록 한다.

MaxIdleTime [ (recommand) default : 300 (5 분) (단위 : 초) ] : 일정 시간동안 사용되지 않는 쓰레드는 자동적으로 제거되는데 이 시간 간격을 지정한다. 디폴트는 300 초(5 분)이고 단위는 초이다.


MaxWaitQueue [ (recommand) default : 4 ] : 쓰레드 풀에 쓰레드들이 모두 서비스 수행 중일 때 새로운 요청이 들어 오면 자유로운 쓰레드가 생길 때까지 대기하거나 새로운 쓰레드를 생성시킬 수 있다. 이 속성은 여기에 설정된 개수 이상의 요청이 대기하고 있을 때에 비로서 쓰레드를 더 생성시키라는 것이다. 만약 값을 1 로 할 경우 요청이 들어 왔을 때 처리할 쓰레드가 없는 경우 바로 쓰레드를 하나 새로 만들게 된다. 디폴트값은 4 이다.

4.2.4.4 WebtoB 와의 연결에 적용되는 속성

다음은 WebtoB 웹서버와의 연결시에만 적용이 되는 속성과 태그들이다.

WebServerAddress [ (required) default : null ] : 연결할 WebtoB 의 IP 어드레스를 지정한다.

RegistrationID [ (recommand) default : “default” ] : WebtoB 와 연결을 맺을 때 등록과정에서 사용할 ID 를 설정한다. 여기에 설정된 ID 는 WebtoB 의 설정파일에 설정된 서버의 이름과 같아야 한다. 예를 들어 RegistrationID=”MyGroup”라고 설정하였다면 WebtoB 의 설정파일에도 다음과 같은 서버 설정이 있어야 한다.


디폴트값은 “default”이며 이 때는 ContextGroup 의 이름으로 설정된다.

ConnectionPortNum [ (recommand) default : 1 ] : WebtoB 와 연결할 포트의 개수를 지정한다. 이것은 반드시 WebtoB 의 HTH 의 개수와 일치하여야 한다. 예를 들어 WebtoB 의 설정파일에서 hth=2 라고 되어 있다면 이 값도 2 로 설정해야 한다. 그리고 만약 9900 포트를 설정하였다면 9900 과 9901 두 개의 포트가 실제로 WebtoB 와 연결을 맺는 포트가 될 것이다.

WebtobHome [ (recommand) default : null ] : 한 노드에 다수의 webtob 를 구동하고 서블릿 엔진이 다수의 webtob 와 연동할 필요가 있을 때 유용하다.

4.2.4.5 WebtoB 와의 연결에 적용되는 태그

WebtoB 웹서버와 연결할 때에는 <Connection> 태그 아래에 다음과 같은 하위 요소들이 올 수 있다.


<BackupWebServer> 태그 (optional) :원래 연결을 맺고자 했던 WebtoB 와 연결을 맺을 수 없거나 맺어졌던 연결들이 모두 끊어졌을 때 다시 연결을 맺을 백업서버를 설정하는 것이다. 만약 백업서버가 여러 개일 때는 각 백업서버마다 이 태그를 설정하면 된다. 이 태그가 가지고 있는 속성은 Connection 태그의 속성에 있는 4 가지로 WebServerAddress, Port, RegistrationID, ConnectionPortNum 이다. 또한 ThreadPool 태그

역시 설정할 수 있다. 하지만 이런 속성들과 태그들이 설정이 되지 않을 경우는 BackupWebServer 태그가 포함되어 있는 Connection 태그의 설정에서 속성값을 가지고 온다.

4.2.5 <DistributedSession> 태그

DistributedSession 태그는 다수의 WebtoB Web Container 가 연동하여 서비스를 제공할 때 Web Container 사이에 세션 객체를 공유하고자 할 때 설정하는 태그이다. 분산 환경에서 WebtoB Web Container 가 제공하는 세션 객체 공유 방식에 대해서는 4 장 Container 의 설정의 4.2.3 분산 세션 절을 참조하기 바란다. 이 태그는 <Container> 태그의 하위 요소 또는 <ContextGroup> 태그의 하위 요소가 될 수 있다. <Conatiner> 태그의 하위 요소일 경우에는 <Container> 태그 내부에 설정한 모든 <ContextGroup> 태그에 공통으로 적용되고 <ContextGroup> 태그의 하위 요소일 경우에는 해당 <ContextGroup> 태그에만 적용된다. 두곳 모두 존재할 경우 <Container> 태그의 하위 요소로 존재하는 <DistributedSession> 태그가 우선한다.

SessionRouting [ (recommand) default : false ] : WebtoB Web Container 의 session routing 에 의한 분산 세션 기능을 설정하는 속성이다. 기본값은 false 이다. 분산 환경에서 웹 서버로 WebtoB 사용하는 경우 이 기능을 true 로 하기를 권장한다.

<SessionServer> 태그

<SessionServer> 태그는 분산 환경에서 WebtoB Servlet Engine 세션 서버에 의한 세션 클러스터링을 하고자 할 때 사용하는 태그이다. 이 태그는 선택적이다. 이 태그는 사용하고자 하는 세션 서버를 지정하는 태그이다. 세션 서버를 구동하기 위해서는 JeusMain.xml 에 이에 관한 설정을 해야 한다.

ServerName [ (required) default : null ] : 주(main) 세션 서버로 사 용 할 세 션 서 버 의 SessionManager 이 름 을 지 정 한 다 . JeusMain.xml 의 SessionManager 태그의 SessionExportName 의 값

과 일치해야 한다.


BackupServerName [ (optional) default : null ] : 주(main) 세션 서

버에 장애가 발생하였을 때 세션 서버로 사용할 서버의 SessionManager 이 름 을 지 정 한 다 . JeusMain.xml 의 SessionManager 태그의 BackupName 의 값과 일치해야 한다.

MaxCapacity [ (required) default : -1 ] : SessionServer 태그를 설정

하는 경우 WebtoB Web Container 에는 세션 서버와 통신하기 위

한 connection pool 을 기 동 한 다 . MaxCapacity 태 그 는 이 connection pool 의 최대 연결 개수를 지정한다. InitCapacity 값보

다 작을 수 없다. Web Container 내의 worker thread 의 개수보다 큰 값은 의미가 없다.

InitCapacity [ (optional) default : 1 ] : 세션 서버로 연결되는 conection pool 의 초기 값을 지정한다. Web Container 내의 worker thread 의 개수보다 큰 값은 의미가 없다.

IncrementRate [ (optional) default : 1 ] : 세션 서버로 연결되는 connection pool 의 capacity 를 증가시킬 때 그 증가치를 지정한

다.

TimeoutMilliSec [ (optional) default : 10000 ] : 세션 서버로 연결

되는 connection pool 에서 연결을 가져 올 때, 최대 대기 시간을 설정한다.


다음은 container.xml 에 DistributedSession 태그를 설정하는 예를 나타낸 것이다. 이와 관련한 JeusMain.xml 의 SessionServer 태그 설정을 그 다음에 나타냈다.

< container.xml >




InitCapacity="1"

MaxCapacity="3"

IncrementRate="1"


</SessionServer>


< JeusMain.xml >

Primary Session Server

<SessionServer>


<SessionManager>





<FileDBPath/>

<FileDBName/>







</SessionManager>

</SessionServer>

Backup Session Server

<SessionServer>


<SessionManager>





<FileDBPath/>

<FileDBName/>







</SessionManager>

</SessionServer>


4.2.6 <ResponseHeader> 태그

이는 클라이언트로 가는 응답헤더와 관련된 설정을 위한 태그이다. 이 태그에는 <SessionIDCookie> 태그가 하나 포함되어 있다.

<SessionIDCookie> 태그는 Container 내부적으로 사용하는 세션 ID 쿠키를 직접 컨트롤하기 위한 것이다. 이 태그를 설정하지 않을 때 클라이언트로 전달되는 세션 ID 쿠키는 모든 속성들이 디폴트값을 가진다.

이 태그의 설정을 알려면 먼저 쿠키에 대한 기본적인 이해가 필요하다. 먼저 쿠키에 설정할 수 있는 속성들에는 다음과 같은 것들이 있다.

Version : 0 과 1, 두 가지 버전이 있다. 디폴트는 0 이다.

Domain : 어떤 URL 요청일 때 쿠키를 함께 보낼지를 결정한다. 예를 들어 .foo.com 이라고 설정하였을 경우 .foo.com 이라는 URL 을 가진 요청에 대해서만 쿠키가 함께 보내진다. 디폴트값은 쿠키를 받은 서버의 도메인 이름과 완전히 일치할 때 보내는 것이다. 예를 들어 쿠키를 받은 서버가 www.foo.com 이라면 www2.foo.com 이라는 URL 의 요청에 대해서는 쿠키를 보내지 않는다.

Path : 어떤 URI 요청일 때 쿠키를 함께 보낼지를 결정한다. 예를 들어 /examples 라고 설정되어 있으면 /examples 로 시작되는 URI 에 대해서만 쿠키를 보낸다. 디폴트값은 ‘/’ 로서 모든 URI 에 대해서 쿠키를 보내는 것이다.

MaxAge : 쿠키가 어느 기간동안 클라이언트에 남아 있을지를 결정한다. 디폴트값은 브라우저가 실행되고 있을 동안이다.

Secure : SSL 을 이용한 요청일 때만 쿠키를 보내도록 하는 설정이다. 디폴트는 false 로 SSL 요청만으로 제한하지 않는다.


위의 속성 중 Domain 속성은 디폴트와 다른 값을 설정할 필요할 경우가 있다. 두 Web Container 가 세션 클러스터링에 묶여 있지만 두 Web Container 로 요청을 보낼 때 다른 URL 을 사용해야 하는 경우를 예로 들어 보자. 두 Web Container 의 URL 이 각각 www.foo.com 과 www2.foo.com, 두 가지라고 할 때 만약 디폴트의 세션 ID 쿠키를 사용한다면 클라이언트는 www.foo.com 에서 받은 세션 ID 쿠키를 www2.foo.com 으로 요청할 때는 그 쿠키를 함께 보내지 않을 것이고 결국 두 Web Container 간의 세션 공유는 실패하게 된다. 이 때 Domain 을 .foo.com 으로 설정한다면 문제는 해결된다. 세션 ID 쿠키의 속성을 바꾸는 것은 Container 의 세션관련 동작에 상당한 영향을 주기 때문에 꼭 필요한 경우가 아닌 경우 설정하지 않는 것이 좋다.

<ResponseHeader> 태그의 설정을 보여 주는 예는 다음과 같다.

<ResponseHeader>

<SessionIDCookie>

<Version>0</Version>

<Domain>.foo.com</Domain>

<Path>/examples</Path>

<MaxAgeSecs>6000</MaxAgeSecs>

<Secure>false</Secure>

</SessionIDCookie>

</ResponseHeader>

이 태그의 하위 요소들은 다음과 같다.

<SessionIDCookie> 태그 [ (optional) ] : 세션 ID 쿠키의 속성을 바꾸고자 할 때 사용한다. 이 태그의 하위 요소는 다음과 같다.

Version [ (optional) default : 0 ] : 버전 속성을 설정한다.

Domain [ (optional) default : 쿠키를 보낸 서버의 도메인 이름 ] : 도메인 속성을 설정한다.

Path [ (optional) default : / ] : Path 속성을 설정한다.

MaxAgeSecs [ (optional) default : null ] : MaxAge 속성을 설정한다. 단위는 초이다.

Secure [ (optional) default : false ] : Secure 속성을 설정한다.


4.2.7 <ActiveManagement> 설정

이 태그는 능동적인 관리에 관한 설정을 한다. 여기서 능동적인 관리라 함은 관리자가 로그정보를 보거나 관리 툴을 주기적으로 사용하여 Container 를 관찰함으로써 Container 의 상태를 아는 것이 아니라 어떤 특정한 상황(예를 들면 에러가 발생하는 상황)에 관리자에게 Container 스스로 능동적으로 알려 주는 것이다. 여기에는 EmailNotify 태그, ThreadStateNotify 태그, AutoRestart 태그가 포함된다.

<ActiveManagement>

<EmailNotify NotifierID="manager"

NotifyLogLevel="error"

SMTPHostAddress="111.111.111.111"

FromEmailAddress="[email protected]">

<ToRecipients>

<EmailAddress>[email protected]</EmailAddress>


</ToRecipients>

<CcRecipients>


</CcRecipients>

<BccRecipients>

<EmailAddress> [email protected] </EmailAddress>

</BccRecipients>

</EmailNotify>

<ThreadStateNotify>

<ThreadState ThreadPoolPort="8010"

MaxThreadActiveTimeSecs="60"

MaxBlockedThreads="6"/>

<EmailNotifier NotifierID="manager"

Subject="[WARNING] threads are hanged up"/>

</ThreadStateNotify>

<AutoRestart>

<ThreadState ThreadPoolPort="8010"

MaxThreadActiveTimeSecs="60"

MaxBlockedThreadRate="0.8"/>

<EmailNotifier NotifierID="manager"

Subject="[WARNING] engine auto restart"/>

</AutoRestart>

</ActiveManagement>

<EmailNotify> 태그 [ (optional) ] : 전자우편으로 관리자에게 에러 상황을 알리는 기능을 설정한다. 전자우편을 보내기 위한 몇 가지 필요한 속성을 가지고 받을 사람을 표시하는 ToRecipients, CcRecipients, BccRecipients 세 가지 태그를 포함하고 있다. 이 태그의 속성은 다음과 같다.

NotifiedID [ (required) default : null ] : EmailNotifier 의 ID 를 설정하는 것으로 ThreadStateNotify 태그와 AutoRestart 태그

의 설정에서 이 ID 를 사용하여 어떤 주소로 전자우편을 보

낼 것인지 선택하게 된다.


NotifyLogLevel [ (recommand) default : error ] : 어떤 에러 레벨의 에러가 발생했을 때 전자우편으로 알릴 것인지를 설정한다. 여기서 설정할 수 있는 값은 Logging 태그이 ErrorLogLevel 에서 설정했던 값들과 같다. (emergency, error, warning, information, debug)지정된 레벨의 에러와 더 심각한 레벨의 에러들은 모두 관리자에게 보내진다. 이 때 보내지는 내용은 에러 로그 파일에 기록되는 내용과 같다. 디폴트는 error 로서 emergency, error 레벨의 에러가 발생했을 때 관리자에게 보내진다.

SMTPHostAddress [ (required) default : null ] : 전자메일을 보낼 SMTP 호스트의 어드레스를 설정한다.

FromEmailAddress [ (required) default : null ] : 전자우편을 보낸 사람의 전자우편 주소를 설정한다. 이때는 반드시 완전한 전자우편 주소이어야 한다. 또한 이 태그에는 다음과 같은 하위 요소들이 있다.

<ToRecipients> 태그 [ (required) ] : 받을 사람의 전자우편 주소들를 설정한다. 반드시 하나 이상의 주소를 설정해야 하고 완전한 전자우편 주소이어야 한다.

<CcRecipients> 태그 [ (optional) ] : 참조되는 전자우편의 주소들을 설정한다. (Carbon copy) 반드시 완전한 전자우편 주소이어야 한다.

< BccRecipients> 태그 [ (optional) ] : 숨은 참조되는 전자우편의 주소들을 설정한다. (Blind carbon copy) 반드시 완전한 전자우편 주소이어야 한다.

<ThreadStateNotify> 태그 [ (optional) ] : 쓰레드의 상태를 주기적 (MonitoringIntval)으로 모니터링하여 관리자가 지정한 특정한 상태에 이르게 되면 전자우편을 통해 관리자에게 알려 주는 기능이다. 서블릿이나 JSP 를 실행하고 있는 쓰레드들이 여러 가지 이유로 해서 더 이상 진행이 되지 않고 deadlock 이 걸린 경우 이러한 쓰레드들을 blocked thread 라고 하고 이런 blocked thread 가 어느 이상 쌓이게 되면 관리자에게 통보가 되는 것이다. 이 기능을 설정해 두면 쓰레드들이 비정상적인 상태를 보일 때 미리 통보가 됨으로써 즉시 조처를 취할 수 있다. 또한 통보가 되는 내용에는 현재 쓰레드들이 어떤 서블릿이나 JSP 를 수행하는 중이었는지에 대한 정보가 있기 때문에 특정 서블릿이나 JSP 가 문제가 있을 경우 조기에 알아낼 수 있다.


<ThreadState> 태그 [ (required) ] : 얼마 동안 실행이 된채 끝나지 않은 쓰레드를 blocked thread 로 간주할 것인지를 설정하고 이런 blocked thread 가 얼마 이상 되었을 때 알려 줄 것인지에 대한 설정을 함으로써 관리하고자 하는 쓰레드의 상태를 설정하는 것이다.

ThreadPoolPort [ (required) default : null ] : 어떤 포트에 관련된 쓰레드 풀의 쓰레드들에 대한 상태를 관리할 것이지 설정한다.

MaxThreadActiveTimeSecs [ (required) default : null ] : 얼마 동안 실행이 된채 끝나지 않은 쓰레드를 blocked thread 로 간주할 것인지를 설정하는 것으로 초 단위로 설정한다. 이 값은 대략 가장 오래 실행되는 서블릿이나 JSP 의 실행시간의 1.5 배 내지는 2 배정도로 설정하면 적당하다. 예를 들어 가장 오래 실행되는 서블릿이나 JSP 가 대략 60 초 정도 걸린다고 할 때 이 값은 90 초 ~ 120 초 정도로 설정하면 된다.

MaxBlockedThreads [ (optional) default : null] : 몇 개 이상의 blocked thread 가 생겼을 때 알려 줄지를 설정한다.

MaxBlockedThreadRate [ (recommand) default : null ] : MaxBlockedThreads 와 마찬 가지로 몇 개 이상의 blocked thread 에 대해 통보해 줄 것인지를 결정하는 것이지만 여기서는 정확한 쓰레드의 개수를 설정하는 것이 아니고 최대 쓰레드의 개수에서 몇 퍼센트인지로 설정하는 것이다. 예를 들어 최대 쓰레드의 개수가 200 개이고 이 값을 0.5 로 설정하였을 경우 200 x 0.5 = 100 개의 쓰레드가 blocking 상태에 있을 때 통보를 하게 된다. 이 속성과 MaxBlockedThreads 속성이 함께 설정된 경우 이 속성이 우선적으로 선택된다.

<EmailNotifier> 태그 [ (required) ] : 어떤 주소로 어떤 제목을 가지고 통보해 줄 것인지를 설정한다.

NotifierID [ (required) default : null ] : 어떤 EmailNotifier 를 통해 통보해 줄 것인지를 결정한다. 즉 EmailNotify 태그에서 설정한 NotifiedID 와 일치하는 값을 설정하면 된다. 그러면 EmailNotify 에서 설정한 주소로 통보가 가게 된다.

Subject [ (recommand) default ] : 전자우편으로 보내질 제목을 설정한다.


<AutoRestart> 태그 [ (optional) ] : ThreadStateNotify 태그를 설정하면 비정상적인 쓰레드 상태일 경우 통보는 해 주지만 그 이상 조처를 취하는 것은 관리자의 책임이 된다. 하지만

AutoRestart 태그를 설정하게 되면 비정상적인 쓰레드 상황에서 자동적으로 Web Container 를 재기동 시킴으로써 상황을 해결할 수 있다. 하지만 이것은 blocked thread 들로 인해 비효율적으로 자원을 사용하던 것을 재기동으로서 해소한다는 것이지 근본적으로 blocked thread 를 만들어낸 서블릿이나 JSP, 혹은 그 이외의 특수한 상황을 해결한다는 것은 아니다. 따라서 관리자는 재기동이 된 후 이 때의 상황을 분석하여 다음에는 비정상적인 상황이 발생하지 않도록 해야 한다. 여기서 설정하는 내용은 ThreadStateNotify 태그에서 설정하는 내용과 완전히 일치한다. 다만 EmailNotifier 태그가 optional 로써 설정하지 않을 경우 재기동만 되고 전자우편을 통한 통보는 하지 않는 것이다. 또 한가지 주의할 점은 ThreadStateNotify 기능은 비정상적인 상황에 대한 경고를 주는 기능이므로 MaxBlockedThreadRate 를 낮게 설정하여 관리자가 조기에 알 수 있도록 하고 AutoRestart 기능은 ThreadStateNotify 보다는 MaxBlockedThreadRate 를 높게 설정하여 너무 자주 재기동이 되는 것을 막아야 한다.


4.3 DB 연결 풀링 설정

데이터베이스 연결 풀링은 Application(servlet 이나 JSP)에서 데이터베이스에 요청을 할 때마다 데이터베이스와 연결을 맺고 인증을 하는 과정에서 생기는 부담을 줄이기 위해 미리 테이터베이스와 연결을 맺어 풀에 넣어 두고 Application 이 요청할 때 꺼내 주고 사용이 끝난 후에는 다시 넣어 다음에 재사용하도록 하는 기법이다.

WebtoB Web Container 에서는 두 가지 DB 연결 풀링 방법이 있다. 하나는 WebtoB Servlet Engine 서버에서 제공하는 naming server 기능을 이용한 방법이고, 다른 하나는 servlet Container 에서 제공하는 DB 연결 풀링이다. 이중 첫번째 것은 WebtoB Servlet Engine 서버의 설정 파일인 JeusMain.xml 에서 설정을 하며 JNDI specification 에 따라 사용할 수 있다. 따라서 여기서는 container.xml 에서 설정해서 servlet 컨테이너 단독으로 사용하는 DB 연결 풀링의 설정에 대해 알아보기로 한다.

이 설정은 <container> 태그 안에서 설정하지만 <ContextGroup> 바깥쪽에 있다. 이 말은 하나의 컨텍스트 그룹에 종속된 DB 연결 풀링이 아니라 어느 컨텍스트 그룹에서도 사용할 수 있는 DB 연결 풀링이라는 뜻이다. 이 설정은 <DBConnectionPool> 태그가 담당한다.

Container 에서 제공하는 데이터베이스 연결 풀링은 shared 와 non-shared 두 종류가 있다. shared 방식은 여러 개의 컨텍스트 그룹 내의 쓰레드들이 DB 연결을 필요로 할 때 DB 연결 풀에서 하나씩 가져다 쓰는 방법이다.

non-shared 방식은 데이터베이스 풀의 DB 연결들이 쓰레드들에 의해 공유되지 않고 각 쓰레드에 할당되는 방식으로 쓰레드 수만큼의 DB 연결이 필요하다. 하지만 이 방식은 DB 연결을 얻기 위해 다른 쓰레드와 경쟁을 할 필요가 없으므로 성능이 향상될 수 있다. 하지만 설정한 쓰레드 수만큼 DB 연결을 맺을 수 없도록 제한되어 있을 경우에는 non-shared 방식을 사용할 수 없다. 이때는 shared 방식을 사용해야 한다.

아래 예는 두 가지 방식의 데이터베이스 연결 풀링의 모든 속성을 설정한 예이다.



<DBConnectionPool ConnectionPoolID="oraclePool"

ConnectionPoolType="shared"





MaxActiveTimeSecs="300"

DynamicIncrement="false"

ConnectionTimeOutSecs="10"

LoginDelayMillis="1000"

CloseDelayMillis="1000">

<DBPoolControl InitCapacity="2"

MaxCapacity="10"

IncrementRate="2"

MaxIdleTimeSecs="300"/>

</DBConnectionPool>



<DBConnectionPool ConnectionPoolID="oraclePool2"

ConnectionPoolType="non-shared"

ThreadPoolPort="8088"


MaxActiveTimeSecs="60"

ConnectionTimeOutSecs="10"

LoginDelayMillis="1000"

CloseDelayMillis="1000">

</DBConnectionPool>

ConnectionPoolID [ (required) default : null ] : 이 속 성 은 Application 에서 DB 연결을 요청할 때 사용할 DB connection pool 의 ID 이다. 즉, jdbc:jeus:pool:oraclePool 의 형식으로 요청을 하게 된다. 여기서 DB connection pool 은 DB connection 들을 가

지고 있는 집합을 말한다. <DBConnectionPool> 태그는 하나의 DB connection pool 을 만들어 낸다.

ConnectionPoolType [ (required) default : non-shared ] : 이 속성

에서는 DB 풀링 방식을 설정한다. 값으로는 “shared”와 “non-shared”가 올 수 있다.

ThreadPoolPort [ (non-shared 인 경우만 required) default : null ] : non-shared 타입의 DB 풀링을 적용할 쓰레드들이 속한 port 번호를 지정한다. 즉, 이 타입의 DB 풀링을 사용할 컨텍스트 그룹의 쓰레드들을 지정하는 것인데, 각 쓰레드들은 웹서버의 connection 마다 있는 쓰레드 풀에 종속되어 있으므로 사용하고자 하는 <connection> 태그의 Port 속성의 값이 오게 된다. 이때 여러 포트 번호가 값으로 올 수 있으며 형식은 “1000,2000,3000” 같이 콤마로 구분한다.

ConnectionURL [ (required) default : null ] : 이 속성은 DB 에 연

결할 때 사용할 DB 의 URL 이다.

DriverClassName [ (required) default : null ] : 이 속성은 pooling을 할 실제 드라이버의 클래스 이름을 나타낸다.

ConnectionArguments [ (required) default : null ] : 이 속성은 username 이나 password 등과 같이 connection 할 때 사용되는 property 들을 지정한다. 이 속성의 값의 형식은 위의 예와 같이 각 property 들이 name=value 형식으로 쓰여지고 property 들을 구분한다.


CloseLongActiveConnection [ (optional) default : false ] : pooling 된 DB connection 은 Application 에 서 close 할 경 우 실 제 connection 이 끊어지는 것이 아니라 다시 풀에 집어 넣게 된다. 하지만 만약 Application 의 버그나 DB 와 문제가 있어 특정

connection 이 close 안되고 계속 일을 하고 있는 상태, 즉 active 상태이면 이 DB connection 은 pool 로 돌아오지 않아서 나중에 사용할 수 없게 된다. 이 속성의 값이 true 이면 이러한 DB connection 을 Container 의 monitoring thread 에 의해 강제로 끊고 이를 pool 에 다시 넣는다. Default 값은 false 이다.

MaxActiveTimeSecs [ (optional) default : -1 (단위 : 초) ]: 이 속성에서는 CloseLongActiveConnection 속성의 값이 true 이면 반드시 지정해야 하는 속성으로 하나의 connection 이 한번에 최대로 Application 에 의해 사용될 수 있는 시간을 지정한다. 값은 초 단위로 설정된다.

DynamicIncrement [ (optional) default : false ] : 만약 풀의 connection 들이 다 Application 에 의해 사용되고 있는데 또 DB 요청이 들어 왔을 경우에는 새로 connection 을 맺어서 DB 연결을 할 수 있게 해 준다. 하지만 만약 풀이 가질 수 있는 최대 connection 개수에 도달했을 경우에는 풀의 connection 중 하나가 사용이 끝나서 풀로 돌아올 때까지 기다리게 된다. 하지만 이 속성의 값이 true 라면 풀에 DB connection 이 없을 때는 최대 connection limit 와 관계없이 새로운 connection 을 하나 맺게 된다. 그리고 DB 연결이 끝난 다음에는 풀에 집어 넣지 않고 바로 끊어 버린다. 하지만 일반적으로 이 속성의 값을 true 로 하면 DB 풀링 이외에 별도로 DB connection 을 맺고 끊는 경우가 종종 생겨서 DB 연결 풀링의 기능을 최대한 사용할 수 없게 되어 성능이 저하된다.

ConnectionTimeOutSecs [ (optional) default : 10 초 (단위 : 초) ] : 앞의 속성의 설명에서 풀에 사용 가능한 connection 이 없으면 보통의 경우 하나의 connection 이 풀로 돌아올 때까지 기다리게 되어 있다. 이 때 기다리는 시간의 최대값이 이 속성의 값으로 지정된다. 이 시간 내에 사용 가능한 connection 이 생기지 않을 경우에는 Application 에 null 을 리턴하게 된다. 따라서 Application 에서는 DB connection 을 얻을 때 null 이 돌려질 경우를 처리할 수 있어야 한다. Default 값은 10 초이다.


MaxUseCount [ (optional) default : -1 ] : 하나의 물리적인 데이터베이스 연결을 몇 번이나 사용할 것인지를 설정하다. 예를 들어 30 이라고 설정이 된 경우 30 번을 사용한 후 자동으로 연결을 끊고 새로운 물리적 연결을 맺어서 사용하는 것이다.

LoginDelayMillis [ (optional) default : -1 (단위 : milliseconds) ] : Container 가 실행될 때에는 DB 연결 풀을 초기화 할 때 최소값만큼 connection 들을 한꺼번에 맺는다. 그런데 상황에 따라 어떤 경우는 연속해서 connection 을 맺을 수 없을 때가 있다. 그래서 그런 경우 connection 을 맺고 이 속성에 지정된 시간만큼 기다리고 다음 connection 을 맺고 하는 식으로 DB 연결 풀이 초기화된다. 단위는 milliseconds 이고, 보통의 경우는 사용하지 않아도 되는 속성이다.

CloseDelayMillis [ (optional) default : -1 (단위 : milliseconds) ] : Container 는 풀을 그만 사용하려고 할 때 connection 을 끊는다. 하지만 이때 사용중인 connection 이 있다면 그 때 기다려 주는 시간을 이 속성에서 지정하는 것으로 단위는 milliseconds 이다. 보통은 풀을 제거할 때는 Container 를 종료할 때이므로 사용하지 않아도 된다. 만약 shared 타입의 DB 풀링을 사용한다면 <DBConnectionPool> 태그 안에는 하위 요소로 <DBPoolControl> 태그가 하나 있어야 한다. 이 태그에서는 <ContextGroup> 태그 안의 <ThreadPool> 태그의 경우와 비슷하게 DB pool 의 초기값, 최대값, 증가값 등을 지정한다. 이 태그의 속성은 다음과 같다.

InitCapacity [ (optional) default : 1 ] : 초기 connection 수이자 최

소로 유지해야 할 connection 의 수를 이 속성의 값으로 지정한

다. default 는 1 개이다.

MaxCapacity [ (required) default : null ] : DB pool 에 담아둘 수 있는 최대 connection 수를 지정한다.

IncrementRate [ (optional) default : 1 ] : 이 속성의 값은 증가시

키는 connection 의 단위이다. default 는 1 개이다.


MaxIdleTimeSecs [ (optional) default : -1 (단위 : 초) ] : DB pool 에 사용하지 않는 connection 이 있을 경우 풀에서 제거되어 connection 이 끊어지는데 이 때 허용하는 최대의 idletime 을 이 속성에서 지정한다. 만약 이 값이 -1 이라면 idle time 을 check 하지 않고 풀에 들어간 connection 이면 그냥 두는 것이 된다. default 는 –1 이다.

4.4 Startup/Shutdown Class

WebtoB Web Container 가 기동될 때 또는 종료될 때 호출할 클래스의 메쏘드를 정의하는 태그이다. <Container> 태그의 하위 요소로 등록된다. StartupClass, ShutdownClass 태그는 복수개 지정할 수 있다. 복수개의 태그가 존재할 경우 기술된 순서대로 호출된다.

StartupMethod [ (required) ] : Web Container 가 기동될 때 호출될 메쏘드를 등록한다. 클래스 이름은 패키지 이름을 포함한 전체 이름을 기재해야 한다. 인자의 타입은 primitive 타입과 java.lang.String 타입을 지원한다.

StartupParameters [ (required) ] : 메쏘드의 파라메터 리스트를 기재한다. 인자의 구분은 컴마(,)로 한다.

ShutdownMethod [ (required) ] : Web Container 가 종료될 때 호출될 메쏘드를 등록한다. 클래스 이름은 패키지 이름을 포함한 전체 이름을 기재해야 한다. 인자의 타입은 primitive 타입과 java.lang.String 타입을 지원한다.

ShutdownParameters [ (required) ] : 메쏘드의 파라메터 리스트를 기재한다. 인자의 구분은 컴마(,)로 한다.


아래에 container.xml 에 등록하는 예를 나타내었다.

<StartupClass>

<StartupMethod>mylib.Startup::start(int,java.lang.String)</Start

upMethod>

<StartupParameters>328943,startupParam</StartupParameters>

</StartupClass>

<ShutdownClass>

<ShutdownMethod>mylib.Shutdown::down(int,java.lang.String)</Shut

downMethod>

<ShutdownParameters>8943,shutdown1 string

parameter</ShutdownParameters>

</ShutdownClass>

5 Container 의 관리

WebtoB Web Container 를 실행하고 실행 중에 Container 를 관리하기 위해서는 webadmin console tool 이용한다. 여기서는 어떤 관리를 할 수 있고 이러한 관리를 어떻게 할 수 있는지에 대해 알아본다.

5.1 webadmin 을 이용한 Container 관리

Container 를 실행시킨 후에 Container 에서 실행되는 Application 에 대한 조작이나 Container 의 설정을 바꾸기 위해서는 webadmin tool 을 사용해야 한다. webadmin 은 console 로 Container 의 각종 정보를 살펴볼 수도 있고, Application 에 대한 조절을 할 수 있다. webadmin 에서 제공하는 명령들은 크게 네가지로 분류할 수 있다.

Container 의 상태를 알려 주는 명령들 (st, ti, info)

Container 의 설정 정보에 관한 명령들 (cfg, set)

Container 의 동작을 조절하는 명령들 (suspend, resume, reload, restart, terminate)

그 외의 명령들 (help, p)


먼저 webadmin 을 실행시켜 보자. 이 프로그램은 WebtoB Servlet Engine 디렉토리의 bin 디렉토리에 있다. webdamin 을 실행시키는 방법은 다음과 같다.

webadmin engine_name [-n node_name] [command]

engine_name 에 해당하는 서블릿 엔진이 다른 노드에 있다면 –n

node_name 옵션을 사용한다. [-n node_name] 옵션은 반드시 engine_name 바로 다음에 와야 한다.

webadmin 을 실행시키면 prompt 가 화면에 나타난다. 우선 webadmin 이 제공하는 명령들의 종류와 사용방법을 알기 위해서 help(h, ?)를 실행시키면 다음과 같은 화면이 출력이 된다.


-- Command list & Usages --

st(stat) [OPTION] : report current state

-m memory state

-t thread state

-r the number of requests

-s session state

-d DB pool state

ti [OPTION] : report detailed thread state

-p port thread information

-r request information of threads

-a all information of threads

cfg [OPTION] : report configuration information

-cg:<ContextGroup> ContextGroup config

-c:<Context> Context config

-cn:<port> Connection & Thread Pool config

-db:<DBPool> DB Connection Pool config

-log logging config

-sc session clustering config

-am active management config

-rh response header config

set [OPTION] : set configuration information

-cg:<ContextGroup> set ContextGroup config

-c:<Context> set Context config

-cn:<port> set Thread Pool config

-db:<DBPool> set DB Connection Pool config

Thread Pool configurations

-tmin <number> set minimum threads

-tman <number> set maximum threads

-trate <number> set changing rate of threads

-tidle <seconds> set idle time of threads

-tmwq <number> set maximum wait queue size

-tmq <number> set maximum queue size

-ts_mbt <number> set <ThreadStateNotify>

MaxBlockedThreads

-ts_mbtr <rate> set <ThreadStateNotify>

MaxBlockedThreadRate

-ar_mbt <number> set <AutoRestart> MaxBlockedThreads


-ar_mbtr <rate> set <AutoRestart>

MaxBlockedThreadRate

DB Connection Pool configurations

-dmin <number> set minimum connections

-dmax <number> set maximum connections

-drate <number> set increment rate of connections

-didle <seconds> set idle time of connections

-clac <true|false> set CloseLongActiveConnection

-mats <seconds> set MaxActiveTimeSecs

-di <true|false> set DynamicIncrement

-muc <count> set MaxUseCount

-mtat <seconds> set MaxThreadActiveTimeSecs

-ctos <seconds> set ConnectionTimeOutSecs

Monitoring Interval configurations

-mi <seconds> set MonitoringIntval

-smi <seconds> set SessionMonitoringIntval

-dmi <seconds> set DBPoolMonitoringIntval

other configurations

-stm <minutes> set SessionTimeoutMinute

-ar <true|false> set AutoReload

-ssn <primary>[:<secondary>] set session server names and

takeover

-tss <temp> set temporary session server and

takeover

info [ContextGroup] [Context] : print current elements

suspend [ContextGroup] [Context] [Servlet]

: temporarily suspending

resume [ContextGroup] [Context] [Servlet]

: resume suspended elements

reload [ContextGroup] [Context] [Servlet] : reload elements

terminate [ContextGroup] [Context] [Servlet] : terminate

elements

restart [ContextGroup] [Context] [Servlet] : restart elements

p(!) : execute previous command

h 라는 명령어는 webadmin prompt 에서 사용할 수 있는 명령어와 그 사용법을 간략히 표시해 주는 help 이다. 그리고 맨 마지막의 p 명령어는 이전에 실행했던 명령을 다시 한번 실행해 주는 명령어이다. 또한 exit 나 quit 나 q 는 webadmin 을 종료하는 명령어이다.

5.1.1 Container 의 상태를 알려 주는 명령들

Container 의 메모리, 쓰레드, 세션 등의 정보와 서블릿이나 JSP 에 대한 정보를 보여 주는 명령들이다.

st (stat) : Container 의 전체 정보를 보여 준다.

여기서 보여 주는 정보에는 다음과 같은 것이 있다.

메모리 정보 : JVM 의 total memory 와 free memory 정보를 보여 준다.

쓰레드 정보 : 각 컨텍스트 그룹의 쓰레드 풀에 대한 정보를 보여 준다.

request 정보 : 각 컨텍스트가 받은 request 의 개수와 평균 처리시간을 보여 준다.

세션 정보 : Container 가 가지고 있는 세션의 개수와 세션 클러스터링에 관한 정보를 보여 준다.

데이터베이스 연결 풀 정보 : 데이터베이스 연결 풀에 대한 정보를 보여 준다.

다음은 사용방법과 옵션에 관한 설명이다.

아무 옵션없이 st 를 실행하면 앞에 설명한 모든 정보가 출력된다.하지만 특정한 정보만을 보기를 원할 때는 다음과 같은 옵션을 줌으로써 원하는 정보만을 출력하게 할 수 있다.

-m : 메모리 상태 정보

-t : 쓰레드 풀 상태 정보

-s : 세션 상태 정보

-r : request 정보


-d : 데이터베이스 연결 풀 상태 정보

이 옵션들은 하나 이상 함께 사용할 수 있다. 즉 메모리 상태 정보와 쓰레드 풀 상태 정보를 함께 보기 위해서는 다음과 같이 실행하면 된다.

$$1 [webdev:webdev_servlet_engine1] st –m –t

ti : 쓰레드의 상태를 보여 준다. st 명령에서 보여 주는 쓰레드 풀에 대한 전체적인 정보와는 달리 ti 명령에서 보여 주는 정보는 개개의 쓰레드들에 대한 상태 정보를 보여 준다. 여기서 보여 주는 정보는 다음과 같은 것들이 있다.

쓰레드 ID

쓰레드의 상태 (사용 중 or 대기 중)

쓰레드가 active state 나 waiting state 로 들어가기 시작한 시간

위의 시간으로부터 지금까지의 경과된 시간

이전 ti 명령 이후 지금까지 request 의 개수

이전 ti 명령 이후 지금까지 request 들의 평균 처리 시간

지금까지 이 쓰레드가 처리한 총 request 개수

active 상태일 때 요청된 URI

사용방법과 옵션은 다음과 같다. 아무 옵션이 없이 ti 만 실행하였을 경우 Container 에 존재하는 모든 쓰레드의 상태와 waiting time 혹은 running time 을 출력해 준다. 예를 들어 Container 에 9660 과 8348 두 개의 포트에 대해 쓰레드 풀이 설정되어 있다면 결과는 다음과 같다.

$$22 [tmaxc1:tmaxc1_servlet_engine1] ti

-- Thread State [168.126.185.131:9660] --

[webtob-9660-w0][waiting, wt=5444 ms]

[webtob-9660-w1][active , rt=3143 ms,

uri=/test/jsp/rush/flush.jsp]










-- Thread State [127.0.0.1:8348] --

[http-8348-w0][waiting, wt=298012 ms]





위에서 webtob-9660-w0, webtob-9660-w1…은 쓰레드 ID 에 해당하고 waiting 과 active 가 쓰레드의 상태를 나타내며 rt 는 running time, wt 는 waiting time 을 가리키고 단위는 milliseconds 이다. 그리고 active 상태인 쓰레드는 현재 처리 중인 request 의 URI 를 보여 준다. 위의 출력은 9660 포트를 사용하는 쓰레드 풀은 현재 쓰레드가 10 개가 있고 그 중 1 개가 /test/jsp/rush/flush.jsp 라는 URI 요청을 처리 중이고 6 개가 대기 중이다. 그리고 8348 포트를 사용하는 쓰레드 풀은 현재 쓰레드가 2 5 개 있고 모두 대기 중이다.

ti 명령에서 사용할 수 있는 옵션은 3 가지가 있다.

-p <port> : 특정 포트를 사용하는 쓰레드 풀에 대한 정보만 출력하고자 할 때 사용한다.

-r : 쓰레드가 처리한 request 에 대한 정보만을 보고자 할 사용한다.

-a : ti 명령이 보여 줄 수 있는 모든 정보를 원할 때 사용한다.

다음은 –r 옵션을 사용한 예이다.

$$21 [tmaxc1:tmaxc1_servlet_engine1] ti -p9660 -r

-- Thread State [168.126.185.131:9660] --

[webtob-9660-w0][reqs=0, avgTime=0 ms, total=6]











위에서 reqs 는 이전 ti 명령을 실행한 시간 이후부터 지금까지 쓰레드가 처리한 request 의 개수이고 avgTime 은 평균 처리 시간을 milliseconds 로 나타낸 것이고 total 은 Container 가 구동하고 지금까지 쓰레드에 의해 처리된 총 request 의 개수를 나타낸다.

다음은 –a 옵션을 사용하였을 때의 예이다.

$$10 [tmaxc1:tmaxc1_servlet_engine1] ti -p9660 –a

-- Thread State [168.126.185.131:9660] --

[webtob-9660-w0][waiting, 2002.04.15 18:26:25, wt=84420

ms][req=0, avgTime=0 ms, total=6][alive=true]



















위의 예에서 각각이 가리키는 바는 다음과 같다.

[t0] : 쓰레드 ID

waiting : waiting 상태

active : active 상태

2001.02.28 20:28:30 : waiting 상태로 들어간 시간이나 running 상태 로 들어간 시간


2002.04.15 18:26:25 : waiting 상태로 들어간 시간이나 running 상 태로 들어간 시간

wt : waiting time

rt : running time

req : 이전 ti 명령 이후 지금까지 request 의 개수

avgTime : 이전 ti 명령 이후 지금까지 request 들의 평균 처리 시간

total : 지금까지 이 쓰레드가 처리한 총 request 개수

uri : active 상태일 때 요청된 URI

alive : 현재 thread 가 살아있는지 여부

info : 서블릿이나 JSP 에 대한 정보를 보여 준다.

다음과 같은 개개의 서블릿이나 JSP 에 대한 정보를 보여 준다.

서블릿이나 JSP 가 로드가 되었는지 아닌지에 대한 정보

서블릿이나 JSP 의 실제 클래스 이름

지금까지 요청된 총 횟수

사용방법은 다음과 같다.

info [ContextGroup] [Context]

즉 특정 컨텍스트 그룹의 컨텍스트에 관한 정보만을 보고 싶을 경우 컨텍스트 그룹과 컨텍스트의 이름을 입력으로 주면 되고 특정 컨텍스트 그룹에 속하는 모든 컨텍스트들에 대한 정보를 보고 싶을 경우에는 컨텍스트 그룹의 이름만 주면 된다.

단지 info 라고만 실행하게 되면 Container 의 모든 컨텍스트 그룹의 모든 컨텍스트들에 대한 정보를 다 보여 주도록 되어 있다.

다음은 MyGroup 이라는 컨텍스트 그룹의 모든 서블릿과 JSP 에 대한 정보를 보여 주는 예이다.

$$3 [webdev:webdev_servlet_engine1] info MyGroup

<<< WebContainer Name: tmaxc1_servlet_engine1 >>>

#### ContextGroup : MyGroup

#### Context : Examples


0:[ForwardTest2] <NotLoaded> class: ForwardTest2, total_reqs:

0

1:[ForwardTest1] <NotLoaded> class: ForwardTest1, total_reqs:

0

2:[CookieTest] <NotLoaded> class: CookieTest, total_reqs: 0

3:[ContentTest] <NotLoaded> class: ContentTest, total_reqs: 0

4:[SessionTest] <Ready> class: SessionTest, total_reqs: 2

5:[ForwardedPage] <NotLoaded> class: ForwardedPage,

total_reqs: 0

6:[IncludeTest2] <NotLoaded> class: IncludeTest2, total_reqs:

0

7:[/jsp/checkbox/checkresult.jsp] <Ready> class:

jsp.checkbox._jsp_checkresult _20010220170436_Impl,

total_reqs: 10

8:[IncludeTest1] <NotLoaded> class: IncludeTest1, total_reqs:

0

9:[DriverTest] <Ready> class: DriverTest, total_reqs: 61

10:[/jsp/snp/snoop.jsp] <Ready> class:

jsp.snp._jsp_snoop_20010227175446 _Impl, total_reqs: 7

11:[/jsp/directive/directive.jsp] <Ready> class:

jsp.directive._jsp_directive _20010220170442_Impl,

total_reqs: 4

12:[RequestInfoTest] <Ready> class: RequestInfoTest,

total_reqs: 2

13:[IncludedPage] <NotLoaded> class: IncludedPage,

total_reqs: 0

14:[RequestHeaderTest] <Ready> class: RequestHeaderTest,

total_reqs: 2

15:[ServletContextTest] <Ready> class: ServletContextTest,

total_reqs: 3

#### Context : DefaultContext

0:[WorkerServlet] <NotLoaded> class:

jeus.servlet.engine.WorkerServlet, total_reqs: 0

위의 예에서 MyGroup 이라는 컨텍스트 그룹은 Examples 와 DefaultCont-ext 라는 두개의 컨텍스트를 가진다.

Examples 컨텍스트에는 서블릿과 JSP 합쳐서 모두 16 개가 등록되었거나 사용 중이다.


1 번 ForwardTest1 이라는 서블릿의 경우 web.xml 에 등록은 되어 있으나 아직 로딩이 되지 않은 상태이고 클래스의 이름은 ForwardTest1.class 임을 나타낸다.

4 번 SessionTest 라는 서블릿은 로딩이 되어 Ready 상태이고 클래스의 이름은 SessionTest.class 이다. 그리고 총 요청 횟수는 2 번이다.

7 번 /jsp/checkbox/checkresult.jsp 라는 JSP 는 로딩이 되어 Ready 상태이고 실제 클래스의 이름은 jsp.checkbox._jsp_checkresult _20010220170436_Impl.class 이다. 그리고 총 요청 횟수는 10 번이다.

참고로 web.xml 에 설정이 되어 있지 않고 아직 로딩이 되지 않은 서블릿이나 JSP 에 대한 정보는 나타나지 않는다.

5.1.2 Container 의 설정 정보에 관한 명령들

Web Container 의 설정 파일인 container.xml 에 설정된 내용들에 대한 정보를 보여 주거나 동적으로 변경하는 명령들이다.

cfg : 설정파일의 내용을 보여 준다.

container.xml 에 설정된 내용을 보여 주는 것으로 다음과 같은 것들이 있다.

Container 에 관한 설정

컨텍스트 그룹에 관한 설정

컨텍스트에 관한 설정

웹서버 연결과 쓰레드 풀에 관한 설정

세션 클러스터링에 관한 정보

로깅에 관한 설정

능동적 관리에 관한 설정

응답 헤더에 관한 설정

데이터베이스 연결 풀링에 관한 설정


사용방법과 옵션은 다음과 같다. 아무 옵션없이 cfg 명령을 실행시키면 container.xml 에 설정되어 있는 모든 정보가 출력이 된다. 만약 특정한 설정에 관한 정보만을 보길 원할 때는 다음의 옵션을 사용하면 된다.

-cg:<ContextGroup> : 지정한 컨텍스트 그룹에 관한 모든 설정을 출력

-c:<Context> : 지정한 컨텍스트에 관한 설정 출력

-cn:<port> : 지정한 포트에 해당하는 웹서버 연결과 쓰레드 풀링에 관한 설정 출력

-db:<DBPoolName> : 지정한 데이터베이스 연결 풀에 관한 설정 출력

-log : 로깅에 관한 설정 출력

-sc : 세션 클러스터링에 관한 설정 출력

-am : 능동적 관리에 관한 설정 출력

-rh : 응답헤더에 관한 설정 출력

위의 옵션은 여러 개를 한꺼번에 사용할 수 있다. 예를 들어 컨텍스트 그룹이 두개 있는 상황에서 MyGroup 이라는 컨텍스트의 로그 설정만 보길 원한다면 다음과 같이 옵션을 사용해야 한다.

$$3 [webdev:webdev_servlet_engine1] cfg –cg:MyGroup –log

출력된 각 항목에서 ()로 표시된 항목은 set 명령을 통해 동적으로 그 값을 변경할 수 있는 것을 나타내며 () 안의 약자가 그 값을 바꿀 때 set 명령의 옵션이 되는 것이다. 예를 들어 다음과 같이 쓰레드 풀에 관한 설정 내용이 출력되었다고 하자.

++ Thread Pool ++

- minimum threads (tmin) : 10

- maximum threads (tmax) : 50

여기서 최소 쓰레드 개수를 5 개로 줄이려고 할 때 다음과 같이 set 명령을 사용하면 된다.

$$3 [webdev:webdev_servlet_engine1] set –cn:8101 –tmin 5

set : 설정 파일에 의해 설정된 값을 동적으로 바꾼다.


사용방법과 옵션은 다음과 같다.

-cg:<ContextGroup> : 지정된 컨텍스트 그룹에 속하는 속성을 바꾼다.

-c:<Context> : 지정된 컨텍스트에 속하는 속성을 바꾼다.

-cn:<port> : 지정된 포트의 쓰레드 풀에 관한 속성과 능동적 관리에 관한 속성을 바꾼다.

-db:<DBPoolName> : 지정된 데이터베이스 연결 풀에 관한 속성을 바꾼다.

쓰레드 풀에 관한 설정 변경 (-cn:<port> 옵션과 함께 사용)

-tmin <number> : 최소 쓰레드 개수 (MinThread)

-tmax <number> : 최대 쓰레드 개수 (MaxThread)

-trate <number> : 쓰 레 드 증 가 및 감 소 단 위 개 수 (ChangeRate)

-tidle <seconds> : 최대 idle time (초) (MaxIdleTime)

-tmwq <number> : 최대 대기 큐 사이즈 (MaxWaitQueue)

-tmq <number> : 최대 큐 사이즈 (MaxQueue)

능동적 관리에 관한 설정 변경 (-cn:<port> 옵션과 함께 사용)

-mtat <seconds> : 최 대 쓰 레 드 active time ( 초 ) (MaxThreadActiveTimeSecs)

-ts_mbt <number> : ThreadStateNotify 에서 최대 blocked 쓰레드 개수(MaxBlockedThreads)

-ts_mbtr <rate> : ThreadStateNotify 에서 최대 blocked 쓰레드 rate (MaxBlockedThreadRate)

-ar_mbt <number> : AutoRestart 에서 최대 blocked 쓰레드 개수 (MaxBlockedThreads)

-ar_mbtr <rate> : AutoRestart 에서 최대 blocked 쓰레드 rate (MaxBlockedThreadRate)

데이터베이스 연결 풀에 관한 설정 변경 (-db:<DBPoolName> 옵션과 함께 사용)


-dmin <number> : 최소 데이터베이스 연결 개수(InitCapacity)

-dmax <number> : 최대 데이터베이스 연결 개수(MaxCapacity)

-drate <number> : 데이터베이스 증가 단위 개수(IncrementRate)

-didle <seconds> : 최대 idle time (초) (MaxIdleTimeSecs)

-clac <true|false> : long active connection 을 강제로 끊을 것인지 여

부 (CloseLongActiveConnection)

-mats <seconds> : 최대 active time (초) (MaxActiveTimeSecs)

-di <true|false> : 동 적 증 가 를 할 것 인 지 의 여 부

(DynamicIncrement)

-muc <number> : 최대 사용 횟수 (MaxUseCount)

-ctos <seconds> : 데 이 터 베 이 스 연 결 얻 기 time out (초)(ConnectionTimeOutSecs)

자원 관리 간격에 관한 설정 변경

-mi <seconds> : Container 관리의 간격(초)(MonitoringIntval)

-smi <seconds> : 세션 관리의 간격(초)(SessionMonitoringIntval)

-dmi <seconds> : 데이터베이스 연결 풀 관리의 간격(초)(DBPoolMonitoringIntval)

세션 서버 관련 설정 변경

-ssn <primary>[:<secondary] : 주 세션 서버 및 백업 세션 서버 설정을 바꾸고 바뀐 서버로 연결을 다시 맺는다.

-tss <temp> : 세션 서버를 잠시동안 “temp”로 바꾼다.

그 외의 설정 변경


-stm <minutes> : 세션 time out(분), -cg:<ContextGroup>와 함께 사용 (SessionTimeoutMinute)

-ar <true|false> : auto reloading 을 할 것인지 말 것인지 여부

-c : <Context>와 함께 사용 (AutoReload)

주의: –stm 과 –ar 옵션에서 컨텍스트 그룹을 지정하지 않으면 디폴트 컨텍스트 그룹이 자동으로 지정된다. 컨텍스트 그룹이 두 개 이상일 경우 디폴트 컨텍스트 그룹은 설정 파일에서 가장 먼저 설정된 컨텍스트 그룹에 해당된다.

5.1.3 Application 조절(Control)

webadmin 에서는 Container 에서 실행되고 있는 Application 의 조절을 할 수 있다. 이러한 명령어들은 모두 컨텍스트 그룹이나 컨텍스트, 각각의 servlet 단위로 실행할 수 있다. 여기에 관련된 명령어들은 다음과 같다.

suspend : suspend 는 현재 실행중인 servlet 을 디버그 하거나 잠시 요청을 받지 않도록 할 때 사용한다. suspend 를 사용한 예는 다음과 같다.

$$1 [webdev:webdev_servlet_engine1] suspend MyGroup

Examples

Command is successfully achieved...

$$2 [webdev:webdev_servlet_engine1] info

<<< WebContainer Name: sinklare_servlet_eng1 >>>




0:[ForwardTest2] <Suspended> class=ForwardTest2

1:[ForwardTest1] <Suspended> class=ForwardTest1

2:[CookieTest] <Suspended> class=CookieTest

3:[SessionTest] <Suspended> class=SessionTest

4:[ForwardedPage] <Suspended> class=ForwardedPage

5:[IncludeTest2] <Suspended> class=IncludeTest2

6:[IncludeTest1] <Suspended> class=IncludeTest1

7:[RequestInfoTest] <Suspended> class=RequestInfoTest

8:[IncludedPage] <Suspended> class=IncludedPage

9:[RequestHeaderTest] <Suspended>

class=RequestHeaderTest

10:[ServletContextTest] <Suspended>

class=ServletContextTest


여기서는 MyGroup 의 Examples 컨텍스트에 대해 suspend 를 사용했다. 그리고 info 를 통해 Application 의 상태를 알아 보면 모두 Suspended 되어 있는 걸 볼 수 있다. 이럴 경우에는 브라우저를 통해 요청을 보내도 요청을 거절하는 화면을 볼 수 있다.

그림 5-1 Suspend 의 화면


resume : resume 은 suspend 되어 있는 servlet 의 서비스를 다시 허용할 때 사용한다. 이를 사용한 예는 다음과 같다.

$$1 [webdev:webdev_servlet_engine1] resume MyGroup

Examples


$$2 [webdev:webdev_servlet_engine1] info

<<< WebContainer Name: sinklare_servlet_eng1 >>>




0:[ForwardTest2] <Running> class=ForwardTest2

1:[ForwardTest1] <Running> class=ForwardTest1

2:[CookieTest] <Running> class=CookieTest

3:[SessionTest] <Running> class=SessionTest

4:[ForwardedPage] <Running> class=ForwardedPage

5:[IncludeTest2] <Running> class=IncludeTest2

6:[IncludeTest1] <Running> class=IncludeTest1

7:[RequestInfoTest] <Running> class=RequestInfoTest

8:[IncludedPage] <Running> class=IncludedPage

9:[RequestHeaderTest] <Running>

class=RequestHeaderTest

10:[ServletContextTest] <Running>

class=ServletContextTest


즉, 다시 모든 servlet 이 running 상태인 것을 알 수 있다.

reload : reload 는 servlet 이나 JSP 문서가 변경되었을 경우 이를 다시 읽어들어 적용하고자 할 때 사용한다. 실제로 container.xml 에서 AutoReload 를 true 로 지정해 주지 않으면 이 명령어를 사용해서 변경된 서비스를 제공할 수 있도록 해야 한다. 이 명령어도 마찬가지로 각각의 단위에 대해 사용할 수 있다.

terminate : 이 명령어는 현재 등록되어 있는 servlet 의 등록을 없애 버린다. 즉, 이 servlet 에 대한 요청이 들어오면 이 servlet 이 존재하지 않는다는 응답을 보내게 된다. 이 명령어를 사용해서 제거를 하면 더 이상 Container 에서 이 Application 에 대한 control 을 할 수 없게 된다. 예를 들어 resume 명령어를 사용해서 terminate 된 servlet 들을 다시 등록할 수는 없다.

restart : 이 명령어는 지정된 단위를 다시 Container 에 읽어 들이게 한다. 이때 Container 는 container.xml 과 web.xml 을 참고해서 각각의 단위들을 읽어 들인다. 그래서 terminate 명령어를 사용해서 등록을 제거한 단위도 다시 Container 에서 실행시킬 수 있게 된다.


5.2 JSP Batch Compiler 의 사용

JSP Batch Compiler 는 개발한 JSP 파일들을 WebtoB Web Container 를 기동하지 않고 명령 프롬프트 상에서 미리 컴파일 해 주는 도구이다.

JSP 파일은 WebtoB Web Container 가 기동된 상태에서 웹 브라우져의 요청을 받는 시점에 컴파일이 이루어진다. 따라서, 최초의 요청은 이러한 파싱 및 컴파일 과정을 거치게 되어 응답 시간이 길어지고 컴파일에 많은 자원을 소모하게 된다. 만약 개발한 JSP 소스 파일이 많고 사용자 요청이 빈번한 웹 사이트라면 최초의 요청에 걸리는 시간과 컴파일에 소모되는 자원이 무시할 수 없을 정도로 클 것이다. JSP Batch Compiler 를 이용하여 개발한 JSP 소스 파일을 미리 컴파일하고 Web Container 를 기동하면 이러한 부담을 없앨 수 있다.

JSP Batch Compiler 를 구 동 하 는 실 행 파 일

은 %W2B_JEUSHOME%\bin\jspc.bat (UNIX 의 경 우 $W2B_JEUSHOME/bin/jspc) 이다. 다음은 jspc 의 사용법이다.

C:\>jspc

JEUS Web Container version: 3.1.2

(1) jspc -e engine_name [-g grpname [-c ctxname]] [-noxml] [-f

container_xml_path]

- pre-compile the jsp files of context ctxname of

contextGroup grpname

- if ctxname omitted, entire contexts of grpname will be pre-

compiled

- if ctxname and grpname omitted, entire contexts of

engine_name will

be pre-compiled

-noxml configuration by .conf file

-g context group name to compile

-c context name to compile

-f config_file configuration file name

-h this message

-v version information

기본적으로 컴파일은 컨텍스트 단위로 이루어 진다. 필수적으로 주어야 할 옵션은 “-e engine_name”이다. 옵션을 자세히 설명하면 다음과 같다.

-e engine_name (required) : 컴파일하고자 하는 서블릿 엔진 이름이다. 예제 환경에서 예를 들면 “webdev_servlet_engine1”이 되겠다. –g 나 –c 옵션을 주지 않는다면. 이 서블릿 엔진이 서비스하는(container.xml 에 기술된) 모든 컨텍스트 그룹의 모든 컨텍스트들을 컴파일한다.

-g grpname (optional) : 컴파일하고자 하는 컨텍스트 그룹의 그룹이름( container.xml 에서 GroupName 으로 지정한)이다. 예제 환경에서 예를 들면 “MyGroup”이 되겠다. –c 옵션을 주지 않으면 이 컨텍스트 그룹의 모든 컨텍스트들을 컴파일 한다.


-c ctxname (optional) : 컴파일하고자 하는 컨텍스트의 컨텍스트 이름( container.xml 에서 ContextName 으로 지정한)이다. –g 옵션으로 이 컨텍스트가 속한 컨텍스트 그룹의 그룹 이름을 반드시 지정해야한다. 이 컨텍스트만 컴파일할 때 사용한다.

-noxml : container.xml 이나 web.xml 이 아닌 container.conf, web.conf 로부터 환경을 읽어들이고자 할 때 이 옵션을 사용한다.

-f config_filename : container.xml 이나 container.conf 파일(-noxml 옵션과 같이 사용하는 경우) 을 따로 지정할 때 이 옵션을 사용한다.


아래는 JSP Batch Compiler 를 이용하여 예제 환경의 “Examples” 컨텍스트를 컴파일 하였을 때 결과 화면이다.

C:\> jspc –e webdev_servlet_engine1 –g MyGroup –c Examples

………

………

[BatchCompiler] === result ===

[BatchCompiler] === Examples ===

[BatchCompiler] << success >>

[BatchCompiler] /examples/jsp/plugin/plugin.jsp

[BatchCompiler] /examples/jsp/sessionlistener/carts.jsp

[BatchCompiler] /examples/jsp/forward/two.jsp

[BatchCompiler] /examples/jsp/error/err.jsp

[BatchCompiler] /examples/jsp/directive/directive.jsp

[BatchCompiler] /examples/jsp/customtag/customtag.jsp

[BatchCompiler] /examples/jsp/javabeans/javabeans.jsp

[BatchCompiler] /examples/jsp/session/carts.jsp

[BatchCompiler] /examples/jsp/error/errorpge.jsp

[BatchCompiler] /examples/jsp/include/next.jsp

[BatchCompiler] /examples/jsp/checkbox/checkresult.jsp

[BatchCompiler] /examples/jsp/upper.jsp

[BatchCompiler] /examples/jsp/forward/one.jsp

[BatchCompiler] /examples/jsp/include/include.jsp

[BatchCompiler] /examples/jsp/snp/snoop.jsp

[BatchCompiler] /examples/jsp/forward/forward.jsp

[BatchCompiler] << fail >>

[BatchCompiler] /examples/jsp/customtag12/date.jsp

[BatchCompiler]

=====================================================

[BatchCompiler] total : 17 success : 16 fail : 1

[BatchCompiler]

=====================================================


특정 JSP 소스를 컴파일하는 도중 실패하게 되면 에러 메시지를 보여주고 다음 JSP 소스로 넘어간다. 결과 리스트에 컴파일을 시도한 JSP 소스 파일 목록 및 성공/실패한 소스 파일 목록을 보여 준다.

6 Web Application 의 개발

6.1 Web Application 이란?

“Web Application”이란 말은 Java Servlet Specification 에서 정의된 것으로 online Application 의 각종 interface 를 만드는 server 쪽의 자원들의 모임을 말한다. 즉, 간단히 말해서 여러 가지 자원들을 이용해서 client 의 요청에 응답하는 server 에서 운영되는 일종의 프로그램이라고 할 수 있다. 이 자원들에는 다음과 같은 것들이 포함된다.

Servlets

JavaServer Pages

HTML pages

Server side classes

특정한 Web Application 에 포함되는 여러가지 자원들


이 specification 에서는 이런 자원들이 옮기기 좋은 “Web Application archive”(WAR) 파일로 어떻게 묶는지 정해 놓아서 이들이 WAR 표준

을 지원하는 Application server 에 설치(deployment)될 수 있도록 해준다. 하나의 Web Application 은 server 에서 돌아가는 다른 Web Application 과 분리된 환경인 servlet context 안에서 운영된다. 각각의 Web Application은 자신 안의 자원들을 묶어주고 WebtoB Servlet Engine 에 어떻게 설치

되었는지를 나타내 주는 deployment descriptor 를 가지고 있다.

J2EE specification 에서는 Web Application 이 어떻게 EJB 같은 다른 server 쪽의 자원들과 작용하는지를 정의하고 있어서 전체적인 J2EE specification 을 따르는 Application 을 구성할 수 있다.

WebtoB Web Container 는 Servlet 2.3 PFD2 specification 을 지원하고 있고 여러 개의 Web Application 을 운영할 수 있다.

6.2 Web Application 작성

Web Application 은 WAR 파일로 묶이고 WebtoB Servlet Engine server 에 설치되기 위해서 정해진 방법을 따라야 한다. 각각의 Web Application 은 server 에 어떻게 설치되었는지를 나타내는 deployment descriptor 를 가지고 있다. 제대로 설계된 Web Application 은 설치된 환경이나 server 에 존재하는 다른 자원들의 위치에 관계없이 구현될 수 있다. Deployment descriptor 는 servlet 소스 파일을 다시 컴파일하지 않고도 server 의 환경에 Web Application 을 맞출 때에 쓰인다.

Web Application 을 WebtoB Servlet Engine 에 설치하기 위해서는 이 Application 의 descriptor 도 제대로 작성되어야 하겠지만, 이 Application을 WebtoB Servlet Engine 에 등록하기 위해 WebtoB Web Container 의 descriptor 도 수정을 해야 한다. 앞의 관리 부분에서 container.xml 을 다

루었고 여기서는 Application 의 descriptor 인 web.xml 의 작성을 다루기

로 한다.


6.2.1 WAR 란?

웹 아카이브(Web ARchive)는 자바 플랫폼에서 표준 압축 파일 포맷인 JAR 의 형태를 취하고 있다. 보통의 JAR 파일과 다른 점은 포함되어 있는 파일들이 어떻게 웹 기반의 Application 을 구현하는데 사용되는지에 대한 특수한 설명자(descriptor) 파일이 더 들어있다는 점이다. 이 파일의 확장자는 보통 .war 를 사용한다. 따라서 war 파일을 만들려면 JDK 에 포함된 jar 를 사용해서 압축을 하고 확장자를 war 로 바꾸어 주기만 하면 된다.

자바 웹 Application 의 모든 파일은 하나의 최상위(root) 디렉토리를 기준으로 하여 디렉토리 구조에 맞게 배치되어 있다. 따라서 모든 파일의 URL 은 동일한 하나의 디렉토리를 기준으로 시작한다. 예를 들어 jeus 라는 이름을 가진 Application 이 있다면 이 Application 의 모든 리소스는 jeus 라는 이름의 최상위 디렉토리 혹은 그 하부의 디렉토리에서 액세스할 수 있다.

또한 하나의 Application 을 구성하는 모든 자바 기반 리소스(servlet 이나 JSP)들은 javax.servlet.ServletContext 인스턴스를 공유한다. 이 인스턴스는 한 Application 을 구성하는 모든 JSP 페이지들이 Application 내부 객체를 통해 사용할 수 있다. (JSP 의 내부 객체에 대한 설명은 11 장 JSP 의 구현에 있다.)

WAR 파일은 한 단위의 Application 을 구성하는 리소스를 묶어 저장할 수 있도록 설계되었다. 또한 WAR 파일은 앞에서 말했듯이 servlet Container 에 등록이 되어야 사용 가능하다.


6.2.2 설명자(Web Application Descriptor)란?

웹 Application 을 이루는 내용물 외에, WAR 파일에는 배포용 설명자 파일이 첨부되어 있다. 여기에는 servlet 에 관련된 초기화 매개변수나 URL 매핑을 제공하는 부분 같이, 이 war 파일에 들어있는 파일들이 Application 내에서 어떤 구실을 하는지에 대해 설명되어 있다.

이 파일의 이름은 web.xml 이며 WAR 파일의 루트 디렉토리에 위치한 WEB-INF 서브 디렉토리의 밑에 있다. 이 디렉토리는 JAR 파일에 있는 META-INF 디렉토리와 비슷하여 압축 파일 자체에 대한 메타 정보를 가지고 있다.

이 파일의 확장자가 말해 주듯, web.xml 파일은 XML 을 사용하여 작성한다. 이 파일의 예를 들면 다음과 같다.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app

PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application

2.2//EN"

"file://c:/webtob/jeus/config/dtds/web-app_2_2.dtd">

<web-app>

<context-param>

<param-name> dbDriver </param-name>

<param-value> oracle.jdbc.driver.OracleDriver </param-

value>

</context-param>

<servlet>

<servlet-name> environmentInit </servlet-name>

<servlet-class> EnvironmentInitServlet </servlet-class>

<load-on-startup> 1 </load-on-startup>

<init-param>

<param-name>ConfigFile</param-name>

<param-value> /environment.dat </param-value>

</init-param>

</servlet>

<servlet>

<servlet-name> main-menu </servlet-name>

<jsp-file> /main-menu.jsp </jsp-file>

</servlet>

<session-config>


</session-config>

<welcome-file-list>

<welcome-file> index.html </welcome-file>

</welcome-file-list>

<taglib>

<taglib-uri>

http://java.apache.org/tomcat/examples-taglib

</taglib-uri>

<taglib-location>

/WEB-INF/jsp/example-taglib.tld

</taglib-location>

</taglib>

<mime-mapping>

<extension> wml </extension>

<mime-type> text/vnd.wap.wml;charset=KS_C_5601-1987

</mime-type>

</mime-mapping>

</web-app>


6.2.3 WAR 파일 만들기

여기서는 Web Application 을 이루고 있는 각각의 파일들이 실제 WAR 파일이나 이 파일을 풀어 놓은 디렉토리 아래에서 어디에 존재해야 되는지를 서술하고 있다. 또한 WAR 파일을 만드는데 꼭 작성해야 할 web.xml 에 대한 설명도 하고 있다.

web.xml 을 작성할 때에는 에디터를 이용해 작성할 수 있다. 하지만 이 경우 모두 web.xml 의 항목에 대한 이해가 필요하다. 여기서는 먼저 WAR 파일 전반에 대한 이야기와 web.xml 에 대한 것을 간단히 살펴 보도록 한다.


6.2.3.1 WAR 파일의 내용

앞에서도 이야기 했듯이, WAR 파일은 웹 Application 배포용의 추가 정보를 더 가지고 있는 JAR 파일이다. 이 추가 정보는 WAR 파일의 최상위 서브 디렉토리인 WEB-INF 에 저장되어 있으며, 이 디렉토리에는 web.xml 이란 배포 설명자 파일 외에도 자바 클래스를 저장할 용도로 준비된 두개의 특수한 서브 디렉토리가 포함되어 있다. WAR 파일의 전체 구조는 다음 그림과 같다.

그림 6-1 WAR 파일의 전체 구조 화면

위의 그림에서와 같이 이 컨텐트는 대부분 JSP 페이지, HTML 문서, 이미지 파일로 구성되어 있다. 하지만, 웹 프로토콜을 통해 전송될 수 있는 것이라면 어떤 파일도 WAR 파일에 담길 수 있다.

이 컨텐트들은 Application 의 이름으로 시작하는 URL 을 통해 액세스된다. 만약 disc.war 라는 파일의 내부가 다음과 같다고 가정해 보자.

Main.jsp


Docs/rules.html

Game/catch.jsp

Images/icons/ring.gif

WEB-INF/web.xml

WEB-INF/classes/RingControlServlet.class

WEB-INF/lib/disc-classes.jar

WEB-INF/lib/discTags_1_0.jar

WEB-INF/tlds/discTags_1_0.tld

이 Application의 Main.jsp 파일을 액세스 하려면 http://server/disc/Main.jsp 의 형식으로 URL을 지정하면 된다. 이때 disc라는 이름은 이 Application의 컨텐트를 참조하는 모든 URL의 최상위 디렉토리가 된다. 또한 ring.gif를 가져오기 위한 URL은 http://server/disc/images/icons/ring.gif이 된다.

[최상위 디렉토리에 관한 문제들]

위의 war 파일 내부에는 disc 라는 이름의 최상위 디렉토리에 대하여 언급해 놓은 부분은 한군데도 없다. 이 디렉토리의 이름은 일단 Application 이 Container 에 등록되기만 하면 Container 가 자동으로 인식한다. 그리고 Application 의 이름은 war 파일의 이름과 상관없이 아무렇게 지정할 수 있다. 실제로 이렇게 war 파일을 Container 에 등록하는 것은 다음 장에서 설명할 container.xml 에서 하는 것이다.

따라서 최상위 URL 디렉토리는 Container 에 의해 결정된다. Application 에 매핑된 디렉토리 이름은 URL 을 해석하여 war 파일로부터 가져올 파일 이름으로 해독할 때 내부적으로 URL 에서 제거된다. 이는 Application 내에서 다른 문서나 리소스의 경로를 절대 URL 로 사용할 때 문제가 될 수 있다. 즉, 실제로 사용할 때의 최상위 URL 디렉토리 이름을 모르기 때문에 절대 URL 을 지정할 수 없을거란 생각이 든다.

이를 해결하기 위해서 JSP 문서의 경우에는 JSP Container 에서 절대 URL 을 사용하는 웹 리소스를 처리할 경우에 최상위 디렉토리 지정을 자동으로 맡아 주게 되어 있다. 이런 경우에는 JSP 문서 내에서 <jsp:include>나 <jsp:forward> tag 를 사용할 경우가 있다. 만약 앞의 war 파일 예제에서 Main.jsp 내에 game 디렉토리의 catch.jsp 로 제어를 옮길 때는 다음과 같이 절대 경로를 사용한다.

<jsp:forward page=”/game/catch.jsp” />


만약 Main.jsp 가 들어 있는 이 Application 의 이름이 disc 라면 JSP 는 위의 tag 를 처리하면서 자동으로 이 페이지를 /disc/game/catch.jsp 의 절대 URL 에서 참조할 수 있게 해 준다.

하지만 표준 HTML 태그를 사용하여 참조하는 URL 은 자동 매핑이 되지 않는다. 이를테면 <IMG> 태그의 SRC 속성이나 <A> 태그를 사용할 때가 해당된다. 이를 해결하기 위해서는 WebtoB Servlet Engine 에 설치되는 Application 의 이름을 직접 정해서 절대 경로에 사용하는 방법이 있지만, 이렇게 하면 후에 WebtoB Servlet Engine 에 설치할 때 다른 이름으로 Application 을 설치하면 제대로 동작하지 않을 것이다.

좀더 유연하게 해결하기 위한 방법은 HTML 의 <BASE> 태그를 사용하는 것이다. 이를 사용하면 이 문서의 모든 상대 URL 은 지정된 절대 경로 값을 기준으로 만들어진다. 즉, 다음과 같이 작성하면 해결될 것이다.

<HTML>

<HEAD>

<BASE href=”<%=request.getContextPath() %>/”>

…

</HEAD>

<BODY>

<A href=”game/catch.jsp”>

…

</BODY>

</HTML>

여기서 사용된 javax.servlet.http.HttpServletRequest 클래스의 getContextPath() 메소드는 들어온 요청에 해당하는 최상위 디렉토리, 즉 WebtoB Servlet Engine 에 설치된 Application 의 이름에 매핑된 디렉토리를 가져다 준다. 이렇게 해서 getContextPath()의 반환값은 “/disc”가 되므로 <BASE> 태그의 href 에는 이 값에다가 끝에 ‘/’를 붙여 준다.

그래서 예에서 쓴 ”game/catch.jsp” 는 실제로는 “/disc/game/catch.jsp”로 바뀌게 된다. 이렇게 한다면 Application 에서 URL 을 쓰는 것이 절대 URL 과 거의 비슷해지고, 설치된 Application 의 이름인 최상위 URL 디렉토리를 앞에다 붙일 필요가 없게 된다.

6.2.3.2 WEB-INF 의 파일들

WAR 에 있는 파일 중 WEB-INF 의 파일들과 서브 디렉토리들은 URL 로 액세스할 수 없게 되어 있으며 WebtoB Servlet Engine 에 의해 내부적으로 사용되도록 예약되어 있다. 이 파일들은 다음과 같은 종류로 나눌 수 있다.

web.xml descriptor file : 이 파일은 앞에서 말했듯이 WebtoB Servlet Engine 가 WAR 파일 안의 파일들을 가지고 Application 을 실행시키는데 필요한 정보를 가지고 있다. 이 장의 나머지에서 이 파일을 다루고 있다.

class files : 컴파일된 자바 클래스 파일들은 WEB-INF 디렉토리의 classes 라는 디렉토리 아래에 있게 되는데, 만약 어떤 package 에 있는 클래스 파일들은 이 디렉토리 아래의 package 에 해당하는 디렉토리들 아래에 있다. 이 파일들은 다음의 종류로 나눌 수 있다.

servlet class file : servlet 클래스 파일들은 실제 요청을 처리하는 클래스 파일들이다. web.xml 에서 <servlet-class> tag 안에 servlet 클래스 파일의 이름만 적어 두었다면 WebtoB Servlet Engine 는 이 클래스 파일을 WEB-INF 디렉토리 바로 밑에서 찾게 된다.

다른 클래스 파일들 : servlet 클래스 파일 이외의 파일들은 servlet 이나 JSP 문서에서 사용하는 자바빈즈(JavaBeans) 같은 클래스들이다. 즉, 수행중인 servlet 이나 JSP 문서에서 어떤 자바 클래스를 사용한다면 WebtoB Servlet Engine 는 자신이 갖고 있는 기본적인 API 들과 해당 Application 의 WEB-INF 디렉토리 밑에서 그 클래스 파일들을 찾는다.

JAR 파일 : 이 파일은 WEB-INF 디렉토리의 lib 서브 디렉토리에 저장되어 있다. classes 디렉토리 아래의 클래스 파일들과 마찬가지로 JAR 파일 내에 있는 모든 클래스 파일들도 해당 Application 에 대한 액세스 요청에 대해 WebtoB Servlet Engine 이 반응할 때 자동으로 JVM 의 클래스에 덧붙여진다. 즉, 클래스 파일들을 묶어놓은 파일이라고 볼 수 있다.


TLD 파일(Tag Library Discriptor) : 이 파일은 custom tag 라이브러리에서 사용하는 파일로서, 이 파일이 위치한 서브

디렉토리의 이름은 보통 tlds 이다. 여기에 관한 내용은 11 장 JSP 구현의 custom tag 항목을 찾아 보길 바란다.

6.2.3.3 WAR 파일을 만드는 방법

war 파일은 jar 파일의 형식을 따른다. 따라서 JDK 에 포함되어 있는 jar 프로그램을 사용해서 jar 파일로 묶은 다음 이 파일의 확장자를 war 로 바꾸어 주기만 하면 된다.


6.2.3.4 배치 설명자(Deployment Descriptor)의 작성

[web.xml 의 전체 구성]

다른 XML 문서와 마찬가지로 web.xml 은 항상 표준 XML 헤더로 시작한다. 보통, XML 버전 번호와 문서의 문자 인코딩을 선언하는 태그가 먼저 오고, 문서 타입 정의(Document Type Difinition: DTD)가 그 뒤를 따른다. DTD 는 이름에서 알 수 있듯이 주어진 문서의 타입에 대하여 유효한 태그를 정하고 있어서 XML 문서의 문법을 검증할 때 사용한다.

web.xml 의 경우, DTD 는 Sun 사가 이미 J2EE specification 을 발표할 때 규정되어 있다. 그래서 web.xml 파일에 들어있어야 하는 헤더는 아래와 같다.

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web

Application 2.3//EN" "http://java.sun.com/j2ee/dtds/web-

app_2_3.dtd">

배포 설명자 파일의 기본이 되는 요소(element)는 <web-app> 태그이다. Web. xml 파일을 이루는 요소는 헤더를 제외하고 모두 이 태그의 몸체에 위치해야 한다. 그리고 Application 자체의 프로퍼티를 설정하려면 별도로 준비된 <web-app> 태그의 하위요소 태그 몇 가지를 사용한다. 예를 들면 다음과 같다.

<web-app>

<description>

Sample

</description>

<display-name>SAMPLE</display-name>

<icon>

<large-icon>/icon/sample32x32.gif</large-icon>

<small-icon>/icon/sample16x16.gif</small-icon>


</icon>

<welcome-file-list>

<welcome-file>default.html</welcome-file>

<welcome-file>index.jsp</welcome-file>

</welcome-file-list>

<distributable/>

</web-app>

하위 요소 태그는 안써도 상관은 없다. <description> 태그는 Application 을 문서화할 때 사용하는 것으로 Application 에 대한 설명을 나타낸다. <icon> 태그들은 실제로 쓰이지 않는 태그들이다. <display-name> 태그도 마찬가지이다.

<welcome-file-list> 태그는 사용자가 Application 디렉토리 만으로 구성된 URL 을 요청했을 때 사용자에게 보여진 첫 페이지를 지정한다. 파일의 이름은 <welcome-file> 태그로 지정하는데, 각 순서에 따라 파일이 존재하면 보여지고 존재하지 않으면 다음 순서의 태그에 지정된 파일을 보여주게 된다. 지정된 모든 파일이 존재하지 않으면 에러 메시지가 브라우저에 나타난다.

<distributable> 태그는 현재의 Application 이 분산처리가 가능한지 아닌지를 알리는 역할만 수행한다. 즉, 이 Application 이 여러 개의 Container 사이에서 분산처리를 지원하도록 만들어졌는지를 나타내는 태그인데, WebtoB Servlet Engine 에서는 사용되지 않고 있다.

[Servlet 정보 구성하기]

Web Application 에서 동작하는 servlet 은 배포 설명자에서 <servlet> 태그와 이 태그의 하위 요소를 가지고 지정하면 된다. 다음의 예제를 보자.

<web-app>

…

<servlet>

<servlet-name>ringControl</servlet-name>

<servlet-class>

jeus.RingControlServlet

</servlet-class>

<description>

Sample servlet

</description>

<display-name>Ring controller</display-name>

<icon>

<small-icon>/icon/sample16x16.gif</small-icon>

</icon>

<init-param>

<param-name>ringCount</param-name>

<param-value>7</param-value>

<description>

initial number of ringCount

</description>

</init-param>

<load-on-startup>3</load-on-startup>

</servlet>

…

</web-app>

<servlet> 태그의 몸체에는 <description>, <display-name>, <icon>이 들어가서 앞의 (web-app> 태그에서 쓰였던 것과 비슷한 역할을 할 수 있다. 이 외의 태그 기능은 각각의 servlet 마다 다른 것들이다. 이 태그들 중 필수적인 요소는 <servlet-name> 과 <servlet-class>이다. 각각의 태그를 살펴 보면 다음과 같다.

<servlet-name> : 이 태그는 servlet의 이름을 지정하는 태그이다. URL에서 server의 이름 뒤에 Application의 이름, 이 태그의 몸체에 오는 값인 servlet의 이름을 사용하면 이 servlet을 호출할 수 있다. 즉, disc Application에 이 ringControl servlet이 있다면 http://server/disc/ringControl 의 URL로 이 servlet을 액세스할 수 있는 것이다.

<servlet-class> : 이 태그는 해당 servlet 을 구현한 자바 클래스를 지정한다. 위의 예에서는 jeus package 에 있는 RingControlServlet 클래스가 지정되었다. 이때 이 클래스 파일은 WEB-INF/classes/jeus/ 에 존재할 것이다.


<init-param> : 요청이 들어오면 servlet 클래스의 인스턴스를 만들고 난 후, Container 는 요청을 처리하기 전에 servlet 클래스의 init() 함수를 호출한다. 이 메소드에 넘겨지는 초기화 매개변수는 javax.servlet.ServletConfig 클래스의 인스턴스를 통해 설정되는데, 이 매개변수를 지정하는 태그가 <init-param> 이다. 이 태그에는 세 개의 하위 태그가 있다. 이들은 다음과 같다. 이중 <description> 만 선택 요소이고 나머지는 필수 요소이다.

<param-name> : 이 태그의 몸체에는 매개 변수의 이름이 온다.

<param-value> : 이 태그의 몸체에는 매개 변수의 값이 온다. 이때 이 매개변수는 String 객체로 servlet 에 전달된다.

<description> : 이 태그의 몸체에는 매개 변수의 설명을 쓰는 곳으로 문서화할 목적으로만 쓰인다.

<load-on-startup> : 이 태그가 <servlet> 태그 내에 있으면 WebtoB Servlet Engine 가 처음 실행되는 과정에서 이 servlet 을 미리 Container 의 JVM 에 올리고 초기화시켜 둔다. 만약 이 태그가 없다면 이 servlet 에 대한 요청이 오기 전까지는 servlet 을 로드하지 않게 된다. 이 몸체에는 정수가 올 수 있는데, 이 값은 servlet 을 로드하는 우선순위로 값이 작을수록 우선순위가 높다.

Servlet 의 정보를 나타내는 태그는 <servlet> 태그 이외에도 <servlet-mapping> 이라는 태그가 있다. 이는 servlet 의 대체(alternative) URL 을 지정하는 것으로 <servlet> 태그에서 지정한 이름으로 URL 을 쓰지 않고 다른 임의의 URL 로 요청할 수 있도록 해 준다. 이는 실제의 servlet 파일이나 이름을 client 로부터 감추려고 할 때 사용한다. 이 태그의 예는 다음과 같다.

<web-app>

…

<servlet-mapping>

<servlet-name>ringControl</servlet-name>

<url-pattern>/ringmaster</url-pattern>

</servlet-mapping>

…

</web-app>

<servlet-mapping> 태그의 하위 요소는 다음과 같다.

<servlet-name> : 대체 URL 을 지정할 servlet 의 이름을 지정해 준다. 이때 이 servlet 은 다른 곳에서 <servlet> 태그를 통해 정의되어 있어야 한다.


<url-pattern> : 대체 URL 을 지정한다. 이때 이 servlet 을 요청하기 위해서는 Application 의 이름 뒤에 이 대체 URL 을 지정한다. 이 URL 은 /ringmaster/blue/fly 처럼 여러 개의 디렉토리 레벨도 포함시킬 수 있고, /ringmaster/blue/* 처럼

지정하면 이러한 디렉토리 패턴으로 시작하는 모든 요청을 이 servlet 이 받게 된다. 또한 *.disc 라고 하게 되면 .disc 의 확장자를 가진 파일에 대한 모든 요청을 이 servlet 에 매핑시킨다.


[JSP 정보 구성하기]

배포 설명자에 JSP 문서를 지정해 둘 때에는 위에서 살펴본 <servlet> 태그를 그대로 이용한다. 이는 JSP 문서가 곧 servlet 으로 취급되기 때문이다. Servlet 의 정보를 지정해 줄 때 사용하는 것과 다른 것은 <servlet> 태그 내의 <servlet-class> 태그가 <jsp-file> 태그로 바뀌어서 이 servlet 에 해당하는 JSP 파일의 전체 경로를 지정해 주는 것이다. 이 경우의 예는 다음과 같다.

<web-app>

…

<servlet>

<servlet-name>startPage</servlet-name>

<jsp-file>/game/start.jsp</jsp-file>

<description>

Sample servlet

</description>

</servlet>

…

</web-app>

여기서 주의할 것은 <jsp-file> 태그의 몸체에는 Application 의 이름을 나타내는 최상위 디렉토리가 들어있지 않는 것이다.

[Custom tag library 의 지정]

JSP 문서에서 사용하는 custom tag library 는 문서 내의 taglib 지시자(directive) 태그를 통해 JSP 페이지에 로드되며, 이 지시자 태그는 URL 을 기준으로 하여 태그 라이브러리의 위치를 찾는다. 이 URL 은 web.xml 에서 지정한다.

Custom tag 라이브러리는 두가지 요소로 구성되어 있는데, custom tag 를 구현한 자바 클래스와 라이브러리의 태그와 태그를 구현한 클래스들의 매핑 정보를 제공하는 TLD 파일이다.

태그 라이브러리의 클래스는 대개 JAR 파일로 묶이고, Application 의 WEB-INF/lib 디렉토리에 저장된다. 또는 WEB-INF/classes 디렉토리의

package 별 디렉토리에 들어 있을 수도 있다. TLD 파일은 대개 WEB-INF 디렉토리의 tlds 디렉토리에 저장된다.

Taglib 지시자는 이 지시자의 uri 속성에 설정된 TLD 파일을 참조하여 custom tag 라이브러리를 읽어 들인다. WEB-INF 디렉토리에 들어 있는 파일들은 URL 로 액세스할 수 없게 되어 있기 때문에 TLD 파일에 대한 매핑 정보를 제공해야 한다. 이 정보를 web.xml 에 <taglib> 태그로 해 주는 것이다. 다음의 예를 보자.

<web-app>

…

<taglib>

<taglib-uri>/discTags</taglib-uri>

<taglib-location>/WEB-INF/tlds/discTags_1_0.tld</taglib-

location>

</taglib>

…

</web-app>

위의 예와 같이 <taglib> 태그는 두개의 하위 요소를 가지고 있다.

<taglib-uri> : JSP 문서에 적힌 taglib 지시자가 TLD 를 액세스하기 위한 URI 를 지정하는 태그이다.

<taglib-location> : TLD 파일의 위치를 지정한다.


하나의 web.xml 파일 안에는 여러 개의 custom tag 라이브러리를 사용할 때에 여러 개의 <taglib>가 있을 수 있다.

[MIME 타입 지정]

웹 서버는 웹 브라우저로 문서를 보낼 때마다 그 문서의 타입 설정 정보를 가지고 있다. 이것을 MIME(Multi-purpose Internet Mail Extension)이라고 한다. 이는 원래 전자메일에 첨부되는 파일로, 보내어지는 문서를 인식할 용도로 개발되었지만, 현재는 WWW 에서 문서 타입을 인식하는 것 외에 많은 Application 에서 사용되고 있다.

대부분의 웹 서버에서는 특정한 파일 확장자와 MIME 타입이 매핑되어 있는 상태로 설정되어 있다. .html 로 끝나는 파일은 text/html 의 MIME 타입으로 연결되어 있으며 .doc 로 끝나는 파일은 Application/msword 의 MIME 타입과 연결되어 있다. 브라우저에서는 이 MIME 타입에 따라 데이터를 처리한다.

WebtoB Servlet Engine 에서 동작하는 웹 Application 의 경우에는 이 Application 에서 생성되는 응답 정보에 MIME 타입을 연결하는 일은 Application 에서 알아서 해야 한다. 만약 표준 확장자 이외의 문서 타입을 포함하고 있는 Web Application 을 배포할 경우에는 확장자를 인식시키는 일과 MIME 타입을 할당하는 일을 직접 해야 한다. 이 때 web.xml 파일에서 사용하는 태그가 <mime-mapping>이다.

<webapp>

…

<mime-mapping>

<extension>pdf</extension>

<mime-type>Application/pdf</mime-type>

</mime-mapping>

…

</webapp>

<mime-mapping> 태그의 하위 요소는 다음과 같다.

<extension> : 파일 확장자를 특정한 MIME 타입에 매핑시킬 때 사용한다.

<mime-type> : 매핑될 MIME 타입을 지정한다.

한 web.xml 안에는 <mime-mapping> 태그가 여러 개 올 수 있다. 각각의 확장자에 매핑되는 MIME 타입은 꼭 하나이어야 하지만, 여러 개의 확장자가 같은 MIME 타입을 가질 수는 있다.

[Container 의 동작 설정]

배포 설명자는 지금까지 설명한 JSP 와 servlet 의 구성정보를 지정할 수 있는 용도 외에도 실행중인 JSP Container 의 특정 사항을 조정할 때에도 사용한다. 즉, 에러가 발생했을 때 제어가 옮겨지는 servlet 과 JSP 페이지를 설정하거나 Application 리소스에 대한 액세스를 제어하는데 필요한 보안상의 제약도 가능하다. 이러한 tag 에는 다음과 같은 것이 있다.

<session-config> : 이 태그는 Application 의 servlet 과 JSP 페이지에서 생성된 세션의 디폴트 타임 아웃 값을 설정할 때 사용한다. 이 태그 안에는 <session-timeout> 태그가 필수로 들어가야 하며 이 태그의 몸체에 분 단위로 세션 타임 아웃 값이 들어간다. 이 경우의 예는 다음과 같다.


<web-app>

…

<session-config>


</session-config>

…

</web-app>

이 경우의 타임 아웃 값은 30 분이 된다.

<context-param> : 이 태그는 <servlet> 태그 안의 <init-param> 태그와 비슷하게 초기화 매개변수를 지정하는 태그로서 <init-param> 태그가 ServletConfig 객체의 초기화 매개변수를 설정하는데 비해 <context-param>은 ServletContext 객체의 초기화 매개변수를 지정한다. 이 태그도 <init-param> 태그와 같이 <param-name>, <param-value>, <description>의 세가지 태그를 가지고 있다. 이 값은 ServletContext 객체의 getInitParameter() 메소드를 사용하여 가져올 수 있다. 또한 JSP 페이지에서는 Application 내부 객체를 통해 사용이 가능하며 이 Application 안의 servlet 과 JSP 문서는 모두 사용할 수 있다. 따라서 여러 리소스 사이에서 공유해야 하는 구성 데이터를 지정할 때 아주 편리한 방법으로 사용할 수 있다.

[Error page 의 설정]

web.xml 에서는 이 Application 에서 HTTP error 가 발생했을 때 WebtoB Servlet Engine 가 브라우저로 보내 주는 Default 화면이 아닌 지정된 HTML 문서나 servlet, JSP 가 수행되도록 하는 설정을 할 수 있다. 이는 <error-page> 태그로 설정할 수 있다. 이 태그 안에는 설정 항목에 따른 하위 요소들이 오게 되는데 이들은 다음과 같은 것들이 있다.


<error-code> : 이 태그의 몸체에는 적용할 error code 를 지정한다. 이 code 번호는 HTTP 1.0 이나 1.1 RFC 문서에 규정되어 있다. 예를 들어 요청한 파일이 발견되지 않는다는 404 (File Not Found)번 error 인 경우 ErrorProcessor 라는 servlet 을 실행시킬 경우 다음과 같이 설정한다.

<error-page>

<error-code> 404 </error-code>

<location> /ErrorProcessor </location>

</error-page>

<location> : 이 태그의 몸체에는 위의 예와 같이 실제 호출되는 servlet 이나 JSP, HTML 문서 등을 지정한다. 이때 이 파일의 path 는 다른 태그의 설정과 마찬가지로 컨텍스트 디렉토리부터 시작한다. 즉, 위의 예에서 이 Application 의 컨텍스트 디렉토리가 app 라면 ErrorProcessor 는 app/ErrorProcessor 에 있게 된다.


6.3 WebtoB Servlet Engine 에 Web Application 등록하기

WebtoB Web Container 에 Web Application 을 등록하기 위해서는 Container 의 설정 파일인 container.xml 에 Web Application 을 등록하는 절차가 필요하다. 이렇게 등록하는 것은 GUI tool 인 admin tool 에서 할 수도 있고 직접 container.xml 의 설정을 고칠 수도 있다. 이런 과정은 5 장 container.xml Reference 의 컨텍스트 설정 항목을 참조하기 바란다.

7 Servlet 의 개요

7.1 Servlet 이란?

일반적으로 Servlet 은 server 에 들어오는 request 를 처리하고 response 를 보내는, server 에서 실행되는 program 이다. 이는 CGI 와 비슷하지만, server 에서 실행된다는 점을 빼고는 applet 과 비슷하다. Applet 이 client 의 Java Virtual Machine(JVM)에서 실행되는 class 이라면 Servlet 은 server 의 JVM 에서 실행되는 class 라고 할 수 있다. (server-side java)

HTTP servlet 은 HTTP request 를 처리해서 HTTP response 를 전달하는 java class 이다. 우리가 원하는 servlet 을 구현하기 위해서는 HTTP protocol 을 처리하는 기본적인 기능을 제공하는 javax.servlet. http.HttpServlet 을 상속받아서(extends) 구현한다.

WebtoB Servlet Engine는 Java Servlet Specification 2.3 PFD2 와 여기에 설

정 되 어 있 는 API 들 을 구 현 하 고 있 다 . 이 specification 은 http://java.sun.com/products/ servlet/index.html에서 구할 수 있다. 쇼핑몰이

나 온라인 서점같이 복잡한 Web Application을 구현하기 위해서는 이런 API들을 사용하게 된다.

7.2 WebtoB Servlet Engine 에서 지원하는 HTTP Servlet

HTTP servlet 의 code 에서는 RMI, JDBC 같은 WebtoB Servlet Engine 의 server-side service 들을 모두 사용할 수 있다. 다음은 HTTP servlet 에서 가능한 service 들이다.


Session 유지(Session Tracking) : session 은 일반적으로 stateless protocol 인 HTTP 를 사용하는 website 에서 각각의 사용자들의 정보를 가지고 있게 해준다. 이는 shopping cart 나 경매 같은 기

능을 수행하는 site 에서는 핵심적인 기능이다.

Database access : servlet 에서는 JDBC driver 를 이용하여 기본적

인 database access 를 할 수 있다. WebtoB Servlet Engine 에서는 DB connection pooling 을 지원하므로 부하가 많이 걸리는 DB connection 을 맺고 끊는 작업을 매번 access 할 때마다 하지 않

아도 되도록 구현되어 있다.

Configuration and management : WebtoB Servlet Engine 에서는 servlet 을 관리하는 console 프로그램을 제공하고 있다.


Integrated service : WebtoB Servlet Engine 의 HTTP servlet 은 JDBC, RMI, JavaBeans 같은 WebtoB Servlet Engine Application 에 사용 가능한 service 중의 하나이다. 이 각각의 service 들은 API를 통해서 복잡한 Web Application 을 쉽고 빠르게 개발할 수 있도록 해준다.

8 Servlet 의 구현

8.1 Servlet 시작하기

8.1.1 Servlet 의 Life cycle

web container 는 client 의 요청을 받아서 이를 servlet 에 넘겨 주고 다시 client 에게 응답을 돌려주는 역할을 한다. 이 container 와 servlet 간의 interface 는 Servlet API 에 의해 정해져 있다. 이 interface 에는 container가 호출하는 servlet 의 함수와 container 가 servlet 에 넘겨주는 object 들

의 class 가 정의되어 있다.

기본적으로 servlet 의 life cycle 은 다음과 같다.

Container 가 servlet 의 instance 를 생성

Container 가 servlet 의 init() 함수 호출

Container 가 어떤 servlet 에 대한 요청을 받으면 그 servlet instance 의 service() 함수 호출

Instance 를 메모리에서 지우기 전에 servlet 의 destroy() 함수 호출

Servlet 의 instance 가 소멸되고 garbage collection 이 됨


즉, service() 함수가 호출되기 전에는 항상 init() 함수가 실행이 된 이후이고 servlet instance 가 소멸되기 전에는 항상 destroy() 함수가 실행된다. 하지만 매번 request 가 들어올 때마다 servlet instance 를 생성하고 응답이 끝날 때마다 소멸시키지는 않는다. 대신 WebtoB Servlet Engine 에서는 처음 request 가 들어올 때에만 instance 를 생성하고는 이를 계속 caching 해 놓아서 매번 instance 를 생성, 소멸시키지는 않는다.

이때 service() 함수가 실행되고 있을 때 또 이 servlet 의 실행을 원하는 request 가 들어올 때에는 WebtoB Servlet Engine 에서는 새로운 thread 로 service() 함수를 실행한다. 이렇게 여러 개의 thread 로 하나의 instance 의 함수가 수행될 수 있으므로 개발할 때에는 code 가 thread 에

안전해야 하며(threadsafe) synchronized 같은 예약어를 사용하여 프로그래밍을 할 필요가 있다. 또한 실제로 WebtoB Servlet Engine 에서는 매번 service()함수가 실행될 때마다 할당되는 thread 를 thread pooling 으로 관리한다. 즉, 미리 thread 들을 만들어 두었다가 thread 가 필요할 때 하나씩 동적으로 할당에서 사용하는 것이다. 이런 과정을 그림으로 나타내면 다음과 같다.

그림 8-1 servlet 의 life cycle 화면


8.1.2 Servlet API 의 구성

WebtoB Web Container 은 Java Servlet 2.3 PFD2 API 의 javax.servlet 과 javax.servlet.http package 를 지원한다. 이 package 에 대한 자료는 다음의 site 에서 찾아볼 수 있다.

http://java.sun.com/products/servlet/ servlet API는 위의 life cycle에 맞추어 설계되어 있는데, servlet의 기본을 이루고 있는 인터페이스와 클래스들을 살펴 보기로 하자.

8.1.2.1 Servlet 인터페이스

앞에서 설명한 servlet lifecycle 은 javax.servlet.Servlet 인터페이스에 정의되어 있다. 만약 servlet 을 만든다면 직접적으로나 간접적으로 항상 이 인터페이스를 구현해야 한다. 대부분의 경우에 javax.servlet.Gene-ricServlet 이나 javax.servlet.http.HttpServlet 클래스를 확장하는 형태로 이 인터페이스를 구현한다. 이 인터페이스에 선언되어 있는 함수는 다음과 같다.

init() method : servlet 이 생성될 때에 servlet Container 는 init() 메

소드를 호출한다. Container 는 이 함수에 ServletConfig 타입의 객체를 넘겨 주어서 WebtoB Servlet Engine 의 설정을 servlet 에 넘겨준다.

service() method : service() 메소드는 매번 이 servlet 에 대한 requesr 가 올 때마다 실행된다. 이 메소드는 servlet Container 로

부터 ServletRequest, ServletResponse 타입의 객체를 하나씩 넘겨 받아서 request 객체의 정보를 분석해서 컨텐트를 만들어 response 객체의 컨텐트를 만들어 준다.

destroy() method : servlet Container 가 servlet 을 메모리나 리소스 풀에서 제거할 때는 항상 이 메소드를 먼저 호출한다. 또한 service() 메소드가 실행되고 있는 중에는 절대 destroy() 메소드가 실행되지 않고 실행되는 service() 메소드가 없을 때에만 destroy() 메소드가 호출되고 servlet 이 제거되는 것이 인터페이스에서 보장된다.

getServletConfig() : servlet 이 초기화되는 중간에 servlet 은 Web Container 에 서 넘 겨 받 은 ServletConfig 객 체 를 저 장 한 다 . ServletConfig 객체를 가지고는 두가지를 액세스할 수 있는데, deployment descriptor 에 지 정 되 어 있 는 Init parameter 와 ServletContext 객체이다 . ServletContext 객체는 하나의 context 안에 포함된 servlet 끼리 공유하는 객체로 각 servlet 끼리의 정보 공유와 servlet Container 에 대한 정보를 알아내는데 쓰인다. getServiceConfig() 함수는 언제든 servlet 에 저장된 ServletConfig 객체를 반환해서 이 객체를 액세스할 수 있게 해 준다.


getServletInfo() : 이 메소드는 servlet 의 제작자나 설명 등의 정보를 String 객체로 넘겨 준다. 이 메소드는 주로 servlet Container 에 의해 사용된다.

8.1.2.2 GenericServlet 클래스

GenericServlet 클래스는 Servlet 인터페이스를 구현한 기본적인 클래스이다. 이 클래스는 service() 메소드가 abstract 로 선언되어 있어서 abstract 클래스가 되며 이 클래스를 확장하는 클래스에서는 꼭 service() 메소드를 구현하여야 한다. 다른 메소드의 기본적인 기능은 구현이 되어 있다.

이 클래스의 init(ServletConfig conf) 메소드는 servlet Container 로부터 받은 ServletConfig 객체를 config 라는 맴버 변수에 저장하도록 구현되어 있다. 따라서 이 함수를 함부로 재정의해서 사용한다면 getServletConfig() 메소드를 사용해서 ServletConfig 객체를 사용할 수 없게 될 수도 있다. 이를 위해 이 클래스를 확장하고 이 메소드를 재정의할 때에는 super.config(conf) 를 추가시켜 주어야 한다.

또는 이 메소드를 재정의하지 않고 init() 이라는 메소드를 정의하면 된다. GenericServlet 클래스의 init(ServletConfig conf) 메소드에서는 수행을 마치기 전에 init() 이라는 매소드를 호출해 주는데, 이때 원하는 기능 수행을 할 수 있도록 init() 메소드를 작성하면 된다.

또한 이 클래스는 ServletConfig 인터페이스를 구현하고 있어서 개발자

가 ServletConfig 객체를 직접 액세스하지 않아도 getIniParameter(), getInitParameterNames(), getServletContext() 메소드를 호출할 수 있게 되

었다.

또한 ServletContext 객체의 log 메소드를 대신 호출해 주는 log 메소드를 가지고 있다.

8.1.2.3 HttpServlet 클래스

HttpServlet 클래스는 GenericServlet 클래스를 확장하고 HTTP 프로토콜에 적합하도록 만들어졌다. 대부분의 개발자들은 이 클래스를 확장해서 사용하게 될 것이다. 이 클래스에서 정의된 메소드는 다음과 같다.


service() 메소드 : service() 메소드는 HttpServlet 에서는 HTTP 요청의 종류에 따라 이 요청을 처리하는 메소드로 요청을 보낸다. 따라서 이 함수는 절대 재정의되어서는 안된다. 대표적인 요청 처리 함수로는 doGet() (HTTP 의 GET request 처리), doPost() (HTTP 의 POST request 처리) 메소드가 있다. 따라서 각각의 요청을 처리하는 함수를 정의해서 응답을 만들어 보내면 되는 것이다.

getLastModified() : 이 메소드는 servlet 이 가장 최근에 변경된 시간을 long 타입으로 돌려준다.

8.1.2.4 HttpServletRequest 인터페이스

HTTP request 객체처럼 HttpServletRequest 인터페이스를 구현한 객체는 servlet 이 객체 내의 메소드를 통해 요청 정보를 액세스할 수 있게 해준다. HTTP 문서의 form 정보를 가져오는 기본적인 메소드들은 다음과 같다.

getParameter() : 요청에 들어온 query string 의 이름을 넘겨주면 그 query 의 값을 String 으로 돌려 준다. 만약 여러 값이 하나의 이름에 할당되어 있다면 처음 값을 돌려준다.

getParameterValues() : 만약 넘겨준 query 이름의 parameter 가 여러 개의 값을 가지고 있다면 그 값을 String[] 객체로 돌려준

다.

getParameterNames() : 이 메소드는 요청에 들어온 parameter 들

의 이름을 Enumeration 객체로 넘겨준다.

8.1.2.5 HttpServletResponse 인터페이스

Web Container 는 이 인터페이스를 구현한 객체를 servlet 에 넘겨 준다. servlet 에서는 이 객체를 통해 응답 헤더를 수정할 수 있고, 응답 결과를 이 객체를 통해 브라우저로 보낼 수 있다. 이 객체의 기본적인 메소드는 다음과 같다.

setContentType() : 브라우저로 응답을 보내기 전에 응답의 MIME type 을 설정하기 위해서는 이 메소드를 호출해야 한다. 인자로는 유효한 MIME type 이 들어갈 수 있다.

getWriter() : 이 메소드는 PrintWriter 객체를 넘겨 줘서 servlet 의 실행 결과를 응답에 기록하는데 사용할 수 있도록 한다. 이 객체는 Java 에서 내부적으로 사용하는 UniCode 문자들을 자동으로 바꾸어서 브라우저에서 읽을 수 있도록 해 준다. 실제로 기록할 때에는 이 객체의 print() 메소드들을 사용한다.


getOutputStream() : 이 메소드는 javax.io.OutputStream 클래스의 subclass 인 ServletOutputStream 객체를 넘겨준다. 이 객체는 client 에 이진 데이터(binery data)를 보낼 때 사용한다.

Note : HttpServletResponse 로부터는 output 객체를 하나만 가져올 수 있다. 만약 이미 객체를 가져 왔는데 다시 이들 함수를 사용해서 가져오려고 하면 IllegalStateException 이라는 예외상황이 발생할 것이다.

setHeader() : 이 메소드는 client 에 보낼 응답의 헤더를 설정할 수 있도록 해 준다.

8.1.3 간단한 servlet 작성


8.1.3.1 Sample servlet code 작성

여기서는 지금까지 살펴본 servlet 의 API 들을 이용해서 간단한 servlet 프로그램을 작성해 보기로 하겠다. 먼저 작성할 프로그램의 전체 코드는 다음과 같다.

import javax.servlet.*;

import javax.servlet.http.*;

import java.io.*;

public class HelloWorldServlet extends HttpServlet

{

public void doGet(HttpServletRequest req,

HttpServletResponse res) throws IOException, ServletException

{

// 먼저 Content Type 설정

res.setContentType("text/html");

//HTML 을 넣은 PrintWriter Object 를 얻는다

PrintWriter out = res.getWriter();

out.println(“<HTML>”);

out.println(“<HEAD>”);

out.println(“<TITLE>Hello World Sample</TITLE>”);

out.println(“</HEAD>”);

out.println(“<BODY>”);

out.println(“<CENTER><H1>Hello World!</H1></CENTER>”);

out.println(“</BODY>”);

out.println(“</HTML>”);

out.close();

}

}

이 코드의 각 부분들을 살펴보면 다음과 같다.

먼저, HTTP Servlet 을 작성하기 위해서 아래의 패키지를 import 한다.



import java.io.*;

HTTPServlet class로부터 상속받는다.

class SampleServlet extends HTTPServlet {

........

}

servlet 이 수행될 때, 데이터를 초기화 시키거나 입력을 받을 필요가 있을 경우, init() 함수를 overide 한다. - 이 예제에서는 초기화할 필요가 없어서 구현하지 않았다. 이럴 경우의 code 는 다음과 같은 형태를 가진다.

public void init(ServletConfig config)

throws SerlvetException {

super.init(config);

.....

}

doGet() 메소드를 이용해서 요청을 처리한다. – HTTP 요청이 들어오면 service() 메소드에서 이를 받아서 요청의 종류에 따라 각각의 메소드를 호출해 준다. 여기서는 GET 요청을 받아 처리하는 함수인 doGet() 메소드를 구현해 두었다.


HttpServletResponse res) throws IOException, ServletException

{

…

}


브라우저로 출력하기 위한 출력 스트림 객체를 연다. – 브라우저로 출력하기 위한 PrintWriter 객체는 response 객체를 이용해서 얻어낼 수 있다. 이 예제에서는 먼저 컨텐트 타입을 text/html 로 설정하였다. 그리고 response 객체의 getWriter() 메소드를 이용하여 PrintWriter 객체를 가져왔다. 이 코드들은 다음과 같다.

res.setContentType("text/html");

PrintWriter out = res.getWriter();

만들어낸 응답을 보낸다. – 앞에서 얻는 out 객체의 println() 메소드를 이용하여 우리가 보내고자 하는 HTML 문서를 출력하였다. 그리고 출력이 끝난 뒤에는 close() 메소드로 out 객체를 닫으면 응답이 보내진다.

out.println(“<HTML>”);

out.println(“<HEAD>”);

out.println(“<TITLE>Hello World Sample</TITLE>”);

out.println(“</HEAD>”);

out.println(“<BODY>”);

out.println(“<CENTER><H1>Hello World!</H1></CENTER>”);

out.println(“</BODY>”);

out.println(“</HTML>”);

out.close();

8.1.3.2 Servlet 코드 컴파일

Servlet 코드는 다른 java 프로그램과 마찬가지로 javac 로 컴파일한다. 이때 신경쓸 일은 servlet 코드에 사용된 패키지들의 경로를 javac 의 –classpath 옵션으로 지정해 주어야 한다는 것이다. 이 servlet 코드는 J2EE 의 API 들만 사용하고 개발자가 개별적으로 만든 class 파일들은 사용하지 않았으므로 classpath 에 jeus 디렉토리 내의 classes 디렉토리만 지정해 주면 된다. 즉,

Javac –classpath (WebtoB Servlet Engine 의 classes 디렉토리 경로)

HelloWorldServlet.java

위의 명령을 이용해 컴파일을 한다. 만약 WebtoB Servlet Engine 가 D 드라이브의 Jeus 라는 디렉토리에 설치되어 있다면 WebtoB Servlet Engine 의 classes 디렉토리 경로는 D:/Jeus/classes/ 가 된다.


8.1.3.3 Servlet 클래스 등록

이렇게 생성된 servlet 클래스 파일을 WebtoB Servlet Engine 에서 실행시키기 위해서는 이 servlet 을 WebtoB Servlet Engine 에 등록해야 한다. 이렇게 등록하는 것은 WebtoB Servlet Engine 의 servlet Container 를 설정하는 것에 포함되며 이 과정에 대한 상세한 설명은

7 장 Web Application 의 개발의 배치 설명자의 작성 항목에서 자세히 다루고 있다.

여기서는 간단히 servlet 을 실행시키기 위해 현재 존재하는 컨텍스트의 설정에 이 HelloWorldServlet servlet 을 추가해 보기로 하겠다. 즉, 다음과 같은 단계를 거쳐서 servlet 을 등록한다.

WebtoB Servlet Engine 를 설 치 한 디 렉 토 리 의 /webhome/servlet_home/webapps/examples/WEB-INF/classes 디렉토

리에 이 servlet 의 class 파일을 넣어 둔다. 우리는 examples 컨

텍스트에 이 HelloWorldServlet 을 추가할 것이다.


바로 상위 디렉토리인 WEB-INF 의 web.xml 을 열어서 다음과 같은 내용을 추가한다. 아래 코드 중에 굵은 글씨로 된 부분이 추가한 부분이다.

<web-app>

<servlet>


<servlet-class>ServletContextTest</servlet-class>

<init-param>

<param-name>color</param-name>

<param-value>blue</param-value>

</init-param>

<init-param>

<param-name>age</param-name>

<param-value>20</param-value>

</init-param>

<load-on-startup>-1</load-on-startup>

</servlet>

<servlet>

<servlet-name>HelloWorld</servlet-name>

<servlet-class>HelloWorldServlet</servlet-class>

</servlet>

<servlet>

<servlet-name>RequestHeaderTest</servlet-name>

<servlet-class>RequestHeaderTest</servlet-class>

<load-on-startup>-1</load-on-startup>

</servlet> ……

이 web.xml 을 저장하고 WebtoB Servlet Engine 를 실행시킨다. WebtoB Servlet Engine 를 실행하는 방법은 1 장 WebtoB Web Container 시작하기에서 다루고 있다.

8.1.3.4 Servlet 실행

위의 과정을 거치면 HelloWorld servlet 이 examples 컨텍스트에 등록이 된다. 이 servlet 을 실행시키려면 다음과 같은 URL 을 브라우저에서 요청한다.

http://hostname_url:port/exmples/HelloWorld

이때 hostname_url 에는 WebtoB Servlet Engine 가 실행되고 있는 node 의 DNS 를 입력한다.

8.2 Servlet 의 요구 경로(Request Path)

Client 에서 servlet 을 요구하는 Request Path 는 여러 중요한 부분들로 이루어져 있다. 요구경로는 아래의 요소들로 이루어져 있으며, 이들은 Request Object 들로부터 얻을 수 있다.

Context Path : ServletContext 와 관련된 path prefix 이다. URL 경로에 이 context path 가 포함되어 있다면, 웹 서버는 이 경로로 시작하는 모든 요청은 이 ServletContext 의 인스턴스를 가지고 있는 Web Application 으로 넘겨준다. 여기서 Web Application 이 의미하는 것은 servlet 이 돌아가는 런타임 환경으로 이해해도 무방하다.(실제 환경을 제공하는 것은 Web Container 이지만, Web Application 에 포함된 servlet 관점에서 본다면 ServletContext Object 의 인스턴스를 가지고 있는 Web Application 이 전부이기 때문이다.) 또한, 같은 servlet 일지라도 다른 Web Application 에 포함되어 있다면, 전혀 다른 환경에서 그들은 수행되기 때문이다. 이 환경이 다르다는 의미는 SelvetContext 가 다르다는 의미이다.

Servlet Path : web.xml 에 포함된 servlet 정의에서 servlet 에 매

핑 된 URL 패턴


PathInfo : Context Path 나 Servlet Path 에도 포함되지 않은 Path 위의 Rule 에 따라서 URL 을 기술하면 Request URI = Context Path + Servlet Path + PathInfo 로 나타낼 수 있다. web.xml 에서의

Context 구성이 다음 표와 같다고 가정할 때 URL 의 요구 경로

는 아래쪽 표와 같다.

Context Path /catalog

Servlet Mapping url-pattern : /lawn

servlet-name : LawnServlet

Servlet Mapping url-pattern : /garden

servlet-name : GardenServlet

Servlet Mapping url-pattern : /*.jsp

servlet-name : JspServlet


Request Path Path Element

/catalog/lawn/index.html

context path : /catalog

servlet path : /lawn

pathinfo : index.html

/catalog/garden/implement/


servlet path : /garden

pathinfo :/implement

/catalog/help/feedback.jsp


servlet path : /help/feedback.jsp

pathinfo : null

8.3 Servlet 의 session tracking

HTTP 는 stateless 프로토콜이다. 이 의미는 하나의 요청이 들어오면 하나의 응답을 하는, 간단한 작업을 하는 프로토콜이란 뜻이다. 하지만 이로 인해 서버는 같은 client 에서 오는 요청들을 전혀 별개로 처리함으로서 사용자의 정보를 각 request 들을 넘나들며 지닐 수 없게 된다.

이러한 HTTP 프로토콜 위에서 각 요청들 사이에서 어떤 상태를 유지하는 것을 세션 추적(session tracking)이라고 한다. 이는 기본적으로 하나의 요청에 의해 생긴 정보를 그 요청 후에 오는 일련의 요청들에서 사용할 수 있도록 해 주는 것이다. 이러한 방법에는 여러 가지 종류가 있다. 이 방법을 나열해 보면 다음과 같다.

Data 를 지닌 감춰진 폼 필드(Hidden form field)를 생성

추가적인 parameter 들을 포함하게 URL 을 다시 쓰기(rewriting)

cookie 를 사용

servlet API 에 있는 session tracking tool 을 사용

servlet API 에서 제공하는 메소드를 이용하면 어느 servlet 이든 액세스할 수 있는 session 객체를 사용할 수 있다. 여기서는 servlet 에서 cookie 를 사용하는 방법과 session 객체를 이용하는 것에 대해 설명하기로 한다.


8.3.1 Cookie 의 사용

쿠키란 일반적으로 세션관리를 위해 브라우저에 의해 관리되는 일련의 데이터 쌍의 이름들이다. HTTP 연결은 비 상태유지 방식이기 때문에 여러 HTTP 연결에 대해 지속적인 정보를 유지하기 위해서 쿠키를 사용한다. 이러한 모든 것들은 Cookie 클래스에서 발생한다.

먼저 쿠키를 저장하기 위해서는 쿠키를 생성하고 HttpServletResponse Response의 내용의 타입을 설정하고, 쿠키를 Response에 추가하고, 이것을 출력으로 내보내는 과정이 필요하다.

쿠키가 HTTP 응답 헤더의 부분으로 되돌아 오기 때문에 출력을 보내기 전에 컨텐트 타입(content type)을 설정해야만 한다. 이런 작업을 하는 코드는 다음과 같다.


private static final String SUM_KEY = "sum";

...

int sum = ...; // get old value and add to it

Cookie theCookie = new Cookie (SUM_KEY, Integer.toString(sum));

response.setContentType("text/html");

response.addCookie(theCookie);

여기에서 쿠키의 자료는 모두 문자열의 형태로 저장된다. 특히 int 형 같은 자료형의 정보의 경우 string 객체로 변환한 뒤에 사용되어져야 한다는 의미이다. 쿠키는 기본적으로 브라우저 세션이 살아있는 동안 보존되는데, 이러한 쿠키를 계속 지속시키기 위해서는 setMaxAge(interval) 메소드를 호출해야 한다. 양수 값의 경우 쿠키가 존재 가능한 시간을 초단위로 설정이 가능하고, 음의 값의 경우에는 기본적으로 설정 된 값이 되며 브라우저가 종료 시에 같이 소멸되도록 한다. 0 의 값을 갖는 경우는 즉시 삭제가 된다.

쿠키의 값을 얻는 방법은 어떤 특정한 키 값으로 검색을 하는 것이 아니라 모든 쿠키들을 호출하고 그 중에서 특별히 원하는 값을 찾는 것이다. 또한 하나 이상의 쿠키가 동일한 이름을 가지는 것이 허용되기 때문에 처음 찾은 쿠키의 값만으로 만족하는 경우 틀린 값을 찾게 되는 경우가 발생할 수도 있다. 다음의 코드는 하나의 값을 가지는 쿠키를 설정하는 예이다.

int sum = 0;

Cookie theCookie = null;

Cookie cookies[] = request.getCookies();

if (cookies != null)

{

for(int i=0, n=cookies.length; i < n; i++)

{

theCookie = cookies[i];

if (theCookie.getName().equals(SUM_KEY))

{

try {

sum =

Integer.parseInt(theCookie.getValue());

}

catch (NumberFormatException ignored) {

sum = 0;

}

break;

}

} /* end for */

} /* end if */

8.3.2 HttpSession 객체를 사용한 세션 추적

HttpSession 객체는 현재의 servlet context 내에서 세션 데이터를 저장하고 있는 객체이다. 이 객체를 이용해서 세션을 관리할 때에도 cookie 가 사용되는데, 이때 cookie 는 session ID 를 저장해서 이 ID 값을 이용해 여러 HttpSession 객체 중 현재 사용자의 session 을 찾기 위해 쓰인다. 만약 cookie 를 지원하지 않는 client 에 대해서는 URL 에 session ID 를 포함시키는 작업을 수행하는 URL 다시쓰기(rewriting)를 해서 session 객체를 찾을 수 있게 한다.

HttpSession 객체는 HttpSession 인터페이스에 정의되어 있으며 HttpServletRequest 객체의 getSession() 메소드를 사용해 얻을 수 있다. 일단 session 객체가 생성되면 여기에 데이터를 저장할 수도 있고 다시 불러낼 수도 있다. 또한 원한다면 session 객체를 제거할 수도 있고 그냥 둔다면 사용자가 요청을 보낸 가장 최근의 시간으로부터 지정된 session expire time 이 지나면 자동으로 session 객체는 소멸된다.


8.3.2.1 Session 객체 사용하기

Session 객체를 얻은 후에는 이 객체에 Object 타입의 객체를 key 값이 되는 객체 이름과 함께 저장할 수 있다. 이때 primitive 타입의 값은 Integer, Long 같은 wrapper class 를 사용해서 Object 타입으로 바꾸어 넣을 수 있다. HttpSession 객체에는 하나의 이름에 해당하는 객체는 오직 하나만 정해진다. 먼저 session 객체에 데이터를 저장하는 예는 다음과 같다.

HttpSession session = request.getSession(true);

Integer sessionItem = new Integer(2001);

session.setAttribute(“mySessionItem”, sessionItem);

이때 getSession() 메소드의 인자로 들어가는 true 는 session 객체가 request 에 없으면 새로 생성하라는 뜻이다. false 를 주었을 때 session 객체가 request 에 없으면 null 을 돌려 준다. Session 객체의 값을 읽어들이는 예는 다음과 같다.

HttpSession session = request.getSession(true);

Integer sessionItem = (Integer) session.getAttribute

(“mySessionItem”);

Int counter = sessionItem.intValue();

만약 주어진 이름의 객체가 session 에 존재하지 않으면 getValue() 메소드는 null 을 돌려준다.

8.4 동적 컨텐트 생성

자바 servlet 은 HTML 문서 같은 text 만 브라우저에게 보낼 수 있는 것은 아니다. 다른 많은 종류의 데이터들이 servlet 에 의해 동적으로 생성되어 보내어질 수 있는데, 이 중 하나는 그림(image)들이다.

8.4.1 MIME 타입

Servlet 에서 보낼 수 있는 데이터의 포맷 (format)은 MIME content type(Multipurpose Internet Mail Extensions)에 분류되어 있다. 이 타입은 type/subtype 의 형태로 되어 있는데, Image 타입에 관한 MIME 타입은 다음과 같은 것들이 있다.

Image/jpeg

Image/gif

Image/png

HTTP 데이터의 컨텐트 타입은 응답 해더의 Content-Type 항목에 지정되어 있다. Client 에서는 자신이 받아들일 수 있는 컨텐트 타입을 요청 헤더의 Accept 항목에 지정해 줄 수 있다.

여기서는 간단히 GIF format 의 그림을 하나 만들어서 client 에 보내는 예제를 만들어 보겠다. 실제로 제대로 보내려면 요청 해더의 Accept 를 확인해 보아야 한다.


8.4.2 이진 데이터(Binery data)를 보내기

servlet 에서 text 를 보낼 때에는 ServletResponse.getWriter() 메소드를 사용해서 PrintWriter 객체를 얻어서 사용했다. 이진 데이터를 보낼 때에는 getWriter() 메소드 대신 getOutputStream() 메소드를 사용해서 OutputStream 객체를얻는다. 이 객체를 사용하면 바로 client 로 이진 데이터를 보낼 수 있게 된다.

8.4.3 GIF 이미지 만들기

Server 에서 이미지를 만들기 위해서는 AWT(Abstract Windowing Toolkit) API 를 사용한다. 이때 servlet 은 server 에 windows 를 실제로 띄우진 않는다. 대신 Application 에서 더블 버퍼링할 때 사용하는 off-screen 이미지를 생성한다. 즉, 메모리 상에 이미지가 들어갈 공간을 확보하고 여기에 그림을 그리는 것이다.

8.4.4 Off-screen 이미지 만들기

Java 에서 이미지를 나타내는 클래스는 java.awt.Image 이다. 하지만 이미지를 그릴 때 AWT 를 사용하기 위해서는 Frame 객체를 통해 이미지 객체를 생성해야 한다. 이를 위해 먼저 Frame 객체를 생성한 후에 addNotify() 함수를 이용해서 현재 platform 의 AWT toolkit 에 연결한 후에 createImage() 함수를 이용해 이미지 객체를 생성한다. 이를 수행하는 코드는 다음과 같다.

int width = 100, height = 100;

Frame dummy = new Frame();

Dummy.addNotify();

Image img = dummy.createImage(width, height);

이때 이 Frame 은 화면에는 나타나지 않는다. 그리고 이 이후로는 AWT 의 함수들을 이용해서 그림을 그릴 수 있다.

Note : 이때 AWT 를 사용하는 것은 host 의 그래픽 시스템에 대한 접근을 필요로 한다. 유닉스 시스템의 경우에는 그래픽 시스템이 대부분 X11 server 가 되는데, 이 server 는 일반적인 server setup 에서는 이용할 수 있지 않는 것이다. 그래서 servlet Container 가 X11 server 에 접근할 수 있도록 해 줄 필요가 있다. 예를 들면 X11 server 를 지원하는 X manager 터미널 상에서 WebtoB Servlet Engine 를 실행시키는 경우가 그것이다. 만약 윈도우 환경에서 WebtoB Servlet Engine 를 사용할 때에는 이를 신경쓸 필요가 없다.


8.4.5 이미지 인코딩(Encoding)

이미지 객체가 생성되고 그림을 그리고 나면 이를 브라우저로 보내야 한다. 따라서 브라우저에서 이미지를 인식할 수 있는 이미지 포맷으로 인코딩해서 보내야 할 것이다. 이미지 인코딩은 Java 1.3 core API 에는 포함되어 있지 않지만 인터넷 상에서 공짜 인코더들을 구할 수 있다. 여기서는 ACME Java utilities 에 포함된 GIF 인코더를 사용할 것이다. 이를 이용한 코드는 다음과 같다.

Image img = …;

FileOUtputStream out = new FileOutputStream(“image.gif”);

New FigEndoder(img, out, true).encode();


8.4.6 “Hello World” 이미지 생성하기

지금까지 다룬 것들을 바탕으로 간단한 이미지를 생성해 보기로 하겠다. 다음의 예제는 “Hello World”를 표시하는 servlet 이다.

import java.io.*;

import java.awt.*;



import Acme.JPM.Encoders.GifEncoder;

public class HelloWorldGraphics extends HttpServlet

{


HttpServletResponse res)

throws ServletException,IOException

{

ServletOutputStream out=res.getOutputStream();

Frame frame=null;

Graphics g=null;

try{

frame = new Frame();

frame.addNotify();

Image image = frame.createImage(400,60);

g = image.getGraphics();

g.setFont(new Font("Serif",Font.ITALIC,48));

g.drawString("Hello World!",10,50);

res.setContentType("image/gif");

GifEncoder encoder =

new GifEncoder(image,out);

encoder.encode();

}

catch(Exception e){}

finally{

if(g!=null) g.dispose();

if(frame!=null) frame.removeNotify();

}

}

}

이 예제의 결과는 다음과 같다.

그림 8-2 Hello World! 이미지 화면

8.5 Connection Pooling 의 사용

DB connection pooling 은 Container 내의 Application 에서 DB 와 연결을 맺고 끊을 때의 부하가 크기 때문에 미리 Container 에서 DB connection 들을 여러 개 가지고 pool 에 보관해 두었다가 Application 에서 해당 pool 에 DB connection 을 요청하면 이 connection 들을 사용하게 해 주

고 Application 에서 다 사용한 connection 은 다시 pool 에 넣어 두어 나

중에 사용에 쓰일 수 있도록 하는 기법이다. 이렇게 하면 매번 DB 와 연결을 맺지 않아도 되므로 Application 의 성능이 향상된다.

Web Container 에서 실행되고 있는 Application 가 사용할 수 있는 WebtoB Servlet Engine 의 DB connection pool 은 2 가지가 있다. 하나는 WebtoB Servlet Engine 서버에서 제공하는 naming server 기능을 이용한 방법이고, 다른 하나는 servlet Container 에서 제공하는 DB 연결 풀링이다. 이중 첫번째 것은 WebtoB Servlet Engine 서버의 설정 파일인 JeusMain.xml 에서 설정을 하며 JNDI specification 에 따라 사용할 수


있다. 두번째 것은 container.xml 에서 설정을 해서 servlet, JSP 에서만 사용할 수 있다. 여기서는 두번째 것을 어떻게 사용할 수 있는지를 알아보기로 하겠다. WebtoB Servlet Engine 서버에서 제공하는 DB pooling 을 사용하려면 DB connection pooling 매뉴얼을 살펴 보길 바란

다.

Web Container 에서 제공하는 DB connection pooling 을 사용하기 위한 방법은 2 가지가 있다. 이 방법들을 알아보자.

DriverManager 를 이용하는 방법 : 이는 DB connection pooling 을 쓰지 않을 때 connection 을 얻는 방법과 거의 비슷하다. 이 방법의 예를 보면 다음과 같다.

Class.forName("jeus.jdbc.pool.Driver");

Connection con =

DriverManager.getConnection ("jdbc:jeus:pool:oraclePool", null);

위의 예제에서 마지막의 oraclePool 이 container.xml 에서 설정한 <DBConnectionPool> 태그의 ConnectionPoolID 속성의 값에 해당한다. 위의 예제의 null 부분에는 Properties 객체를 사용하여 DB pool 에 관련된 property 들을 넘겨 줄 수가 있다. 이때 이 property 에는 다음과 같은 것들이 올 수 있다.

jeus.jdbc.pool.ConnectionPoolID : getConnection() 메소드의 첫

번째 인자에서 ConnectionPoolID 를 지정하지 않을 경우에 두번째 인자에 ConnectionPoolID 를 property 형태로 넘길 수 있다. 이렇게 하는 예는 다음과 같다.

Properties prop = new Properties();

prop.put("jeus.jdbc.pool.ConnectionPoolID", "oraclePool");

Connection con

= DriverManager.getConnection ("jdbc:jeus:pool", prop);

jeus.jdbc.pool.ConnectionTimeOut : 이는 container.xml 에서 설정한 ConnectionTimeOutSecs 속성의 값과 같은 역할을 하

는 값이다. 이는 container.xml 에서 지정해 둔 값과 다른 값

을 사용할 때 유용하다.


Note : ConnectionPoolID 나 ConnectionTimeOut 속성의 의미가 무

엇인지 알려면 5 장 container.xml Reference 에서 DB 연결 풀링 항목을 살펴 보길 바란다.

Driver 를 바로 사용하는 방법 : 이는 DriverManaer 객체 대신에 Driver 객체를 이용해서 connection 을 얻는 방법이다. 이 방법의 예를 보면 다음과 같다.

Driver myDriver

= (Driver)Class.forName("jeus.jdbc.pool.Driver").newInstance();

Connection conn = myDriver.connect("jdbc:jeus:pool:oraclePool",

null);

위의 예제에서 connect() 메소드를 사용할 때의 parameter 들의 의미와 null 의 위치에 올 수 있는 것들은 DriverManager 객체를 사용할 때의 것과 같다.

8.6 Servlet 에서의 쓰레드(Thread)

만약 WebtoB Servlet Engine server 에 많은 요청이 몰려서 하나의 servlet 에 여러 요청이 들어올 때가 생기면 이 servlet 의 인스턴스의 service() 함수가 여러 쓰레드 상에서 동시에 동작할 때가 생긴다. 이때에는 servlet 을 설계할 때 다중 쓰레드가 공유할 수 있는 맴버 변수나 DB connection 같은 리소스 관리를 신경써서 해야 한다.

만약 이러한 처리를 하기가 힘들다면 하나의 servlet 인스턴스는 항상 하나의 쓰레드로 수행되도록 할 수 있다. 이렇게 하기 위해서는 해당 servlet 이 SingleThreadModel 인터페이스를 구현하도록(implements) 해두면 된다. 이때는 동시에 들어오는 여러 요청에 따라 여러 개의 인스턴스를 만들어서 각각의 요청을 처리한다.

SingleThreadModel 인터페이스를 구현하도록 servlet 을 만들었다고 하더라도 이 인스턴스들이 하나의 공유된 리소스를 사용할 수도 있으므로 여전히 synchronization 의 문제가 생길 수 있다.

WebtoB Servlet Engine 에서는 이러한 문제들을 각각의 servlet 을 중심으로 다루어지는걸 추천한다. 이를 위한 여러 가지 가이드 라인을 제시하면 다음과 같다.

가능하다면, WebtoB Servlet Engine 의 성능을 저하시킬 수 있는 synchronization 의 사용은 피하는 것이 좋다.


각각의 servlet 에서 사용하는 변수들은 service() 메소드 안에서 정의되는게 좋다. 이러한 지역 변수들은 stack 에 쌓여서 인스턴스들 간에 공유가 되지 않아서 synchronization 을 필요로 하지 않는다.

외부 리소스를 액세스하는 것은 class 레벨에서 synchronization 이 되거나 트랜젝션(transaction)으로 감싸 주어야 한다.

8.7 다른 servlet 으로 요청 전달

servlet API 에서는 ServletContext 인터페이스에서 getService() 메소드를 사용해서 다른 servlet 에 접근하는 것을 사용하지 않는 추세이다. 대신 RequestDispatcher 인터페이스를 사용해서 다른 servlet 과의 통신을 할 수 있도록 한다. 이는 현재의 request 객체를 다른 servlet 으로 넘겨서 이를 처리할 수 있도록 하는 것인데, servlet 뿐만 아니라 어떤 서버 리소스에도 request 을 넘길 수 있고 다른 servlet 의 결과가 현재의 output 에 포함될 수도 있다.

ReqeustDispatcher 객 체 를 얻 기 위 해 서 는 ServletContext 객 체 에 서 getRequestDispatcher() 메 소 드 를 호 출 해 야 한 다 . 이 를 위 해 먼 저 ServletConfig 인 터 페 이 스 의 getServletContext() 메 소 드 를 이 용 해 서 ServletContext 객체를 얻어야 한다. HttpServlet 클래스는 ServletConfig 인터페이스를 구현하고 있으므로 이를 위한 코드는 다음과 같다.

RequestDispatcher rd =

getServletContext().getRequestDispatcher(

“/servlet/some_resource” );

위의 예에서 /servlet/some_resource 는 context path 를 제외한 나머지 URI 이다. RequestDispatcher 객체를 얻은 후에는 forward() 메소드를 이용해서 요청을 넘겨줄 수 있거나 include() 메소드를 사용해서 다른 servlet 의 컨텐트를 현재의 output 에 끼워 넣을 수 있다.


8.8 필터(Filter)

필터는 Java Servlet Specification 2.3 에 새롭게 도입된 개념이다. 필터는 클라이언트 HTTP request 를 처리하기 전 또는 클라이언트로 보낼 HTTP response 를 보내기 직전에 그 내용을 수정(필터링)할 수 있게 하는 클래스(정확히 말하면 인터페이스)이다.

개발자는 javax.servlet.Filter 인터페이스를 구현하고 web.xml 에 <filter> 태그와 <filter-mapping> 태그로 등록하면 이러한 기능을 사용할 수 있다.

HTTP request 및 HTTP response 를 수정할 수 있도록하기 위해서 ServletRequestWrapper, HttpServletRequestWrapper, ServletResponseWrapper, HttpServletResponseWrapper 라는 클래스가 새롭게 추가되었다.

구현된 필터 클래스는 아래와 같이 web.xml 에 등록된다. <filter> 태그는 <servlet> 태그와 유사하다. 필터이름과 실제 필터 클래스의 전체 이름을 설정한다. <filter-mapping>은 <servlet-mapping>과 유사하다. 언제 이 필터가 호출되어 동작할 지를 결정한다. 매핑될 대상은 서블릿 이름이거나 URL 패턴이 될 수가 있다.

<filter>

<filter-name>Image Filter</filter-name>

<filter-class>com.acme.ImageServlet</filter-class>

</filter>

<filter-mapping>

<filter-name>Image Filter</filter-name>

<servlet-name>ImageServlet</servlet-name>

</filter-mapping>

<filter-mapping>

<filter-name>Logging Filter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<filter-mapping> 따라서는 한번의 클라이언트 요청에 여러 개의 필터 클래스가 맵핑될 수 있다. 이러한 일련의 필터 클래스들을 filter chain 이라고 한다. filter chain 은 Web Container 에 의해 FilterChain 이라는 클래스로 나타낼 수 있으며 Filter.doFilter 메쏘드를 호출할 때 인자로 넘겨진다.

개발자가 구현할 Filter 인터페이스는 다음과 같은 세가지 함수를 가지고 있다.

void init(FilterConfig config) : 개발자가 작성한 필터 클래스가 최초로 실행되기 전에 한번 호출되는 함수이다. Config 에는 web.xml 의 <filter> 태그에 설정한 파라메터등이 담겨져 있다.

void destroy() : 필터가 더 이상 기능을 하지 않는 시점에 한번 호출된다.


void doFilter(ServletRequest, ServletResponse, FilterChain) : 실제 필터의 기능이 구현될 함수이다 .

FilterChain 에는 현재의 요청에 적용할 Filter 들의 목록을 가지

고 있는 클래스이다 . Web Container 는 FilterChain 에 있는 Filter 의 목록에 따라 순서대로 doFilter 함수를 호출한다. doFilter 를 구현하는 방법에 따라서 FilterChain 에 있는 목록을 더 이상 진행하지 않고 중도에 마칠 수도 있다.

8.8.1 필터 생존 주기(Filter LifeCycle)

Web Container 가 HTTP request 를 받았을 때 이 request 에 적용할 필터 목록이 있다면 목록의 첫 번째 필터의 doFilter 함수를 호출하게 된다. doFilter 함수가 어떻게 구현되어 있느냐에 따라서, 일련의 필터 작업이 계속 진행할 수 있거나 중도에서 멈출 수도 있다. doFilter 함수는 다음과 같은 절차를 수행하도록 작성한다.

Step1 : request header 의 정보를 참조할 수 있다.

Step2 : HttpServletRequestWrapper 를 상속받은 request wrapper 클래스로 클라이언트로부터 받은 request 를 wrapping 하여 request 의 내용을 수정할 수 있다.

Step3 : HttpServletResponseWrapper 를 상 속 받 은 response wrapper 클래스로 클라이언트 요청을 처리한 결과인 response 객

체를 wrapping 하여 클라이언트로 응답할 response 의 내용을 수

정할 수 있다.

Step4 : 필터 목록에 있는 다음 필터를 수행할 것인지를 결정할 수 있다. 다음 필터의 doFilter 를 호출하려면 인자로 받은 FilterChain 객체의 doFilter 함수를 호출하면 된다. Web Container 가 내부적으로 다음 필터의 doFilter 함수를 호출해 준다. FilterChain 객체의 doFilter 함수를 호출할 때 step2, step3 에서 생성한 wrapper 클래스 객체를 인자로 넘겨줄 수 있다. FilterChain 의 doFilter 를 호출하지 않으면 여기에서 클라이언트 요청에 대한 모든 처리가 끝난다. 즉, 실제 클라이언트가 요청한 서비스는 실행되지 않는다. 따라서, FilterChain 의 doFilter 를 호출하지 않을 경우 클라이언트에 대한 응답을 자체적으로 처리해야 한다.


Step5 : FilterChain 의 doFilter 를 호출한 후 response header 를 참조할 수 있다.


8.8.2 간단한 필터 예제

간단한 필터 예제 프로그램을 작성해 보겠다.

아래에 보인 예제는 response 가 나가기 직전에 response 스트림의 끝에 hit count 정보를 삽입하는 필터이다.

package filters;

import java.io.*;



public final class HitCounterFilter implements Filter {

private FilterConfig filterConfig = null;

public void init(FilterConfig filterConfig)

throws ServletException {

// do something

}

public void destroy() {

// do something

}

public void doFilter(ServletRequest request,

ServletResponse response,

FilterChain chain) throws

IOException,

ServletException {

if (filterConfig == null)

return;

PrintWriter out = response.getWriter();

CharResponseWrapper wrapper = new

CharResponseWrapper((HttpServletResponse)response);

chain.doFilter(request, wrapper);

StringWriter sw = new StringWriter();

PrintWriter writer = new PrintWriter(sw);

Counter counter

=(Counter)filterConfig.getServletContext().

getAttribute("hitCounter");

int count = counter.incCounter();

CharArrayWriter caw = new CharArrayWriter();

int pos = wrapper.toString().indexOf("</body>");

if (pos > 0) {

caw.write(wrapper.toString().substring(0, pos-1));

caw.write("<hr><center><p>\nYou are visitor number

<font color='red'>" + count + "</font></center>");

caw.write("\n</body></html>");

response.setContentLength(caw.toString().length());

out.write(caw.toString());

} else {

}

out.close();

}

}

counter 라는 객체는 컨텍스트의 속성으로서 (어디선가 속성으로 등록하였다고 가정하자) 페이지 방문 횟수를 기억하는 일을 담당하는 객체이다.

CharResponseWrapper 객체는 HttpServletResponseWrapper 를 상속한 객체로서 getWriter 함수를 overriding 하여 요청에 대한 응답을 가로챌 수 있게 하고 있다. chain.doFilter 를 호출하기 전에 인자로서 CharResponseWrapper 를 넘기기 때문에 그 외 필터에서 생성한 response 혹은 Web Container 가 실제 요청을 처리하면서 생성된 response 스트림을 가로채고 있다. chain.doFilter 를 호출하고 난 후는 필터 목록의 모든 필터들의 doFilter 가 수행을 끝냈고 Web Container 가 본래 요청에 대한 서비스를 끝낸 상태이다. 이 때 이 필터에서는 response 스트림의 끝부분을 찾아 방문자 회수를 보여주는 HTML 코드를 삽입하고 있다.


8.9 이벤트 처리기(Event Listener)

Java Servlet Specification 2.2 에는 HttpSessionBindingEvent 와 HttpSes-sionBindingListenr 라는 클래스가 있다. 이 클래스들은 특정 세션 객체의 속성 객체가 새로 생성되거나 속성 목록에서 제거될 때 그 이벤트를 받아 처리할 수 있는 기능을 제공하기 위한 클래스들이다. Java Servlet Specifi-cation 2.3 에서는 이 Event/Listener 외에 다른 여러가

지 Event/Listener 기능이 새롭게 추가되었다. 다음은 새롭게 추가된 Event 와 그 Listener 에 대한 설명이다.

ServletContext LifeCycle Event : 컨텍스트가 기동된 직후나 종료되기 직전에 발생하는 이벤트이다. 이 이벤트를 받아서 처리하고자 하면 java.servlet.ServletContextListener interface 를 구현하고 web.xml 에 등록한다.

ServletContext 의 속성 변경 Event : 컨텍스트의 속성이 새롭게 추가되거나 변경되거나 제거되는 경우 이 이벤트가 발생한다. 이 이벤트를 받아서 처리하고자 하면 java.servlet.ServletContextAttributeListener interface 를 구현하고 web.xml 에 등록한다.

HttpSession LifeCycle Event : HttpSession 객체가 생성되거나 invalidate 되거나 타임아웃에 의해 제거될 때 이 이벤트가 발생한다. 이 이벤트를 받아서 처리하고자 하면 java.servlet.http.HttpSessionListener interface 를 구현하고 web.xml 에 등록한다.

HttpSession 의 속성 변경 Event : HttpSession 의 속성이 새롭게 추가되거나 변경되거나 제거되는 경우 이 이벤트가 발생한다. 이 이벤트를 받아서 처리하고자 하면 java.servlet.http.HttpSessionAttributeListener interface 를 구현하고 web.xml 에 등록한다.


이벤트 처리기(Listener)를 구현한 후에는 web.xml 에 등록해야 하는데 <listener> 태그를 사용한다. 아래에 그 예제를 나타내었다.

<web-app>

<display-name>MyListeningApplication</display-name>

<listener>

<listener-class>

com.acme.MyConnectionManager

</listener-class>

</listener>

<listener>

<listener-class>com.acme.MyLoggingModule</listener-class>

</listener>

<servlet>

<display-name>RegistrationServlet</display-name>

...etc

</servlet>

</web-app>

같은 종류의 이벤트 처리기(Listener) 클래스가 두개이상 등록되었으면 등록된 순서대로 이벤트 처리기를 호출한다. 단, ServletContextListener 를 구현한 클래스의 경우 컨텍스트가 기동될 때는 등록된 순서대로, 컨텍스트가 종료될 때는 등록된 반대 순서로 호출된다. 컨텍스트가 종료될 때는 HttpSession 객체도 모두 invalidate 되는데 HttpSessionListener 를 구현한 클래스가 있다면 ServletContextListener 를 구현한 클래스 보다 먼저 호출된다.


8.9.1 간단한 이벤트 처리기 예제

ServletContextListener 를 구현한 예제를 아래에 나타내었다.

package listeners;

import javax.servlet.ServletContext;

import javax.servlet.ServletContextListener;

import javax.servlet.ServletContextEvent;

public class ContextListener implements ServletContextListener {

public void contextInitialized(ServletContextEvent event) {

ServletContext ctx = event.getServletContext();

String msg = "[ContextListener] contextInitialized :” +

“ contextName = " + ctx.getServletContextName();

ctx.log(msg);

System.out.println(msg);

}

public void contextDestroyed(ServletContextEvent event) {

ServletContext ctx = event.getServletContext();

String msg = "[ContextListener] contextDestroyed :” +

“contextName = " + ctx.getServletContextName();

ctx.log(msg);

System.out.println(msg);

}

}

contextInitialized 함수는 컨텍스트가 기동될 때 호출되는 함수이고, contextDestroyed 함수는 컨텍스트가 종료될 때 호출되는 함수이다.


그 외 이벤트 처리기에 대한 자세한 사항은 Java Servlet Specification 2.3의 10 장과 Servlet API reference 를 참조하기 바란다.

9 JSP 의 개요

9.1 JSP 란?

Java Server Pages(JSP)는 동적인 정보들을 web page 에 만들기 위해 HTML 과 java 를 결합시킨 JavaSoft 의 표준 specification 이다. 이는 HTML page 의 layout 에 java code 를 그대로 첨가시킬 수 있기 때문에 HTTP servlet 을 사용하는 것보다 훨씬 편리하다. JSP 는 Java Enterprise Platform 의 한 부분이다.

WebtoB Servlet Engine 는 JSP 1.2 PFD2 specification 을 지원한다. 이 버전

에서는 JSP 확장 tag 를 사용할 수 있도록 정의해 놓았다. JSP 에 대한 자세한 정보는 다음의 site 에서 볼 수 있다.

http://java.sun.com/products/jsp/index.html

Servlet 과 JSP 는 Web Application 개발을 지원하기 위한 J2EE specification 의 필수 요소이다. 둘 다 동적으로 HTML code 를 생성하는데 쓰이지만 데이터를 출력하는데 필요한 presentation 부분과 데이터를 생성하는데 필요한 business 부분을 제대로 분리할 수 있는 기술은 JSP 뿐이다. 이는 request 를 해석하고 database 를 access 하고 결과를 생성하는 등 서버에서 실행되는 code 에 전혀 관계없이 JSP page 를 이루고 있는 사용자 인터페이스를 디자인할 수 있다는 것이다. 이를 위해 사용할 수 있는 것이 HTML tag 와 비슷한 사용법을 가지고 있는 custom tag, business 부분을 감싸고 있는 JavaBeans 이다. 이런 component 들을 통해 JSP 개발에서 재사용성을 높이고 효율성을 높일 수 있게 된다.

9.2 JSP 는 어떻게 동작하는가?


9.2.1 JSP 의 동작 개요

JSP 는 server 에서 수행될 때에는 servlet 으로 바뀌어서 수행된다. 즉, HTTP server 가 JSP 에 대한 URL 요청을 받으면 이 요청은 JSP container 에게 전달되어 container 가 JSP page 를 servlet 으로 바꾸고 이를 compile 해 주는 Page servlet compiler 를 호출한다. 이 과정을 통해


요청된 JSP page 가 class 파일로 compile 이 되면 servlet 을 사용하여 요청에 대한 응답 정보를 만들어 낸다. 그리고 이를 client 로 전송한다.

이때 JSP page 를 servlet 으로 변환하고 이를 compile 하는 과정은 이 JSP page 에 해당하는 servlet class 파일이 존재하지 않거나 기존의 JSP page 가 변경될 때에만 일어난다. 따라서 최초의 요청이 들어올 때에는 compile 하는 시간이 걸리나 그 이후의 요청에 대해서는 빠르게 반응할 수 있게 된다.

Note : WebtoB Servlet Engine 는 JSP page 들에 사용된 JavaBeans class 나 custom tag class 들을 caching 해 놓아서 나중에 이 page 들에 compile 될 때에 caching 된 class 들을 그대로 사용하여 compile 한다 . 따라서 JavaBeans class 나 custom tag class 를 변경해서 compile 한 후에 이 class를 사용한 JSP page 를 제대로 실행시키기 위해서는 이 JSP page 를 다

시 저장하고 WebtoB Web Container 를 끄고 다시 켜야 한다. 그러면 새

롭게 변경된 class 들을 reload 하고 JSP page 를 다시 compile 해서 원하

는 결과를 얻을 수 있게 된다.

이런 과정을 그림으로 나타내면 다음과 같다.

그림 9-1 JSP 의 동작 화면


9.2.2 버퍼 출력 기능(Buffered Output)

HTTP 프로토콜의 기본은 요청(request)과 응답(response)이다. 웹 브라우저는 웹 서버로 요청을 보내고, 웹 서버는 그에 대한 응답으로 웹 컨텐트를 보내 준다. 또한 요청에 헤더 정보를 붙여서 브라우저의 타입과 특성(capability)을 알아내거나 캐쉬를 조정하고 쿠키(cookie) 데이터를 돌려 주는데 사용하기도 한다.

비슷하게, HTTP 프로토콜은 서버로 하여금 클라이언트에게 응답을 보낼 때 응답헤더(response header)라는 것을 보낼 수 있게 하고 있다.

이 헤더는 요청된 실제 내용(이 부분을 요청의 몸체(body)라고 한다. )과 함께 전송된다. 응답 헤더의 용도는 다음과 같다.

요청에 대한 상태 정보를 브라우저에게 되돌려 보낼 때 쓰임

요청 헤더와 같이 캐쉬 조정, 쿠키 설정 등에 쓰임

하지만 응답 헤더에는 한계가 있다. 브라우저는 컨텐트 몸체를 받기 전에 헤더 정보를 모두 받기를 바란다는 것이다. 따라서 JSP 페이지가 어떤 헤더 데이터만 브라우저로 보낼 필요가 있을 때에도 JSP 의 출력을 응답 몸체로 보내기 전에 모든 헤더 정보를 설정해야 한다는 것이다. 예를 들어 쿠키를 설정해야 할 때에도 페이지의 맨 처음 시작부분이 아닌 컨텐트 몸체를 보낸 다음에 하려고 하면 헤더에 쿠키를 설정할 수가 없게 된다.

또한 HTTP 프로토콜에서는 일단 서버가 응답을 보내기 시작한 이후에 도로 되돌리는 동작을 할 수가 없다. 도중에 전송을 취소할 수는 있지만, 브라우저는 여전히 자신이 받은 문서까지 화면에 출력한다. JSP 처리를 할 때에도 어떤 한 페이지가 시작되면 그 페이지의 출력 내용을 브라우저에 출력하지 않고서는 다른 JSP 를 처리할 수가 없다. 예를 들어 어떤 페이지를 처리하는 도중에 에러가 나면, 에러가 나기 전까지 생성된 모든 컨텐트는 에러 메시지가 달린 채로 바로 브라우저에 표시되어 버린다. 이전의 출력을 무효로 하고 에러 메시지만 표시한다든지 특별한 에러 페이지로 흐름을 돌린다든지 하는 방법은 HTTP 프로토콜에서는 존재하지 않는다.

이를 극복하기 위해 JSP specification 에서는 모든 JSP 엔진이 버퍼 출력 기능을 지원하도록 요구하고 있다. 즉, JSP 페이지가 처리되며 만들어지는 컨텐트를 일시적으로 출력 버퍼에 쌓아 두면서 전체 페이지가 처리될 때까지 기다린 다음, 처리가 모두 끝난 후에 이 버퍼에 들어있는 응답 전체를 보내는 것이다.

출력이 버퍼링되기 때문에 생기는 이점은 다음과 같이 요약할 수 있다.

JSP 페이지를 처리하는 도중이라면 어느 때이든지 헤더 정보를 설정할 수 있다. – 조건에 따라 쿠키를 설정하는 코드나 custom tag 를 포함시킬 수 있고 이 코드를 페이지 어느 부분에라도 놓을 수 있다.


웹 컨텐트를 만드는 도중에 “전면 취소”가 가능하다. – HTTP 프로토콜에서는 응답취소가 불가능하게 되어 있지만, JSP 에서는 프로그램 흐름에 따라 컨텐트를 모으는 도중에

전송취소를 결정하고 다른 응답 전송을 시작하는 것이 가능하다.

이러한 JSP 의 버퍼 출력 기능은 모든 JSP 페이지 servlet 에다가 자동으로 만들어 주는 기능이다. 하지만 버퍼 출력의 한계는 출력 버퍼의 크기(size)가 한정되어 있다는 것이다. 만약 어떤 응답 컨텐트의 길이가 너무 길어 컨텐트를 만드는 중간에 버퍼가 가득찬다면 자동으로 버퍼가 비워져(flush) 현재의 내용이 빠져나가게 되는데, 이때에는 그때까지 만든 헤더만으로 응답을 브라우저로 보내게 된다. 이후에는 응답 몸체만 계속 버퍼에 쌓였다가 보낼 수 있으며 다시 헤더를 보낼 수는 없게 된다. 따라서 추가적인 헤더를 더 보낼 수 없고, 브라우저로 출력된 응답을 취소할 수도 없게 된다.

기본적인 버퍼 크기는 8K 로 대부분의 웹페이지에는 충분한 공간이다. 하지만 필요에 의해서 버퍼의 크기를 더 키울 수도 있고, 페이지 처리 중간에 버퍼가 자동으로 비워지지 못하게 할 수도 있다.

Note : 이런 설정은 page directive(<%@ page %>)에서 설정할 수 있다. 또한 버퍼가 자동으로 비워질 때 Exception 이 발생하도록 할 수도 있다.


9.2.3 세션(session) 관리

HTTP 프로토콜의 특징 중 하나는 상태가 없다는 것이다. (stateless) 이는 HTTP 서버가 자신에 접속한 브라우저에 대한 정보를 유지하지 않는다는 것이다. 이러한 구조가 HTTP 의 명료성과 신뢰성을 높이기는 하지만 접속한 각각의 사용자에 대해 개별적인 컨텐트를 만드는 등의 세련된 웹 Application 을 만들기란 상당한 무리가 있다.

여러 개의 HTTP 요청에 대해 각각의 상태 정보를 유지하기 위한 과정을 세션관리(session management)라고 한다. JSP 는 자바 servlet API 에서 제공되는 기능을 통해 내부적으로 이 세션관리 기능을 지원한다. Servlet 은 쿠키(cookie)나 URL 다시 쓰기(rewriting) 등을 통해 세션 관리를 수행할 수 있도록 되어 있는데, 세세한 세션 관리는 JSP 수준에서는 보이지 않으므로 개발자는 신경쓰지 않아도 된다.

Note : URL 다시 쓰기는 브라우저 쪽에서 쿠키 지원이 불가능하게 되었을 때 세션을 지원하기 위해 사용하는 방법으로 모든 페이지의 URL 에 대해 세션 ID 를 요청 매개변수(request parameter)로 붙이는 것이다.


이러한 세션은 JSP 페이지의 session 이라는 내부 객체를 통해 사용 가능하다. JSP 페이지에서는 이 객체에 여러 가지 객체들을 저장할 수 있고 불러낼 수 있다. 즉, 어떤 한 페이지에서 session 객체에 어떤 객체를 넣어 두고 다른 페이지에서 이 객체를 다시 불러낼 수 있는 것이다.

하지만 session 객체에 많은 양의 데이터를 담는 일은 피하는 것이 좋다. 이는 session 이 각 사용자마다 하나씩 할당되므로 세션 저장에 필요한 데이터의 양은 동시 접속이 가능한 사용자 수에 직접적인 영향을 끼치기 때문이다. 메모리 사용량을 줄이는 방법 중 하나는 데이터의 참조정보(reference)만을 세션에 저장하는 것이다. 그리고 실제 데이터는 다른 저장소에 두었다가 세션에서 읽은 참조정보로 실제 데이터를 가지고 오는 것이다.

또한 session 객체는 사용자의 세션 제한 시간이 초과하면 JSP Container 에 의해 사라져 버린다. 이는 HTTP 프로토콜에서 사용자가 브라우저를 열어 두었는지 닫아 버렸는지를 알 수 없기 때문이다. 대신 가장 최근에 사용했을 때로부터 설정된 제한 시간이 지나면 session 객체를 소멸시키는 것이다. 그리고 그 사용자가 다시 이 site 에 접속하면 빈 session 객체가 만들어진다.

Note : JSP 세션의 타임아웃 간격은 JSP Container 에서 설정할 수 있는 변수이다. WebtoB Servlet Engine 에서는 container.xml 에서 설정할 수도 있고 web.xml 에서도 설정할 수 있다. 이때 각각의 설정의 의미는 조금 다른데 더 자세한 설명은 Ⅲ장 Container 의 설정의 Session 의 설정을 참조하기 바란다. 또한 이 값을 javax.servlet.http. HttpSession 인터페이스의 getMaxInactiveInterval() 과 setMaxInactiveInterval() 매소드를 이용하여 프로그램 상에서 알아내고 바꿀 수도 있다.

10 JSP 의 구현

10.1 JSP Reference 10.1.1 JSP tags

아래의 표는 JSP page 에서 사용하는 기본적인 tag 들을 정리해 놓은 것이다. 각각의 tag 에 대한 자세한 설명은 이 장에 계속 이어진다.


Tags 형 식 설 명

HTML 주석  HTML 형식의 주석

JSP 주석 <%-- 주석 --%> JSP 형식의 주석

Declaration <%! 변수 or 함수 선언 %> Page 범위의 변수나

함수 선언

Expression <%= 표현식 %> 변수나 함수 결과값

출력

Scriptlet <% Java_code %> Java code

Directive <%@ dir_type dir_attr %> 프로그램에서 dir_type 에 정해진

항목의 속성 지정

Actions <jsp:useBean …>

JSP codes

</jsp:useBean>

<jsp:setProperty …>

JSP page 에서 여러

가지 고급 기능들의

사용

<jsp:getProperty …>

<jsp:include …>

<jsp:forward …>

<jsp:plugin …>

Note : 여기서 HTML 주석문 안에 JSP code 가 들어있을 경우는 “주석” 이란 이름에 어울리지 않게 실행되어 버린다. 이러는 이유는 HTML 주석 tag 도 HTML tag 의 일종으로 보아서 servlet 으로 변경할 때 out.println() 함수로 그대로 출력해 버리며 이 주석 tag 사이의 code 들도 다른 HTML tag 사이에 있는 JSP code 처럼 다루게 된다. 즉, 결과로 나오는 HTML 문서를 보면 HTML 주석 tag 와 이 안의 JSP code 들의 실행 결과들이 따라 나오게 되며 브라우저에서 주석 처리되어서 화면에는 보이지 않게 된다. 따라서 debug 를 할 때 주석을 사용하기 위해서는 JSP 주석 tag 를 사용해야 한다. JSP 주석 tag 는 말 그대로 JSP compiler 에서 이 tag 안의 code 는 무시해 버리게 한다.

10.1.2 내부 객체들(예약어)

JSP 는 아래에 나오는 단어들을 ‘내부 객체들(implicit objects)’을 위해 scriptlet 과 expression 에서 미리 사용한다. 이들 객체들은 JSP page 에 대한 유용한 정보들과 함수들을 제공한다. WebtoB Servlet Engine 에서는 JSP 1.2 PFD2 specification 에 정해진 모든 내부 객체들을 구현한다.

Note : 이 내부 객체들은 scriptlet 과 expression tag 안에서만 사용해야 한다. Declaration 에서는 내부 객체들의 이름을 사용할 경우 아직 정의

되어 있지 않은 객체라며 compile error 가 난다.(undefined variable)

Servlet 관련 내부 객체


page : 이 객체는 JSP page 자체, 즉, JSP page 가 컴파일되어 만들어지는 servlet 클래스의 instance 를 가리킨다. 이는 scriptlet code 에서 this 와 같은 instance 를 가리킨다. 이때 JSP page 가 compile 되어서 실행되는 page servlet class 는 page 마다 다르기 때문에 page 내부 객체의 타입은 java.lang.Object 로 되어 있다. 따라서 javax.servlet.jsp.HttpJspPage 인터페이스에 정의된 method 를 호출하려면 page 객체를 캐스팅(casting) 해주어야 한다.

Config : config 객체는 JSP page 가 compile 되는 servlet 의 구성 데이터를 저장한다. 이 객체는 javax.servlet.ServletConfig 인터페이스를 구현한 것이다.

입력/출력용 내부 객체

request : request 내부 객체는 현재의 페이지 처리를 시작하게 한 request 정보를 가지고 있는 객체이다. 이 객체가 HTTP 요청에 대해 생긴 것이라면 발신지, 요청된 URL, 헤더, 쿠키, 그 외의 매개 변수를 이 객체를 통해 얻어낼 수 있다. request 객체는 javax.servlet.ServletRequest 인터페이스를 구현한 것이어야 하며, 통신 프로토콜들이 HTTP 이라면 이 인터페이스의 subclass 인 javax.servlet.http.HttpServletRequest 를 구현한 것이다.

response : response 내부 객체는 JSP 페이지의 처리 결과로서 사용자에게 보내어지는 response 를 나타낸다. 이 객체는 javax.servlet.ServletResponse 인터페이스를 구현하고 있으며 HTTP response 일 경우에는 이 class 의 subclass 인 javax.servlet.http.HttpServletResponse 인터페이스를 구현하고 있다.

out : 이 내부 객체는 해당 페이지, 즉 응답정보의 몸체(body)로서 브라우져에 보내어지는 content 의 출력 스트림이다. 이를 가지고 JSP 페이지에 원하는 content 를 출력할 수 있는 것이다. 이 객체는 javax.servlet.jsp.JspWriter 클래스의 인스턴스로 되어 있는데, 이는 java.io.Writer 를 확장한 추상클래스로서 java.io.PrintWriter 클래스에서 제공되는 몇 가지의 메소드가 추가되어 있다. 이 클래스는 java.io.Writer 의 표준 write() 메소드들을 모두 물려 받았으며, java.io.PrintWriter 의 print()와 println() 메소드들을 모두 구현하고 있다.

외부 환경 객체(Contextual object)


session : 이 내부 객체는 각 사용자의 현재 세션을 담고 있다. 한 사람이 웹 서버에 대해 행하는 모든 요청은 한 세션의 일부로 생각하면 간편하다. 동일한 사용자가 동일한 웹서버와 계속적으로 요청과 응답을 주고 받는 한 그 세션은 계속 없어지지 않고 유지된다. 하지만, 새로운

요청이 일정 시간 이상 들어오지 않으면 세션의 유효기간은 끝나게 된다. (expire)session 객체에는 그 세션 자체에 대한 모든 정보가 담긴다. 구현된 Application 에만 의미를 가지는 별도의 데이터는 대개 JSP 내부 객체의 공통 창구인 속성(attribute)를 통해 추가하며, 이때 javax.servlet.http.HttpSession 인터페이스에 선언된 여러 메소드들과 이에 관련된 메소드들을 사용한다.

Application : 이 내부 객체는 해당 JSP 페이지로 만들

어 지 고 있 는 Application 자 체 를 나 타 내 며 , javax.servlet.ServletContext 인터페이스를 구현한 인스턴스

(ServletContext)이다. 사실 appli-cation 이란 것은 URL 각각에 따라 JSP 페이지들이 묶인 단위인데, JSP Container 는 하나의 ServletContext 를 Application 의 단위로 여긴다.

pageContext : pageContext 객체는 다른 내부 객체를 엑세스할 수 있게 하는 객체이다. 이 객체는 어떤 내부 객체의 속성을 얻어낼 수 있는 메소드를 가지고 있다. 또한, 현재 페이지에서 다른 페이지로 흐름 제어를 넘길 수 있는 메소드를 구현하고 있어서 현재 페이지의 출력에 임시적으로 포함시킬 것을 만든다든지 제어를 완전히 넘길 수 있는 기능을 사용할 수 있다. 이 객체가 만들어진 클래스는 javax.servlet.jsp.PageContext 이다. 속성을 저장할 수 있는 내부 객체는 pageContext 객체, request 객체, session 객체, Application 객체인데, 이들은 스코프(scope)라고도 불린다. 즉, 각각의 객체에 저장되어 있는 속성은 각 객체가 존재하는 범위에서만 의미가 있다.

Note : “page”나 “request” 스코프에 저장된 속성은 JSP container 안에서 돌아가는 요청 처리를 담당하는 쓰레드 하나만이 access 할 수 있다. “session” 과 “Application” 속성의 경우는 쓰레드 안정성이 더욱 강조된다. 이들의 속성은 요청이 여러 개 들어왔을 때 동시에 처리되기 때문에, Application scope 에 저장된 객체는 다중 쓰레드 환경에 대해 문제없이 사용될 수 있도록 견고성을 가져야 한다. 또한 같은 컴퓨터에서 여러 개의 브라우저를 열고 웹서버에 들어 있는 같은 페이지를 보게 되는 경우도 있기 때문에, session scope 에 저장된 객체도 한 개 이상의 쓰레드가 동시에 access 할 수 있다는 것을 알아 두어야 한다.


에러 처리용 내부 객체

exception : 마지막 내부 객체는 exception 객체로 이를 사용하기 위해서는 page derectivie 의 isErrorPage 속성을 true 로 설정해야 한다.이는 java.lang.Throwable 클래스의 인스턴스이며 처리중 에러가 발생했을 때 브라우저에 나타나는 페이지에서 사용할 수 있다.

10.1.3 지시자(Directives)

지시자는 JSP Container 에 해당 페이지의 특수한 처리 정보를 넣고자 할 때 사용한다. 예를 들어, 이 페이지에만 사용할 스크립팅 언어를 지정한다든가, 다른 페이지의 컨텐트를 포함시킨다든가, custom tag 라이브러리를 지정한다든가 하는 일이다. 이 지시자의 종류와 간단한 설명은 다음과 같다.

JSP directive tags 형 식 설 명

Include directive <%@ include file=”…” %> 지정된 파일을 포함해서

compile 한다.

Page directive <%@ page attr=”…” … %> 전체 JSP page 의 속성을

지정한다.

Taglib directive <%@ taglib uri=”…” prefix=”…” %>

이 JSP page 에서 사용할

tag library 와 prefix 를

지정한다.


10.1.4 선언문(Declaration)

이는 주어진 JSP 페이지에서 사용되는 변수와 메소드를 정의할 때 사용하는 태그이다. 이렇게 선언된 변수와 메소드는 같은 페이지의 다른 스크립팅 요소에서 참조될 수 있다.

Note : JSP 의 인스턴스 변수를 Declaration 으로 선언할 때에는 동시에 들어오는 요청을 처리하는 여러 개의 스레드들에 의해 이 JSP 페이지가 동시에 액세스될 수 있다는 가능성을 꼭 염두해 두어야 한다. 해당 페이지에 있는 다른 스크립팅 요소가 인스턴스 변수의 값을 바꾸거나 하면 이후에는 이 페이지를 사용하고 있는 다른 쓰레드에서도 바뀐 값을 보게 된다는 것이다. 딱 하나의 요청 처리에 국한된 변수를 만들고 싶을 때에는 scriptlet 안에서 선언하면 된다. 이런 차이는 declaration 으로 선언한 변수나 함수는 JSP compiler 에

의해 servlet 으로 바뀐 뒤에는 이 servlet class 의 멤버 변수나 함수로 mapping 이 되고, scriptlet 안에서 선언한 변수는 이 servlet 의 service() 함수에서 선언되기 때문이다.

이렇게 declaration 으로 선언된 변수가 쓰레드 처리에서 안전하게 만드는 방법 중 하나는 쓰레드 처리를 하지 않도록 하는 방법이 있다. 즉, <%@ page isThreadSafe=”false” %> 라고 page directive 에 명시해 두면 JSP compiler 의 결과로 생기는 servlet 은 SingleThreadModel 인터페이스를 구현하도록 만들어지고 따라서 하나의 servlet instance 에서 여러 개의 쓰레드가 동작하는 걸 막게 한다.

이 선언문을 이용하면 JSP 페이지가 생성될 때와 소멸될 때에 각각 실행되는 함수들을 정의할 수 있다. 즉, Servlet 의 init() 함수와 destroy() 함수에 해당하는 함수인 jspInit() 함수와 jspDestroy() 함수를 정의할 수 있다. 이 함수를 정의하는 code 는 다음과 같은 모양을 가진다.

<%! public void jspInit(){

…

}

public void jspDestroy() {

…

}

%>


10.1.5 표현식(Expression)

선언문 tag 는 JSP 페이지에 변수와 메소드를 추가할 수 있게 해 주지만, 그 페이지의 출력을 위해서는 표현식 tag 를 사용한다. 이를 페이지에 사용하면 지정된 표현식을 바로 처리하여 그 결과를 페이지 출력으로 표현식 요소 대신 보낸다. 이 표현식의 형식은 다음과 같다.

<%= expr %>

이에 대한 간단한 예제는 다음과 같다. 이를 보면 쉽게 예제의 결과를 유추할 수 있을 것이다.

<html>

<head>

<title>

Hello World program

</title>

</head>

<body>

<center>

<h1>

Hello World Program

</h1>

<%

out.print(“Hello World by WebtoB Servlet Engine”);

%>

<p> Hello World by HTML

<p>

<%

for (int i=1; i<3; i++) {

%>

<h2>Hello World by HTML in a Java Loop! <%= i %></h2>

<%

}

%>

</center>

</body>

</html>

10.1.6 액션(Action)

Action tag 는 페이지 사이를 전환하거나 자바 애플릿을 설정하거나 자바빈즈 컴포넌트를 사용할 때 쓰인다. 또한 custom tag 라이브러리에 정의된 custom tag 들이 action tag 의 형식을 취하고 있다.


10.1.6.1 Forward 액션

<jsp:forward> 액션은 로컬 서버 안에서 한 JSP 페이지에서 다른 페이지로 제어를 완전히 옮기고 싶을 때, 즉 한 페이지에서 요철을 처리하다가 다른 페이지로 그 요청을 전달하고 싶을 때 사용한다. 이 tag 를 사용하면 현재의 페이지에서 생성되던 모든 컨텐트는 바로 버려지고 그 요철의 처리는 지정된 다른 페이지에서 시작된다. 이 tag 의 사용법은 다음과 같다.

<jsp:forward page=”localURL” />

또한 localURL 의 자리에는 요청시점 속성값(request-time attribute)을 사용할 수 있다. 즉, JSP 의 표현식을 사용하여 변수의 값을 localURL 의 값으로 쓸 수 있다는 것이다. 이를 사용하면 localURL 을 forwarding 할 page 의 URL 을 가지고 있는 String 변수라고 할 때 다음의 코드의 같은 모양이 된다.

<jsp:forward page=”<%= localURL %>” />

request 객체는 원래의 페이지와 옮겨진 페이지에서 공통으로 사용할 수 있기 때문에 옮겨지는 페이지에 필요한 매개 변수를 추가로 넘기는 방법으로 request 의 속성으로 지정해 주는 방법이 있다. 이는 <jsp:forward> tag 안에서 <jsp:param> tag 를 사용하면 지정할 수 있는데 예는 다음과 같다.

<jsp:forward page=”localURL” />

<jsp:param name=”parameterName1” value=”parameterValue1” />

…

</jsp:forward>

Note : JSP page 에서 client 에게 response 를 보낼 때에는 page 에서 출력하는 내용을 buffer 에 담아 두었다가 buffer 가 다 차거나 page 의 처리가 끝나면 client 로 보내게 되어 있다. 이런 상황에서 <jsp:forward> tag 를 사용할 때에는 IllegalStateException 이 발생할 수 있는데, 이 exception 이 발생하는 원인은 forward 가 이루어지기 전에 출력 버퍼가 한번 이상 flush 되어서 client 로 content 가 보내어졌을 경우이다. 이때에는 HTML 헤더 부분도 전송이 되므로 forwarding 된 page 에서 다시 새로운 page 를 보낼 수 없게 된다. 이를 피하기 위한 방법은 다음과 같다.

<jsp:forward> tag 를 사용하기 전에 출력 버퍼가 flush 되지 않도록 한다.

버퍼 출력이 되지 않는 페이지의 경우, <jsp:forward> tag 를 content 출력 부분 앞에 둔다.

Note : 또한 <jsp:forward> tag 를 만나면 그 이후의 code 들은 실행되지 않으므로 그 page 에서 특정한 자원을 할당해서 사용했을 경우에는 이 tag 앞부분에 이 자원들을 해제해 주는 code 를 두어야 한다.


10.1.6.2 Include 액션

<jsp:include> 액션은 현재의 페이지에 다른 로컬 page 에서 생성된 content 를 간접적으로 포함시킬 때 사용한다. 이 content 는

<jsp:include> tag 의 자리를 대신 차지하며 그 content 이후에는 원래 페이지의 처리가 계속된다. 이 tag 의 형태는 다음과 같다.

<jsp:include page =”localURL” flush=”true” />

이때 flush 속성은 해당 페이지의 출력을 넣기 전에 현제 페이지의 출력 버퍼를 비울 것인가를 지정한다. JSP 1.2 specification 에 따르면 이 속성은 servlet API 의 한계 때문에 항상 true 로 설정되어 있어야 한다.

Note : 이런 제약사항 때문에 <jsp:include> tag 를 사용하는 페이지에서는 여러 가지 불가능한 동작들이 생긴다. 이들은 다음과 같다.

다른 페이지(에러 페이지 포함)로의 forwarding

쿠키나 HTTP 헤더의 설정

포함되는 페이지에 request 를 넘기거나(forwarding 을 하거나) 그 페이지에서 쿠키 및 헤더를 설정하는 것

<jsp:include> tag 에서도 forward 와 마찬가지로 param tag 를 사용하여 매개변수를 넘겨줄 수 있다. 이 예는 다음과 같다.

<jsp:include page=”localURL” />

<jsp:param name=”parameterName1” value=”parameterValue1” />

…

</jsp:include>

<jsp:include> tag 가 실행되면 지금까지의 출력이 flush 되어서 client 에 넘겨진 후에 include 되는 페이지에 request 를 넘기고 이 페이지를 JSP Container 가 처리하게 된다. 그리고 이 페이지의 출력이 끝나면 다시 원래 페이지로 돌아가서 계속 처리를 하게 된다. 따라서 포함되는 페이지가 변경되었더라도 JSP Container 가 이 페이지를 처리하면서 다른 페이지가 변경되었을 때처럼 재컴파일을 하게 된다.

Note : JSP tag 중에 다른 페이지를 포함하는 tag 는 <jsp:include> action tag 말고도 include directive(<%@ include %>)가 있다. include directive 는 action tag 와는 달리 포함되는 페이지를 아예 원래 페이지의 servlet 에 포함시켜 버린다. 이는 C 의 include 와 같은 작용을 한다. 따라서 포함되는 페이지가 변경되었더라도 원래 페이지가 변경되지 않으면 다시 컴파일되지 않는다. 이 둘을 구별하면 다음과 같다.


Include Directive 로 지정된 페이지 : 원래의 페이지와 하나가 되어 하나의 servlet 이 된다.

Include Action 으로 지정된 페이지 : 원래의 페이지 바깥에서 request 를 넘겨받아 처리하고 다시 원래의 페이지 servlet 으로 돌아간다.

10.1.6.3 Plug-in 액션

자바 2 를 이용한 Applet 을 브라우저에서 보여주기 위해서는 이를 실행시킬 수 있는 브라우저 플러그-인(Plug-in)을 브라우져에 설치해야 한다. 또한 자바 플러그-인을 사용하는 페이지에 애플릿을 추가시킬 때 사용하는 HTML tag 가 브라우저마다 다르다. 결국 플러그-인을 통해 애플릿을 실행시키도록 설정하려면 HTML 만 사용해서 하긴 힘들다.

이를 단순하게 하기 위해 JSP 에서는 플랫폼에 독립적인 <jsp:plugin> tag 를 제공하고 있다. 이 tag 를 사용한 예는 다음과 같다.

<jsp:plugin type=”type” code=”objectCode”

codebase=”objectCodeBase”

height=”100” width=”100” …>

<jsp:params>

<jsp:param name=”parameterName” value=”parameterValue”/>

…

</jsp:params>

<jsp:fallback>fallback text</jsp:fallback>

</jsp:plugin>

위의 예에서 <jsp:plugin> tag 의 처음 다섯가지 속성은 필수로 넣어 주어야 한다. 이외에도 여러 가지의 선택적인 속성이 있다. 매개변수를 지정해 줄 때에는 <jsp:params> tag 안에 <jsp:param> tag 를 사용한다. 그리고 어떤 이유로 플러그인이 사용되지 못했을 때에 표시할 text 는 <jsp:fallback> tag 안에 기록하게 된다. 이 외에도 여러 가지 속성이 있는데, WebtoB Servlet Engine 는 JSP specification 1.2 PDF2 의 구현을 따르고 있다.


10.2 자바빈즈(JavaBeans)의 사용

JavaBeans 는 뒤에서 설명할 custom tag 와 함께 JSP 컴포넌트(Component) 모델을 이루고 있다. 컴포넌트란 개체에 모든 것을 갖춘 재사용성이 가능한 소프트웨어 부품으로서, 동작 원리와 데이터를 꾸러미로 묶어 가지고 있다. 해당 컴포넌트의 내부에 대해서는 사용자가 전혀 고민할 필요가 없고 사용하는 interface 만

신경쓰면 된다. 컴포넌트의 동작은 특정한 Application 에 대해서만 국한되지 않기 때문에 적절한 쓰임새만 보이면 어디든 사용할 수 있다. 이러한 추상화(abstraction)와 재사용성(reusability)은 컴포넌트 중심 설계의 핵심이다.

10.2.1 자바빈즈의 개요

자바빈즈(JavaBeans)는 자바로 작성된 소프트웨어 컴포넌트를 두루 지칭하는 말이다. 이 컴포넌트 자체는 빈(Bean)이라고 불리며 Sun 의 자바빈즈 API 에 나온 스펙을 따라 만들어진다. JSP 에서는 자바빈즈를 자신의 컴포넌트 모델로 채택하여 content 개발자가 자바 언어를 몰라도 빈을 통해 자바의 기능을 충분히 사용할 수 있는 수단을 제공하였고 이것이 바로 빈 태그(Bean tag)라고 불리는 자바빈즈 전용 tag 이다. WebtoB Servlet Engine 는 JSP 1.2 PFD2 specification 에 있는 JavaBeans 에 대한 사항을 모두 지원한다.

자바빈즈는 간단히 말해 다음과 같은 요소를 가지고 있는 자바 클래스라고 할 수 있다.

아무 인자도 받지 않는 public constructor

각각의 variable 에 대한 set() 함수

각각의 variable 에 대한 get() 함수


10.2.2 자바빈즈 객체의 생성

<jsp:useBean> tag 는 이 페이지에서 어떤 빈을 사용하겠다는 것을 지정한다. 즉, 빈을 생성하거나 서버에 있는 빈을 페이지로 올리는데 사용하며, 이 태그의 속성을 사용하여 빈의 타입을 정하고 이름을 지어 붙인다. 또한 이 태그 안에 자바빈즈 객체가 생성될 때에 실행되는 초기화 code 를 넣어서 처음 생성될 때 실행되도록 할 수 있다. 다음은 자바빈즈 객체를 생성하는 형식을 나타낸 것이다.

<jsp:useBean id=”bean name” class=”class name” />

or

<jsp:useBean id=”bean name” class=”class name” >

Initailization codes

</jsp:useBean>

이런 형식을 사용하면 class 속성에 지정된 class 의 자바빈즈 객체를 id 속성에 정해진 이름으로 생성한다. 또한 초기화 코드가 tag 안에 있을 경우에는 생성될 때에 이 code 를 수행한다. 만약 지정된 id 의

자바빈즈 객체가 현재 page 의 scope 에 있을 때에는 객체를 생성시키지 않고 존재해 있는 것을 갖다 쓰게 되므로 초기화 코드는 수행되지 않는다. Scope 속성의 기본 값은 “page”이다.

기본적으로 빈은 원래 객체의 클래스 이름을 그대로 사용하여 참조되는게 보통이다. 하지만 이 빈 객체를 자신의 클래스의 슈퍼클래스나 이 빈이 구현한 인터페이스의 타입으로 page 에서 참조할 필요가 있다면 <jsp:useBean> tag 의 type 속성에 사용할 타입을 지정해서 이 타입으로 casting 된 객체를 페이지에서 참조할 수 있다. 만약 type 이 List 나 Set 등의 Collection 클래스의 subclass 인데 Collection 클래스의 객체로 캐스팅해서 쓰고 싶다면 다음과 같이 하면 된다.

<jsp:useBean id=”bean name” type=”java.util.Collection” />

Note : 만약 id 에 지정된 이름의 자바빈즈 객체가 지정된 scope 에 존재하지 않는다면 class 속성 없이 type 속성만 지정해 두면 InstantiationException 이 발생한다. 즉, 객체가 생성되어야 할 때에는 항상 class 속성이 지정되어 있어야 한다.

10.2.3 자바빈즈 객체의 사용

생성된 자바빈즈 객체는 <jsp:setProperty> tag 와 <jsp:getProperty> tag 를 가지고 사용한다 . <jsp:setProperty> 는 빈의 property 를 설정할 때 , <jsp:getProperty>는 빈의 property 를 가져올 때 사용한다. 이 tag 들을 사용하는 형식은 다음과 같다.

<jsp:setProperty name=”id of the bean” property=”propertyName”

value=”propertyValue” />

<jsp:getProperty name=”id of the bean” property=”propertyName”

/>


10.2.4 자바빈즈의 scope

빈을 액세스할 수 있는 대상과 빈의 수명, 즉 스코프는 <jsp:useBean> tag 의 scope 속성을 통해 결정된다. 이 속성에 담을 수 있는 값은 page, request, session, Application 이다. 빈의 액세스 가능 대상(accessibility)는 Application 의 어떤 부분이나 페이지가 빈을 엑세스할 수 있는지를 지정하는 것이고 빈의 수명(life span)은 이 빈이 언제까지 사용 가능한 상태로 있는지 지정하는 것이다. 각 스코프의 특성은 다음 표와 같다.

스코프 액세스 가능 대상 수 명

Page 오직 현재의 페이지만 페이지가 표시되거나 다른

페이지로 제어가 넘어가기

전까지

Request 현재의 페이지와 여기에

포함되거나 forwarding 되는

페이지

요청이 완전히 처리되고

응답이 사용자에게 돌려질

때까지

Session 동일한 브라우저

윈도우에서 행해지는

현재의 요청과 그 이후의

요청들

session objec 의 수명과 동일

Application 동 일 한 웹 Application 의

일부가 되는 현재와 이후

의 요청들

Application object 의 수명과 동일

10.2.5 자바빈즈의 구현

지금까지 살펴본 자바빈즈의 대략적인 모습을 바탕으로 여기서는 DB connection 을 관리하는 자바빈즈를 하나 만들어 활용하는 방법을 살펴 보기로 하겠다.

10.2.5.1 빈에서 구현 가능한 인터페이스(Bean Interfaces)

자바빈즈가 구현할 수 있는 인터페이스에는 세가지가 있다. 이를 나열하면 다음과 같다.


BeanInfo 인터페이스 : 빈 클래스가 빈 Container 에게 자신의 프로퍼티 정보를 알리는 수단 중 하나도 BeanInfo 인터페이스를 구현하는 방법이 있다. BeanInfo 인터페이스는 어떤 빈의 프로퍼티와 액세스 수준을 대신 정의해 주는 클래스를 구현할 수 있는 틀로서 기존의 자바 클래스라도 그 클래스의 인터페이스를 바꾸지 않고 자바빈즈로서 활용할 수 있도록 할 수 있다. 또한 자바의 리플렉션이 너무 상세하기 때문에 어떤 메소드를 숨길 때에도 쓸 수 있다.

Serializable 인터페이스 : JSP specification 에서는 나와 있지 않지만 자바빈즈 규약에 나와 있는 한 가지가 바로 “빈은 Serializable 인터페이스를 구현해야 한다.” 라는 항목이다. 즉, 사용하고 있는 빈을 직렬화하여 이후에 사용할 수 있도록 디스크에 저장될 수 있는 이진 데이터 스트림으로 바꿀 수 있어야 한다는 것이다. 이때에는 그 당시의 빈 상태가 모두 보존되어 기록된다. 이렇게 하는데는 몇가지 이유가 있다. WebtoB Servlet Engine 에서는 클러스터링을 지원하는데, 이때 클러스터링으로 묶인 서버 사이에는 session 객체의 공유가 가능하다. 이때에는 session 에 저장되는 빈이 Serializable 인터페이스를 구현해야만 session 객체의 공유가 가능하게 된다. 또한 종료할 때 모든 세션 데이터를 디스크에 기록함으로서 장기간 세견 관리 기능을 지원하는데 이때에도 빈들이 직렬화가 가능해야 한다.

HttpSessionBindingListener 인터페이스 : 자바빈즈에서 이 인터페이스를 구현하면 세션 이벤트의 통지를 받을 수 있게 된다. 즉, 세션에 자바빈즈가 저장되거나 세션에서 이 객체가 사라질 때 이벤트 통보를 받아서 이 인터페이스에 선언된 메소드가 호출된다. 이 메소드들은 다음과 같다.

public void valueBound(HttpSessionBindingEvent event)

public void valueUnbound(HttpSessionBindingEvent event)

valueBound() 메소드는 빈이 사용자의 세션에 처음 저장될 때(Binding) 호출된다. 이는 대부분 세션 스코프를 지정하는 <jsp:useBean> 태그에 의해 빈의 인스턴스가 생긴 직후에 이루어지는 일일 것이다.valueUnbound() 메소드는 현재의 세션에서 빈이 제거될 때 호출된다. 이런 상황은 이 세션의 타임 아웃이 지나서 세션 객체가 사라지거나 다른 servlet 이나 JSP 문서의 자바 코드에서 이 빈을 세션에서 제거할 때이다. 이때 발생하는 객체는 HttpSessionBindingEvent 타입의 객체인데, 이를 사용하면 세션 객체까지 액세스할 수 있다. 이 인터페이스를 통해 세션 이벤트를 자유롭게 처리할 수 있을 것이다.


HttpSessionBindingListener 인터페이스 : 자바빈즈에서 이 인터페이스를 구현하면 세션 이벤트의 통지를 받을 수 있게 된다. 즉, 세션에 자바빈즈가 저장되거나 세션에서 이 객체가 사라질 때 이벤트 통보를 받아서 이 인터페이스에 선언된 메소드가 호출된다. 이 메소드들은 다음과 같다.

public void valueBound(HttpSessionBindingEvent event)

public void valueUnbound(HttpSessionBindingEvent event)

valueBound() 메소드는 빈이 사용자의 세션에 처음 저장될 때(Binding) 호출된다. 이는 대부분 세션 스코프를 지정하는 <jsp:useBean> 태그에 의해 빈의 인스턴스가 생긴 직후에 이루어지는 일일 것이다.valueUnbound() 메소드는 현재의 세션에서 빈이 제거될 때 호출된다. 이런 상황은 이 세션의 타임 아웃이 지나서 세션 객체가 사라지거나 다른 servlet 이나 JSP 문서의 자바 코드에서 이 빈을 세션에서 제거할 때이다. 이때 발생하는 객체는 HttpSessionBindingEvent 타입의 객체인데, 이를 사용하면 세션 객체까지 액세스할 수 있다. 이 인터페이스를 통해 세션 이벤트를 자유롭게 처리할 수 있을 것이다.


10.2.5.2 간단한 빈 작성

자바빈즈의 예로 작성하게 되는 빈은 여러 개의 숫자를 받아 통계 계산을 수행해 주는 간단한 빈이다. 이 StatBean 의 소스는 다음과 같다.

package jeus.example;

import java.util.*;

public class StatBean

{

private double[] numbers;

public StatBean()

{

numbers = new double [2];

numbers[0] = 0;

numbers[1] = 1;

}

public double getAverage()

{

double sum = 0;

for (int i=0; i < numbers.length; i++)

{

sum += numbers[i];


}

return sum/numbers.length;

}

public double getNumbers(int index)

{

return numbers[index];

}

public void setNumbers(double[] new_numbers)

{

numbers = new_numbers;

}

public void setNumbers(int index, double value)

{

numbers[index] = value;

}

public void setNumberList(String values)

{

Vector n = new Vector();

StringTokenizer tok = new StringTokenizer(values, ",");

while (tok.hasMoreTokens())

n.addElement(tok.nextToken());

numbers = new double[n.size()];


numbers[i]

= Double.parseDouble((String)

n.elementAt(i));

}

public String getNumbersList()

{

String list = new String();


{

if ( i != numbers.length)

list += numbers[i] + ",";


else

list += numbers[i];

}

return list;

}

public int getNumbersSize()

{

return numbers.length;

}

}

이 StatBean 은 주어진 값의 평균을 구해 주는 로직을 가지고 있다. 이렇게 자바빈즈는 Application 에서 필요한 business logic 들을 JSP 문서에서 감추어 주는 역할을 함으로서 presentation logic 과 분리될 수 있도록 한다.

이 빈을 사용한 JSP 문서를 보면 다음과 같다.

<jsp:useBean id=”stat” class=”jeus.example.StatBean”>

<jsp:setProperty name=”stat” property=”numbersList”

value=”100,250,150,50,450” />

</jsp:useBean>

<html>

<body>

The average of <jsp:getProperty name=”stat”

property=”numbersList” /> is

equal to <jsp:getProperty name=”stat” property=”average” />

</body>

</html>

이 JSP 문서에서는 먼저 <jsp:useBean> 태그를 사용해서 StatBean 의 객체를 생성하고 생성될 때에 numbersList property 의 값을 <jsp:setProperty> 태그를 이용해 지정해 주고 있다. 이렇게 자바빈즈를 이용하면 자바 코드를 하나도 쓰지 않고도 원하는 결과를 만들어내는 JSP 문서를 깔끔하게 만들 수 있다.

10.3 Custom tag 의 사용

앞에서도 이야기 했듯이, 다른 동적 컨텐트 생성 시스템에 비해 JSP 가 가지는 가장 큰 장점은 presentation 과 프로그램 구현의 분리를 완벽하게 할 수 있다는 것이다. HTML 코드에 스크립트 언어를 이리저리 꼬아 넣는 일을 막아주기 때문에 JSP 페이지의 유지 보수성은 꽤 좋으며 하부기능을 맡아 수행하는 자바 코드도 재사용할 수 있다.

하지만, JSP 에서 자바진 객체를 사용할 수 있게 도와주는 tag 는 세 개 뿐으로 이 tag 로 할 수 없는 일이 생기면 어쩔수 없이 자바코드를 끼워 넣을 수밖에 없다. 하지만 JSP 1.2 PFD2 specification 에서는 JSP 의 tag 를 확장할 수 있는 custom tag 를 제공하고 있다.

자바빈즈의 property 를 가지고 동적 HTML 생성을 구현하는 것은 바람직하지 않다. 빈은 어떤 Application 을 만들든 상관없이 사용할 수 있는 비즈니스 부분을 구현하는 독립형 컴포넌트이기 때문이다. 만약 자바 프로그래밍을 통해 HTML 컨텐트를 생성하고 싶다면 custom tag 를 사용하는 것이 좋다. Custom tag 의 성질은 다음과 같이 간추릴 수 있다.

태그의 동작을 설정하는 속성(Attribute)를 가질 수 있다.

몸체(body)를 가질 수 있다 - 이는 중첩된 JSP 요소나 tag 자체에 의해 처리되는 tag 만의 컨텐트로 이루어진다.

다른 tag 와 함께 동작할 수 있다 - 중첩된 태그의 계층구조를 통해 정보를 요청하던가 새로운 스크립트 변수를 정의 도입하여 다음의 tag 들이 사용할 수 있도록 함으로서 가능하다.

다른 JSP 구성 요소와 같이 custom tag 도 자바 객체로 구현한다. 즉, 원하는 tag 기능을 하는 자바 클래스를 만드는 것이다. 따라서 모든 자바 API 를 사용할 수 있게 된다. WebtoB Servlet Engine 에서는 이러한 JSP specification 의 tag 확장 매커니즘을 모두 지원하고 있다. 이러한 custom tag 를 사용하면 주로 다음과 같은 종류의 일을 수행할 수 있다.


출력하는 것들을 만들어낸다 – tag 의 출력은 tag 를 둘러싸고 있는 범위로 출력하는 것으로 JSP 페이지에 바로 tag 가 포함되어 있다면 JSP 페이지 output 에, 다른 tag 에 포함되어 있다면 바로 바깥 tag 의 output 에 출력을 하게 된다.

새로운 객체를 정의해서 JSP page 의 변수로 사용할 수 있다 - 이때 tag 는 tag 의 속성으로 지정한 값으로 변수 이름을 정할 수 있다.

몸체 부분을 어떤 조건이 만족될 때까지 반복할 수 있다.

몸체 부분을 수행해야 할지, 그냥 건너 뛰어야 할지도 결정할 수 있다. 또한 남은 페이지의 부분을 수행할지, 건너 뛰어 페이지의 수행을 끝낼 지도 결정할 수 있다.

10.3.1 Custom tag library

10.3.1.1 Custom tag library 의 원리

Custom tag 를 사용하기 위해서는 이 tag 의 기능이 구현되어 있는 tag handler 라는 java class 와 이 tag 들이 등록되어 있는 TLD 파일이 있어

야 한다.

태그 라이브러리(tag library)는 전형적인 JAR 파일로서, 라이브러리의 태그를 구현하고 있는 클래스 파일들이 여기에 들어 있다. 이 외에도 META-INF 라는 최상위 디렉토리가 있어서 이 압축 파일 자체의 정보를 담고 있다. 이 디렉토리의 파일중 하나가 MANIFEST.MF 라는 것으로 해당 압축 파일에 담겨진 모든 파일 리스트와 압축파일의 무결성을 확인하는데 사용하는 인증 데이터가 들어 있다. 여기에 덧붙여 JSP 태그 라이브러리를 담은 JAR 파일의 경우 이 디렉토리에 taglib.tld 라는 파일(이 라이브러리에 대한 TLD 의 사본)이 들어 있다. TLD 는 해당 라이브러리에서 제공되는 custom tag 를 식별하고 설명하는 XML 파일이다.

TLD 파일은 JSP 페이지를 컴파일할 때 custom tag 의 유효성을 검사하는데 쓰인다. 즉, 컴파일 할 때에 tag handler class 까지 로드할 필요가 없다는 것이다. 만약 새로운 스크립트 변수를 추가시킬 목적으로 custom tag 가 쓰일 경우에는 몇가지가 더 필요하다. TLD 에는 해당 custom tag 에서 들여오는 스크립트 변수의 이름과 타입을 JSP Container 가 식별하는데 필요한 Helper class 가 설정되는데 이 class 에서 추가적인 검사가 가능하다.


10.3.1.2 Custom tag library 설정용 요소

TLD 는 XML 문서이기 때문에 표준 XML 헤더 정보를 가지고 있어야 한다. JSP 태그 라이브러리에 대한 헤더의 예는 다음과 같다.

<?xml version=”1.0” encoding”ISO-8859-1” ?>

<!DOCTYPE taglib PUBLIC

“-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN”

“http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd”>

TLD 를 이루는 중심 태그는 <taglib>로서, 여기에 몇 개의 하위 요소 태그를 넣어 쓴다. 이중 하나가 라이브러리의 tag 를 지정할 때 쓰는 <tag>이다. 그 이외의 하위 태그 요소들은 라이브러리 자체의 특성을 설정한다.


10.3.1.3 라이브러리를 설명해 주는 요소들

<taglib>의 하위 요소로 오는 다섯가지는 라이브러리를 설명하는데 쓰인다. 이들의 예는 다음과 같다.

<taglib>

<tlibversion>1.0</tlibversion>

<jspversion>1.1</jspversion>

<shortname>jeus</shortname>

<info>Custom tag library for WebtoB Servlet Engine</info>

<uri>http://localhost/taglib/jeus_1_0.tld</uri>

…

</taglib>

이 tag 들은 속성을 가지지 않는다. 필수 요소들은 <tlibversion>과 <shortname>이다.

<tlibversion> 태그는 태그 라이브러리의 버전 정보를 설정한다. 완전한 버전 형식은 N.N.N.N 으로 N 은 한자리 숫자이다. N=0 일때는 생략 가능하지만 첫번째 N 은 생략할 수 없다.

<jspversion> 태그는 현재의 태그 라이브러리가 따르는 JSP specification 의 버전을 나타낸다. Default 값은 1.1 이다.

<shortname> 태그는 태그 라이브러리 이름의 축약형을 지정할 때 사용한다. 이 이름은 JSP Container 나 JSP 개발 도구에서 변수 이름을 생성할 때 사용하기 때문에 변수 이름을 지을 때의 규칙인 첫 글자는 알파벳, 공백 문자가 없다는 규칙을 따라야 한다.

<info> 태그는 커스텀 태그 라이브러리를 문서화할 때 포함될 텍스트 문자열을 정할 경우 사용한다. Default 값은 빈 문자열이다.

<uri> 태그는 쓰지 않아도 되는 것으로 태그 라이브러리의 도규먼트시 추가로 붙일 정보가 있을 때 사용한다. 이 태그의 몸체에는 현재 버전의 라이브러리에서 공개적으로 사용할 수 있는 TLD 사본을 가리키는 URL 이 들어간다. 즉, 남이 만든 커스텀 태그 라이브러리를 사용하는 페이지 디자이너는 원래 소스를 참조해야 할 필요가 있을 때 TLD 의 이 부분을 보면 된다.


10.3.1.4 Custom tag 를 설정해 주는 요소들

TLD 의 <taglib>에는 이 tag 의 하위 요소인 <tag>도 한 개 이상 꼭 들어가야 한다. 라이브러리에 정의된 커스텀 태그마다 하나씩 <tag> 있게 되는데, <tag> 자체에도 다섯 개의 하위 요소 태그로 custom tag 의 특성을 설정하도록 하고 있으며 tag 의 속성도 지정할 수 있다. 이 tag 들의 예는 다음과 같다.

<tag>

<name>forProperty</name>

<tagclass>jeus.servlet.jsp.taglib.forPropertyTag</tagclass>

<teiclass>jeus.servlet.jsp.taglib.forPropertyTei</teiclass>

<bodycontent>JSP</bodycontent>

<info>

Loop through an indexed property.

</info>

…

</tag>

이중 필수인 요소는 <name>과 <tagclass>로서 <name>은 해당 custom tag 의 식별자를 설정할 때 사용한다. 이 식별자가 JSP 페이지에서 사용될 때에는 라이브러리의 namespace 접두어와 조합되어 사용된다. 즉, 위의 예제에서 jeus 란 접두어와 함께 이 tag library 를 사용하는 JSP 페이지에서 이 custom tag 를 사용할 때의 이름은 <jeus:forProperty> 가 된다.

<tagclass> tag 는 이 custom tag 의 handler 를 구현하는 클래스를 설정한다. 클래스 이름은 패키지 이름까지 정확히 앞에 붙은 완전한 형식을 따른다. <teiclass> 태그는 custom tag 에 대한 helper class 를 설정

할 때 사 용 한 다 . TEI 라는 것은 이 helper class 들이 확장하는 javax.servlet.jsp.tagext.TagExtraInfo 클래스의 이름에서 따온 것이다.

<bodycontent>는 tag 의 시작 tag 과 끝 tag 사이에 오는 몸체 컨텐트의 타입을 지정할 때 사용하는 태그이다. 여기엔 empty, JSP,

tagdependent 의 세가지 값을 줄 수가 있다. Empty 는 tag 사이에 몸체가 들어가지 않는다는 뜻이고, JSP 는 tag 사이의 몸체는 JSP code 라는 것을 의미한다. 이 두가지 종류에 대해서는 JSP Container 가 컴파일 과정에서 태그의 몸체에 대한 JSP 문법 검사를 수행한다.

이 값이 tagdependent 이면 tag 자체에서 몸체의 해석을 한다는 것이다. 즉, 이 몸체에 대해서는 JSP Container 가 수행하지 않고 전적으로 tag 의 이용에 맡긴다는 것이다.

<info> tag 는 태그의 설명문이 온다.


10.3.1.5 Tag 의 속성(attribute)를 지정해 주는 요소들

만들고 있는 custom tag 가 속성을 가진다면 <attribute> tag 를 사용하여 TLD 에 지정해 주어야 한다. 이 tag 자체의 하위 요소는 세가지이다. 여기에 관한 예제는 다음과 같다.

<tag>

…

<attribute>

<name>id</name>

<required>true</required>

<rtexprvalue>false</rtexprvalue>

</attribute>

…

</tag>

이 속성 중 <name> tag 는 필수 요소이다. 이는 속성의 식별자를 문자열로 정해줄 때 사용한다. 위의 예제가 앞의 forProperty tag 의 속성이라면 속성의 지정은 다음과 같이 한다.

< jeus:forProperty id=”loop”>

이렇게 사용하기 때문에 속성의 이름은 tag 의 이름을 정할 때와 같이 변수의 이름 규칙을 따른다.

<required> tag 는 이 속성이 필수적인지(required) 선택적인지(optional) 구분해 줄 때 사용한다. Default 값은 false 이다. True 이면 JSP 페이지에서 이 속성을 지정해 주었는지 JSP Container 에서 검사를 하게 된다.

<rtexprvalue> tag 는 이 속성의 값을 정할 때 요청 시점 속성값(request-time attribute)을 허용할 지를 구분한다. Default 값은 false 인데 이는

고정된 값만 속성의 값으로 지정할 수 있다는 뜻이고 true 일 때에는 어떤 변수의 값이 속성의 값으로 지정이 될 수 있다는 것이다. 즉 다음과 같은 형식이 가능하게 된다.

<jeus:item text=”<%= cookies[i].getName() %>”/>

위의 형식으로 사용하게 되면 tag 를 구현하는 handler class 의 해당 attribute 의 set 함수의 인자로는 cookies[i].getName() 함수가 돌려주는 String class 의 객체가 할당된다. 즉, 객체가 전달된다는 것이다.

10.3.1.6 Custom tag library 설정용 요소 – JSP 1.2

JavaServer Page Specification 1.2 부터 TLD 를 작성하는 태그의 모양이 달라졌다. 물론 이전 버전의 태그도 그대로 지원한다. 여기에서는 달라진 태그와 새롭게 추가된 태그에 대해서 설명하기로 한다.

우선 JSP 태그 라이브러리에 대한 헤더는 다음과 같이 바뀌었다.

<?xml version=”1.0” encoding”ISO-8859-1” ?>

<!DOCTYPE taglib PUBLIC

“-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN”

“http://java.sun.com/j2ee/dtd/web-jsptaglibrary_1_2.dtd”>

기능은 이전것과 동일하나 이름만 바뀐 태그들은 다음과 같다.

tlibversion tlib-version

jspversion jsp-version

shortname short-name

info description

tagclass tag-class

teiclass tei-class

bodycontent body-content

새롭게 추가된 태그중 중요한 것들은 다음과 같다.


<validator> : <taglib> 태그에 새롭게 추가된 태그이다. JSP 1.2 에 javax.servlet.jsp.tagext.TagLibraryValidator 라는 추상 클래스가 새로 추가 되었는데 개발자가 이 클래스를 상속받아 이 태그를

이용해 등록하면 validate 라는 함수를 통해 JSP 소스 파일의 문법 검사를 서비스 시작전에 할 수 있다.

<listener> : <taglib> 태그에 새롭게 추가된 태그이다. Javax 패키지의 Listener 인터페이스를 구현한 클래스를 이곳에 등록할 수 있다. Listener 에 대해서는 9 장. 이벤트 처리기를 참조하기 바란다.

<variable> : <tag> 태그의 하위 요소이다. 이 태그에 의해 생성될 스크립팅 변수를 지정한다. JSP specification 1.1 에서는 TagExtraInfo 클래스에 의해 변수를 생성하였다. JSP specification 1.2 에서는 이외에 이 태그를 사용하여 TLD 로부터 변수를 생성할 수 있게끔 하였다.

기타 자세한 사항은 JavaServer Page specification 1.2 를 참조하기 바란다.

10.3.2 Custom tag 의 구현에 필요한 API 들

Custom tag 의 handler class 와 helper class 를 구현하는 용도로 JSP 에서 지원하고 있는 자바 클래스와 인터페이스는 모두 javax.servlet.jsp.target 패키지에 모여 있다.


10.3.2.1 Tag handler

태그 핸들러(tag handler)는 custom tag 가 쓰였을 때 그 태그에 대해 설정된 동작을 수행하는 자바 객체이다. 페이지 처리 중에 custom tag 를 만나게 되면 그 tag 의 handler class 의 인스턴스가 나타나 초기화되고 원하는 동작을 수행한 뒤에 리소스 풀로 빠져서 재사용을 기다리게 된다. 다음에 같은 tag 가 수행될 때에는 새로 생성하지 않고 이전의 리소스 풀에서 가져와 사용하게 된다.

Note : 이런 특성 때문에 custom tag 가 한번 수행된 뒤에는 인스턴스의 상태를 원래대로 돌릴 필요가 있다. 이렇게 해야만 다시 같은 tag 가 수행될 때에 리소스 풀에서 가져온 인스턴트가 제대로 동작할 수 있게 될 것이다. 이렇게 리소스 풀을 사용하는 까닭은 인스턴스를 생성하는데 드는 시간을 줄여서 성능을 높이기 위해서이다.

Custom tag 를 수행하기 위해 Tag handler 클래스가 구현해야 하는 메소

드 들 은 javax.servlet.jsp.targext.Tag, javax.servlet.jsp.targext.IterationTag, javax.servlet.jsp.targext.BodyTag 인터페이스에 정의되어 있다 . Custom tag 가 수행되는 흐름은 JSP specification 에 정의되어 있어서 JSP Container 는 정의에 따라 handler class 의 메소드들을 호출하게 된다.

따라서 custom tag 를 구현하는 사람은 이 흐름에 맞는 동작을 하는 정해진 메소드들을 적절히 구현하기만 하면 된다.

Tag handler 클래스가 구현해야 하는 메소드들을 기본적으로 구현해 놓은 class 는 같은 패키지 내에 있는 TagSupport 와 BodyTagSupport 클래스로서 이 class 를 확장함으로써 개발자는 handler class 에 필요한 기본적인 함수들을 따로 구현하지 않아도 된다. 이제 여기서 자기가 원하는 함수들만 재정의하면 되는 것이다.

이렇게 태그 핸들러 인터페이스가 두 개 있는 이유는 custom tag 의 동작 유형에 따라 나누어졌기 때문이다. BodyTag 인터페이스와 BodyTagSupport 클래스는 몸체 컨텐트를 조작 처리해야 하는 custom tag 를 구현할 용도로 만들어 졌고 IterationTag(Tag 를 상속) 인터페이스와 TagSupport 클래스는 단순한 custom tag, 또는 반복 작업을 하는 tag 를 만들 용도로 만들어졌다. 이들은 모두 custom tag 를 구현하는 데 사용되므로 기본 기능은 동일하다. 실제로 BodyTag 인터페이스는 Tag 인터페이스를 확장한 것이며 BodyTagSupport 는 TagSupport 의 subclass 이다.

10.3.2.2 Tag handler class 의 생존 주기(life cycle)

Tag 인터페이스를 구현한 tag 의 생존주기


Custom tag 를 개발하기 위해서는 JSP Container 가 어느 순간에 어떤 handler 클래스의 메소드를 호출하는지를 알아야 한다. 이를 위해 우선 Tag 인터페이스를 구현한 tag handler 클래스의 생존 주기(life cycle)을 보면 다음 그림과 같다.


그림 10-1 tag handler 클래스의 생존주기(life cycle)화면

첫째 단계는 tag handler 의 인스턴스가 생기는 것이다. 이 인스턴스는 리소스 풀에서 건져지며, 여기에 없으면 생성이 된다. 그 다음은 handler 의 프로퍼티(property)가 설정된다. 이 과정에서는 tag handler 의 setPageContext()메소드가 JSP Container 에 의해 호출되어 pageContext 의 객체를 참조할 수 있게 되고, setParent() 메소드가 호출되어 이 tag 를 포함하고 있는 parent tag 의 객체를 참조할 수 있게 된다.

이 다음에는 tag 에 정의되어 있는 속성값이 필요하다면 설정된다. Custom tag 의 속성은 자바빈즈 property 의 설정과 비슷하게 tag handler의 set, get 함수를 호출해서 설정된다. 이 함수들은 JSP Container 가 호

출한다.

이제, JSP Container 는 tag handler 의 doStartTag() 함수를 호출한다. 이 함수에서 custom tag 의 기능을 시작하게 되며 이 함수의 수행이 끝날 때에는 Tag.SKIP_BODY 와 Tag.EVAL_BODY_INCLUDE 라는 클래스 변수의 값 중 하나를 return 한다. 이때 SKIP_BODY 는 tag 안에 포함된 몸체 컨텐트를 무시하라는 것이고, EVAL_BODY_INCLUDE 는 이 몸체 컨텐트를 정상적으로 처리하라는 뜻이다.

doStartTag() 함수가 어떤 값을 반환하든 그 다음엔 tag handler 의 doEndTag() 함수가 호출된다. 여기서도 custom tag 에 맞는 기능을 하도록 구현할 수 있고, Tag.SKIP_PAGE 나 Tag.EVAL_PAGE 중 하나의 값을 반환하게 되어 있다. 이때 SKIP_PAGE 는 현재 페이지에 대한 처리를 멈추고 지금까지의 결과만으로 응답을 보낸다. EVAL_PAGE 는 페이지의 처리를 계속 해 나가라는 뜻이다.

마지막으로 doEndTag() 함수에서 반환되는 값에 상관없이 JSP Container 는 tag handler 의 release() 함수를 호출한다. 이 함수는 tag handler 가 리소스풀로 돌아가기 전에 자신의 상태를 초기화시키고 생성하거나 사용한 리소스를 해제하는 등의 마무리 작업을 할 수 있도록 준비한 함수이다.

IterationTag 인터페이스를 구현한 tag 의 생존주기


IterationTag 인터페이스는 JavaServer Page specification 1.2 에 새롭게 추가된 인터페이스이다. 기능상으로 보면 예전에 BodyTag 에 있던 iteraion 기능을 빼온 것이다. 대신 BodyTag 는 IterationTag 를 상속 받는 것으로 바뀌었으며 몸체(body) 처리를 위한 기능만이 남아 있게 되었다.


그림 10-2 IteraitionTag 의 생존주기 화면

TagSupport 클래스는 이 IterationTag 를 구현한 클래스이다. (JavaServer Page specification 1.1 에서 TagSupport 클래스는 Tag 인터페이스를 구현

하였다.)

doStartTag()를 수행하기 전까지는 Tag 인터페이스와 동일하다. DoStartTag()가 SKIP_BODY 를 리턴하면 몸체는 무시되며 EVAL_BODY_INCLUDE 를 리턴하면 몸체를 처리한다. 몸체 처리후 Web Container 는 IterationTag 의 함수인 doAfterBody()를 호출하는데 이 함수에서 몸체를 반복해서 처리할지 여부를 결정한다. doAfterBody()가 SKIP_BODY 를 리턴하면 몸체 처리는 여기서 멈추고 doEndTag()를 수행하게 되며 EVAL_BODY_AGAIN 을 리턴하면 몸체 처리를 다시하게 된다. doEndTag() 부터의 동작은 Tag 인터페이스와 동일하다.

BodyTag 인터페이스를 구현한 tag 의 생존주기


앞서 설명하였듯이 JavaServer Page specification 1.2 부터 BodyTag 인터페

이 스 의 iteration 기 능 은 IterationTag 로 옮 겨 졌 고 BodyTag 에 는 BodyContent 관련 부분만 남아있게 되었다.

그림 10-3 Body Tag 의 생존주기 화면

doStartTag() 를 수 행 하 기 까 지 는 Tag 인 터 페 이 스 와 동 일 하 다 . doStartTag()가 SKIP_BODY 를 리턴하면 Tag 인터페이스와 동일한 동작

을 하게 되며 EVAL_BODY_INCLUDE 를 리턴하면 IterationTag 와 동일

한 동작을 한다. doStartTag()가 EVAL_BODY_BUFFERED 를 리턴하면 BodyContent 를 위한 초기화 작업을 하게된다. setBodyContent 함수가 수 행 되 면 JSP 의 implicit 객 체 인 out 이 Web Container 에 의 해 BodyContent 객체로 잠시 바뀌게 된다 . BodyContent 는 JspWriter 의 subclass 이다. 즉, 이 태그 핸들러를 수행하는 동안에 out 으로

출력되는 모든 값은 BodyContent 에 저장되며 이 내용을 웹 브라우져로 보낼지 여부는 태그 핸들러에서 결정하게 된다.

Custom tag 의 몸체 컨텐트(BodyContent)를 처리하는 과정은 먼저 BodyContent 클래스의 인스턴스를 생성하거나 리소스풀에서 가져온 다음 tag handler 의 setBodyContent() 메소드를 통해 tag handler 에 설정이 된다. 그 다음 JSP Container 는 tag handler 의 doInitBody() 메소드를 호출하여 BodyContent 인스턴스가 설정된 후의 추가적인 초기화를 수행할 수 있도록 한다. 그 다음 몸체가 처리되고 이 결과는 BodyContent 인스턴스에 남게된다.

Note : 이때 몸체 내에서의 out 이라는 내부객체는 BodyContent 를 참조한다. 물론 몸체 내에서도 pageContext 객체의 메소드를 호출하면 output buffer 에 직접 출력을 할 수는 있지만 이렇게 tag 를 디자인하기 보다는 tag handler 에서 출력을 지원할 수 있도록 만드는게 좋다.

몸체 컨텐트를 처리하고 난 다음에는 JSP Container 가 tag handler 의 doAfterBody() 메소드를 호출한다. 이 메소드는 대부분의 경우 BodyContent 인스턴스를 사용해서 기능을 수행하게 된다. doStartTag() 와 마찬가지로 이 메소드는 Tag.SKIP_BODY 나 IterationTag. EVAL_BODY_AGAIN 을 반환하게 되어 있다. EVAL_BODY_AGAIN 값이 반환되면 몸체 처리를 다시 한번 더 하고 doAfterBody() 함수를 호출한다. 이렇게 해서 SKIP_BODY 를 반환할 때까지 필요에 따라 몸체 컨텐트를 반복적으로 수행할 수 있게 된다.

이렇게 몸체 컨텐트의 수행이 끝나면 tag handler 의 doEndTag() 메소드가 호출된다. 그 이후에는 Tag 인터페이스를 구현한 것과 동일하게 진행된다.


10.3.2.3 도우미 클래스(Helper class)

앞에서 이야기한 helper class 는 javax.servlet.jsp.tagext. TagExtraInfo 클래스의 subclass 이다. JSP Container 가 custom tag 를 가지고 있는 페이지를 컴파일할 때 이 custom tag 의 TLD 에 <tei-class>(또는 <teiclass>)가 지정되어 있는 경우에는 이 helper class 의 인스턴스를 생성하거나 리소스 풀에서 가지고 온다. 이 클래스의 역할은 두 가지로서, custom tag 에서 새로 들여오는 스크립트 변수에 대한 정보를 JSP Container 에게 제공해서 이 변수를 생성할 수 있도록 하고, 페이지 컴파일러에 의해 수행되는 문법 검사 이외에 추가적인 태그 검사를 수행하는 것이다.

Note : JavaServer Page specification 1.2 부터는 TLD 의 <variable> 태그를 사용하여 스크립트 변수를 생성할 수도 있게 하였다.

이를 위해 TagExtraInfo 클래스에는 subclass 에서 재정의할 수 있는 두 개의 메소드를 선언해 두었다. getVariableInfo() 함수는 스크립트 변수에 대한 정보를 내어 주는 메소드이고 isValid() 함수는 tag 의 문법검사를 하는 함수이다.

이들의 인자로는 TagData 클래스의 인스턴스가 들어가는데, 이 인스턴스에는 custom tag 에서 설정된 속성과 그 속성에 해당된 값이 들어있다. 이를 가지고 변수의 정보를 만들어 내거나 문법 검사를 하게 된다.

10.3.2.4 보조 클래스(Auxiliary class)

javax.servlet.jsp.tagext 패키지 내에는 JSP Container 가 TLD 파일 안의 내용을 나타낼 때 사용하는 세 개의 보조 클래스가 추가로 포함되어 있다. 이들은 TagLibraryInfo, TagInfo, TagAttributeInfo 인데, JSP Container 에서만 사용되도록 설계된 것이기 때문에 개발자들이 사용하는 경우는 드물다.

TagLibraryInfo 클래스는 태그 라이브러리에 있는 정보를 프로퍼티로 저장하고 있으며, 프로퍼티를 액세스할 수 있는 메소드를 내놓고 있다. 태그 라이브러리의 정보 중 대부분은 라이브러리에서 제공하고 있는 태그 리스트인데, 이 태그 리스트를 구성하고 있는 것이 TagInfo 클래스의 인스턴스이다. TagInfo 인스턴스에는 각각의 태그에서 지원되는 속성 집합이 담겨져 있으며, 각각의 속성을 나타내고 있는 것이 TagAttributeInfo 클래스이다.

10.3.2.5 TryCatchFinally 인터페이스

javax.servlet.jsp.tagext.TryCatchFinally 인터페이스는 JavaServer Page specification 1.2 에 새로 추가된 인터페이스이다. 태그 핸들러를 수행하다 예외가 발생한 경우 사용자가 작성한 예외 핸들러를 수행하고 싶을 때 사용한다. 이 인터페이스에는 다음과 같은 두가지 함수가 정의되어 있다.


doCatch(Throwable t) : Web Container 가 태그 핸들러가 몸체를 처

리하거나 doStartTag(), doEndTag(), doAfterBody(), doInitBody()를 수행하는 중에 Throwable 를 상위 클래스로하는 Exception 이 발

생하면 이 함수를 호출해 준다.

doFinally() : Web Container 가 doEndTag()를 수행한 후 이 함수를 호출해 준다. 태그 핸들러를 수행하는 중에 예외가 발생하여도 이 함수는 호출된다.

10.3.3 Tag 의 상호작용(Interacting)

HTML 태그 중에는 태그가 위치한 환경(context)에 따라 동작이 달리지는 것들이 몇 개 있다. 가령 <TD> tag 는 <TR> tag 의 몸체에서만 의미를 가지며 <TR> tag 는 <TABLE> tag 의 몸체 안에서만 나타나야 한다.

다른 JSP tag 와 마찬가지로 custom tag 에서도 이런 상호작용이 가능하도록 구현할 수 있다. JSP 에서 제공하고 있는 방법은 다음과 같다.

10.3.3.1 내부 객체의 속성(Attribute)을 통한 상호작용

Tag 끼리 상호작용을 할 수 있는 가장 간단한 매커니즘은 페이지의 내부 객체에 저장될 수 있는 속성을 통해서이다. Tag handler 는 pageContext 인스턴스를 통해 속성을 지정할 수 있는 네가지의 표준 페이지 객체(Application, session, request, pageContext)를 얻어낼 수 있다. Custom tag 에 의해 속성에 저장될 데이터의 scope 와 어떤 페이지 객체의 scope 가 일치하기만 하면 이를 통해 tag 들끼리 데이터를 주고 받을 수 있다. 하지만, 이를 사용하기 위해서는 custom tag 들이 쓰이는 페이지에 중복되는 이름의 속성이 내부 객체들 안에 존재하지 않아야 한다. 또한 scope 가 맞지 않을 때에도 사용할 수가 없는 방법이다.


10.3.3.2 Custom tag 의 계층 구조를 이용한 상호작용

JSP Container 는 tag handler 의 동작과정에서 처음 호출되는 함수 중 하나인 setParent() 메소드를 사용하여 tag 가 나타나는 주변 환경을 부모/자식의 계층 구조로 계속 유지한다. 이때 어떤 custom tag 가 다른 custom tag 의 몸체에 들어 있을 때 바깥쪽 tag 는 안쪽 tag 의 부모가 된다. JSP Container 가 어떤 tag 의 부모를 setParent() 메소드를 통해 지정한 후에는 그 tag 는 getParent() 메소드를 통해 부모로 지정된 태그의 태그 핸들러를 가져올 수 있다.

Note : 이때 tag 의 계층 구조는 상향식(bottom-up manner)로 되어 있다. 즉, 어떤 tag 의 자식은 어떤 tag 들이 있는지 알 수 없다.

이를 이용하면 부모 tag 의 객체에 대한 참조자(reference)를 얻어서 부모의 메소드를 호출할 수 있다. 하지만 tag 는 아무렇게나 중첩

가능하기 때문에 부모 태그 핸들러의 타입을 예측하기는 힘들다. 따라서 올바른 부모의 handler class 타입으로 캐스팅해서 사용하기가 힘들게 된다.

이를 해결하기 위한 방법은 TagSupport 클래스에서 정의된 static 메소드인 findAncestorWithClass() 이다. 이 메소드는 계층 구조를 탐색하여 지정된 class 타입의 가장 가까운 조상(ancestor)인 tag handler 를 돌려준다. 이 메소드의 형식은 다음과 같다.

static Tag TagSupport.findAncestorWithClass(Tag from, Class

class)

10.3.4 간단한 Custom tag 만들기

지금까지 살펴본 custom tag 의 기능을 이용해 간단한 custom tag 를 구현해 보기로 하겠다. 여기서 만들 custom tag 는 일반 text 를 HTML 문자로 인코딩해주는 tag 이다.


10.3.4.1 HTML 인코딩

브라우저는 HTML 컨텐트를 읽어서 HTML 태그 같은 특수한 문자들을 해석해서 출력을 한다. 이때 <, >, &, “, <ENTER>, <TAB> 같은 문자들을 특수한 용도에 쓰거나 무시해 버리는데, 이런 문자들을 제대로 표현하기 위해서는 HTML 형식으로 인코딩하는 과정이 필요하다. 즉, <는 &lt, >는 &gt 같이 바꾸어 주는 것이다. 이를 위한 custom tag 소스는 다음과 같다.

package jeus.example.taglib;

import javax.servlet.jsp.PageContext;

import javax.servlet.jsp.tagext.*;

import javax.servlet.jsp.*;

import java.io.IOException;

import java.util.Hashtable;

public class EncodeHtmlTag extends BodyTagSupport

{

static private Hashtable translations = makeTranslationTable();

static private Hashtable makeTranslationTable()

{


Hashtable table = new Hashtable();

table.put(new Character('<'), "<");

table.put(new Character('>'), ">");

table.put(new Character('&'), "&");

table.put(new Character('"'), """);

table.put(new Character('\n'), "<br>");

table.put(new Character('\t'), " ");

return table;

}

static public String getTranslation (char c)

{

return (String) translations.get(new Character(c));

}

public int doAfterBody() throws JspException

{

BodyContent body = getBodyContent();

String orig = body.getString();

body.clearBody();

int length = orig.length();

StringBuffer result = new StringBuffer(Math.round(length

* 1.1f));

for (int i = 0; i < length; i++)

{

char c = orig.charAt(i);

String translation = getTranslation(c);

if (translation == null)

{

result.append(c);

}

else

{

result.append(translation);

}

}

try

{

getPreviousOut().print(result.toString());

}

catch (IOException e)

{

throw new JspTagException("unexpected IO error");

}

return SKIP_BODY;

}

}

makeTranslationTable() 메소드에서는 특수 문자와 HTML entity 와의 매핑을 해시테이블에 저장해 두어서 변환할 때 참고할 수 있도록 하였다. 그리고 이 encodeHTML tag 는 컨텐트를 조작하는 태그이기 때문에 BodyTagSupprot 클래스를 이용해서 tag handler 를 구현하였다. 그리고 doAfterBody() 메소드를 재정의해서 태그 안에 둘러 쌓인 text 를 HTML 인코딩 후에 출력으로 보내게 된다. 이 tag 를 사용하는 JSP 예제 문서는 다음과 같다.

<%@ taglib uri=”/jeus” prefix=”jeus” %>

<html>

<body>

sample tag<br>

<tt><jeus:encodeHTML>if ( (x < 24) && (x > 0) ) {

fact(x);

}</jeus:encodeHTML>

</body>

</html>

만약 custom tag 를 만들지 않고 이를 수행하려면 매번 수작업으로 인코딩을 해서 HTML 문서를 만들거나 인코딩을 해주는 자바 함수를 JSP 문서 내에 포함시켜야 할 것이다. 또한 이런 용도에서는 자바빈즈를 사용하는 것보다 custom tag 를 만드는 것이 더욱 자연스러울 것이다.


10.4 에러 처리

WebtoB Servlet Engine 에서의 에러는 세가지 종류가 있다. JSP 문서를 파싱해서(parsing) servlet source code 로 만들 때 나오는 JSP 파싱 에러, servlet code 를 javac 를 이용해서 컴파일할 때에 나오는 컴파일 에러,

컴파일 후에 실행중에 발생하는 런타임 에러(run-time error)가 그것이다. 이 각각에 대한 해결 방법을 살펴 보기로 하자.

10.4.1 파싱 에러(JSP parsing error)

JSP 파싱 에러는 JSP 문서를 servlet code 로 변환시켜줄 때 JSP 문법에 맞지 않는 경우에 발생한다. 이는 대부분 오타일 경우가 많으므로 쉽게 수정할 수 있다.

10.4.2 컴파일 에러(Compilation errors)

JSP 컴파일은 WebtoB Servlet Engine 내의 JSP 컴파일러에서 자동으로 실행해 주는 것이다. 즉, 새로운 요청이 들어오거나 페이지가 바뀔 때마다 실행이 되며 만약 컴파일 에러가 발생하면 브라우저에 “페이지 요청을 마칠 수 없다.”는 에러 메시지가 뜨게 되는 것이다. 컴파일 에러의 요인은 자바빈즈 태그에 넣는 클래스나 프로퍼티 이름을 잘못 썼다든지 하는 단순한 실수일 수도 있고, 논리상의 에러나 문법 에러 같은 조금 더 복잡한 문제일 수도 있다.

에러 메시지는 javac 에서 보여주는 것이기 때문에 java 에 지식이 있어야만 어떤 에러인지를 알 수 있다. 그리고 이 에러는 JSP 문서를 servlet 소스 코드로 바꾼 파일을 컴파일할 때 나는 것이기 때문에 JSP 문서 보다는 이 servlet 소스 코드를 보는 것이 에러를 잡는데 도움을 준다. 이 소스 코드는 해당 Application 디렉토리의 %W2B_SERVLETHOME% 안의 jspwork 라는 디렉토리 내에 존재한다. 해당 파일 이름은 에러 메시지를 출력할 때 나올 것이다.


10.4.3 런타임 에러(Run-time errors)

컴파일 에러는 JSP 페이지가 새로 추가되거나 원래 페이지가 수정된 후에만 생기며 이를 고치기 전에는 페이지를 볼 수 없지만, 런타임 에러는 JSP 페이지가 실행되는 도중에 생기는 에러로 예기치 못한 상황이 생기거나 프로그램 로직 자체의 문제에 의해 생기게 된다.

이는 컴파일 에러와 비슷하게 웹 브라우저에 나타나는 에러 메시지로 확인이 가능하다. 에러 메시지 뒤에는 JSP Container 의 설정 사항에 따라 스택 추적 정보(stack trace)가 이어진다. 이는 프로그램의 실행 순서를 거슬러 올라가면서 현재의 에러를 나게 한 메소드 호출문까지 출력하는 것이다. 이 정보를 보면 에러 상태가 발생할 때 JSP Container 가 어떤 동작을 했는지를 알 수 있다.


런타임 에러는 원인을 찾기가 힘들다. 이 원인 중 하나가 될 수 있는 것은 서버나 네트워크 설정이 바뀌었을 때이다. 네트워크 액세스에 에러가 생겼다든지, 어떤 컴퓨터가 일시적으로 오프라인 상태가 되었다든지, 데이터 소스가 변경되었다든지 할 때 에러가 생길 확률이 높다. 어떤 스택 추적 정보를 통해 이들 리소스를 액세스 하다가 에러가 발생한 것을 알아냈다면 의문이 가는 리소스의 상태와 구성 정보를 점검하는 것이 문제 해결의 첫단계이다.

이런 것에 아무런 문제가 없다면 다음에는 프로그램을 살펴 보아야 한다. 프로그램을 작성하면서 고려하지 않았던 자주 발생하지 않는 주

변 요인 때문에 런타임 에러가 발생할 수 있다.

webtob web container guide - tmaxsoftkr.tmaxsoft.com/img/service/pdf/manual/webtob_3.1_web...구동...

Documents