3. 웹 어플리케이션과 JSP 및 Servlet의 이해

이번 장은 앞으로 본 책을 학습하는데 있어서

매우 중요한 장이다. 본 장에서는 웹 어플리케이션에 대한

전반적인 이해를 목적으로 웹 어플리케이션의

개념과 구조에 대해 설명한다.

한편, JSP의 전체 처리 과정 및 Servlet과 JSP의 관계

에 대해서도 설명한다. 한편, Servlet의 원리

및 첫 번재 Servlet 프로그램을 작성해 본다.

3.1 웹 어플리케이션 (Web Application) 개념 및 폴더 구조

3.2 JSP의 처리 과정 및 Servlet과의 관계

3.3 Servlet의 이해

3.4 첫 번째 Servlet 프로그램 : helloworld.servlet

3.1 웹 어플리케이션 (Web Application) 개념 및 폴더 구조

3.1.1 웹 어플리케이션의 개념

데스크탑에서 일반적으로 많이 사용하는 프로그램은 독립 어플리케이션 (Stand-alone

Application)이라고 지칭한다. 독립 어플리케이션의 예로는 글, MS 워드, MS 엑셀, MS

파워포인트 등이 있다. 이러한 독립 어플리케이션은 이름 그대로 데스크탑 상에서 독립적으로

실행되어 수행되는 프로그램을 의미한다.

반면에 웹 어플리케이션 (Web Application)은 독립적으로 수행되는 것이 아니라 반드시 웹

브라우저 상에서 수행되는 어플리케이션을 의미한다. 즉, HTTP 프로토콜 및 HTML 문서를

근간으로 만들어지는 어플리케이션이다. 본 교재의 목적은 이러한 웹 어플리케이션을 효과적

으로 만들기 위한 JSP/Servlet 동적 웹 페이지 작성법을 배우는 것이다. 웹 어플리케이션이

웹 브라우저 상에서 수행되기 때문에 독립 어플리케이션에 비하여 사용자 인터페이스 (User

Interface)나 정보의 표현력에 한계가 있긴 하지만 최근 웹 2.0 추세에 맞추어 그 둘 사이의

차이는 좁혀지고 있는 추세이다. 특히, 웹 기술 및 웹 브라우저의 발달로 인하여 새로운 유저

인터페이스와 사용자 환경을 갖추고 사용자의 만족도와 생산성을 높여주는 풍부하고 매력적

인 경험을 제공하는 RIA (Rich Internet Application) 기술1)이 최근에 각광을 받고 있다.

웹 어플리케이션(웹 기반 응용 프로그램)이 Tomcat 안에서 구현될 때의 규칙은 [그림 3-1]에

서처럼 Tomcat 설치 폴더 하위의 webapps 폴더와 관련이 깊다.

[그림 3-1] 웹 어플리케이션과 webapps 내의 폴더

1) RIA 기술과 관련이 깊은 것은 클라이언트 측 스크립트 언어인 Javascript와 관련이 깊다. 한편,

조금 더 동적이고 액티브한 화면 구성이 가능한 Adobe 사의 Flex와 Microsoft의 Siverlight 및

Sun사의 Java 기반인 JavaFX 기술이 RIA 기술을 실현하기 위한 도구이다.

jspbook 웹 어플리케이션

(첫 번째 웹 어플리케이션)

2장의 helloworld.jsp를 작성하고 실행하기 위하여 만든 jspbook이라는 폴더는 webapps 폴

더의 하위에 위치하며 이 폴더가 바로 jspbook 웹 어플리케이션 루트(Root)가 된다. 만약 새

로운 웹 어플리케이션을 하나 더 만들고자 한다면 역시 [그림 3-2]처럼 webapps 폴더 하위

에 새로운 폴더를 만들면서 이름을 정하면 된다.

jspbook 웹 어플리케이션

(첫 번째 웹 어플리케이션)

[그림 3-2] webapps 내의 두 번째 웹 어플리케이션 생성

한편 JSP/Servlet 스펙에서는 이러한 독립된 하나의 웹 어플리케이션에 대하여 Context 라

는 용어를 붙이기도 한다. 즉, 다음과 같은 관계가 성립한다.

webapps 폴더 내에 새로운 폴더 생성

= 새로운 웹 어플리케이션 생성

= 새로운 Context 생성

즉, 각각의 웹 어플리케이션은 오직 하나의 ServletContext와 매핑이 된다. 즉, 서로 다른 두

개의 웹 어플리케이션은 독립적인 ServletContext 객체와 매핑되어 각자 독립적인 공간에 자

신만의 정보를 관리할 수 있다. 또한 ServletContext는 하나의 웹 어플리케이션 내에 여러

JSP 페이지와 Servlet 들이 공동으로 활용할 수 있는 저장소로서 이용될 수 있다.

3.1.2 웹 어플리케이션 폴더와 URL간의 매핑

위와 같이 webapps 폴더 밑에 새로운 폴더를 생성하여 웹 케이션을 만들면 웹 브라우저로

접근할 수 있는 웹 어플리케이션 URL도 동시에 생성이 된다. 예를 들어 [그림 3-2]처럼

webapps 내에 jspbook과 myapp 웹 케이션을 생성하게 되면 아래와 같은 URL이 생성된다.

myapp 웹 어플리케이션

(두 번째 웹 어플리케이션)

h ttp :/ / lo c a lh o s t :8 0 8 0 / jsp b o o k

h ttp :/ / lo c a lh o s t :8 0 8 0 /m yap p

localhost:8080은 본인이 사용하는 컴퓨터 내에서 Tomcat 및 웹 케이션을 접근할 때 사용하

는 것이며 만약 외부의 웹 서버에 웹 케이션을 업로드하여 이용하게 되면 localhost:8080은

그 웹 서버의 URL로 대치될 것이다. 본 교재에서 작성된 모든 예제들은 jspbook 웹 케이션

에 위치하게 되며 2장에서 설명한 것처럼 jspbook은 저자가 운영하는 웹 서버인

www.thinkonweb.com서버로 업로드가 되어 있기 때문에 http://localhost:8080/jspbook은

다음과 같은 URL로도 접근이 가능하다.

h ttp :/ /w w w .th in k o n w e b .co m / jsp b o o k

[그림 3-3]은 지금까지 설명한 웹 어플리케이션 폴더와 URL 관계에 대한 그림이다.

[그림 3-3] 웹 어플리케이션 폴더와 URL 관계

웹 브라우저에서 웹 어플리케이션 지정없이 http://localhost:8080으로 URL 요청을 한다면

기본적으로 webapps 폴더 밑의 ROOT 폴더로 접근하게 된다. 예를 들어 http://localhost:80

80/hello.jsp 라는 URL 요청을 한다면 이 파일은 webapps/ROOT/hello.jsp를 접근하게 된

다.

웹 어플리케이션 폴더는 Context 하나와 매핑된다고 하였다. 이와 연관되어서 다음 두 개의

메소드를 기억하자.

re q u e s t .g e tC o n te x tP a th ()

a p p lic a t io n .g e tR e a lP a th (" / " )

request 객체의 getContextPath() 메소드는 JSP 페이지 및 Servlet 수행 시에 웹 케이션의

경로를 얻어오기 위해 사용한다. 한편, application 객체의 getRealPath("/") 메소드는 하드디

스크상의 실제 경로를 얻어오기 위해 사용한다. 다음은 이에 관한 예제이다.

0 10 20 30 40 50 60 70 8

< % @ p a g e co n te n tT yp e = " te x t/h tm l; c h a rse t= u tf- 8 " % >< h tm l>< h e ad > < t it le > co n te x t의 경 로 < /t it le > < /h e ad >< b o d y>현 재 수 행 JS P 의 co n te x t (웹 케 이 션 ) 경 로 : < % = re q u e s t .g e tC o n te x tP a th () % > < b r/>현 재 수 행 JS P 의 실 제 경 로 : < % = ap p lic a t io n .g e tR e a lP a th (" / " ) % >< /b o d y>< /h tm l>

[예제 3.1] jspbook\ch03\path.jsp

[그림 3-4] path.jsp 수행 모습

만약 [그림 3-5]과 같이 testjsp.jsp 파일을 jspbook/test 폴더 밑에 두었다면

[그림 3-5] testjsp.jsp 파일의 위치

이 파일을 웹 브라우저로 접근하기 위한 URL은 다음과 같다.

h ttp :/ / lo c a lh o s t :8 0 8 0 / jsp b o o k / te s t/ te s t js p .js p

만약 apple.bmp 라는 이미지 파일이 jspbook/images에 있다면 apple.bmp를 웹 브라우저로

접근하기 위한 URL은 다음과 같다.

h ttp :/ / lo c a lh o s t :8 0 8 0 / jsp b o o k / im ag e s /a p p le .b m p

3.1.3 웹 케이션의 폴더 구조

[그림 3-6] 웹 케이션의 폴더 구조

웹 케이션을 새로 생성하기 위하여 webapps 밑에 jspbook 처럼 새로운 폴더를 만들면 그

새로운 폴더 내에 [그림 3-6]과 같은 파일 및 폴더 구조를 일반적으로 개발자가 직접 만들어

야할 필요가 있다. web.xml 파일을 포함하여 WEB-INF 폴더와 그 하위 폴더들은 간단한 웹

어플리케이션의 경우 생략이 가능하다. 즉, 다음과 같이 정리할 수 있다.

일반적인 웹 어플리케이션의 구조에는 반드시 WEB-INF 폴더와

web.xml 파일이 그 안에 존재한다. 하지만 간단한 웹 어플리케이션인

경우에는 WEB-INF 폴더 및 web.xml 생략이 가능하다.

그림 3-4에 소개된 파일 및 폴더들의 이름은 images를 제외하고는 JSP/Servlet 컨테이너인

Tomcat과 약속이 되어 있는 것들로, 대소문자까지 철저하게 지켜서 파일 및 폴더를 생성해야

한다. 다음 표 1은 이들에 대한 설명이다.

폴더 또는 파일 설명

\웹 어플리케이션 폴더\

웹 어플리케이션의 루트 (ROOT) 폴더이

다. 웹 어플리케이션과 관련된 모든

HTML, JSP, Servlet, Java 클래스, 이미지

파일들이 이 폴더 밑에 저장된다.

\웹 어플리케이션 폴더\WEB-INF

웹 어플리케이션의 환경 설정 및 관련

Utility 클래스와 Java Beans 및 라이브러

리들을 위치시키는 폴더이다. 이 폴더에 웹

어플리케이션 배치 정의자인 web.xml가 위

치한다. 이곳에 위치한 파일은 클리이언트

가 직접적으로 접근할 수 없다.

\웹 어플리케이션 폴더\WEB-INF\web.xml웹 어플리케이션 배치 정의자 역할을 하는

파일이다.

\웹 어플리케이션 폴더\WEB-INF\classesServlet 및 Java Beans 클래스를 포함한

여러 클래스들이 위치하는 폴더이다.

\웹 어플리케이션 폴더\WEB-INF\lib

라이브러리 역할을 하는 jar 파일이 위치하

는 폴더이다. JDBC 드라이버나 태그 라이

브러리를 구성하는 jar 파일이 여기 위치한

다.

\웹 어플리케이션 폴더\WEB-INF\tld

태그 라이브러리 관련 설정 파일들이 위치

한다. 태그 라이브러리는 19장에서 학습한

다.

\웹 어플리케이션 폴더\images

images 라는 이름 자체는 JSP/Servlet 컨

테이너와 약속이 된 것은 아니지만 보통

이 폴더 내에 웹 어플리케이션과 관련된

모든 이미지 파일을 위치시킨다.

표 1 웹 어플리케이션의 폴더 구조

영화제작으로 비교하면 영화를 만드는 데에 있어서 뒤에서 일하는 스텝들과 같은 역할을 하는

파일 및 자원들은 모두 WEB-INF 폴더 내에 두어야 하며 WEB-INF 폴더 내의 파일 및 자

원들은 웹 브라우저인 클라이언트에서 절대 접근할 수 없다. 특히, web.xml은 웹 어플리케이

션 배치 정의자이며 웹 어플리케이션의 환경 설정, Servlet 정의, Servlet 매핑, Servlet 파라

미터 설정, 에러 페이지 정의 등과 같은 역할을 수행한다. 이러한 여러 기능을 하는 web.xml

은 매우 중요하며 추후 교재 내에서 관련 내용을 배울 때 web.xml에 이러한 기능을 어떻게

표현하는지 알아볼 것이다.

3.2 JSP의 처리 과정 및 Servlet과의 관계

3.2.1 JSP 파일의 Servlet 파일로의 자동 변환

2장에서 helloworld.jsp를 작성하여 실행하는 과정을 보면 매우 간단하게 보이지만 사실 JSP

는 JSP/Servlet 컨테이너인 Tomcat에서 다소 복잡한 과정을 거쳐서 수행된다. 가장 먼저 이

해해야 하는 사항은 우선 2장에서 만든 helloworld.jsp에 해당하는 Java 소스 파일이 존재한

다는 사실이다. 2장에서 helloworld.jsp는 아래와 같은 경로 아래에 파일을 만들어서 웹브라

우저로 그 결과를 확인해 보았다.

T o m ca t 설 치 폴 더 \ w eb a p p s\ jsp b o o k\ ch 0 2 \ h e llo w o r ld .jsp

위 JSP 파일을 웹 브라우저로 반드시 실제로 실행시킨 다음 아래 경로 및 파일을 그림 3-5처

럼 탐색기에서 확인해 보자.

T o m ca t 설 치 폴 더 \ w o rk\ C a ta lin a\ lo c a lh o s t\ js p b o o k\ o rg \ ap a ch e \ jsp\ ch 0 2 \ h e llo w o r ld _ jsp .ja v a

T o m ca t 설 치 폴 더 \ w o rk\ C a ta lin a\ lo c a lh o s t\ js p b o o k\ o rg \ ap a ch e \ jsp\ ch 0 2 \ h e llo w o r ld _ jsp .c la s s

[그림 3-7] helloworld.jsp가 Servlet으로 변환된 Java 소스 및

클래스 파일

Tomcat이 설치된 폴더의 work 폴더는 일종의 임시 파일들이 저장되는 곳인데 대표적으로

JSP 파일과 대응되는 Servlet의 Java 소스파일과 클래스 파일들이 저장된다. 즉, JSP 파일은

실행이 될 때 일단 Servlet인 Java 소스파일로 변환되고 다시 클래스 파일로 컴파일된 후 이

클래스 파일이 JSP/Servlet 컨테이너인 Tomcat 내에서 실행되어 그 결과가 최종적으로 웹

브라우저로 전달되는 것이다. 정리하면 다음 [그림 3-8]과 같다.

[그림 3-8] JSP 파일의 변환과 컴파일

[그림 3-8]에서 보이는 것처럼 JSP 파일의 변환 과정과 Java 파일의 컴파일 과정은 JSP의

태생적 원리가 무엇인지 알려준다. 원래 Java를 통한 동적 웹 페이지 방법이 처음 세상에 소

개될 때에는 Servlet 만 소개되었으며 JSP는 Servlet이 알려지고 1～2년 이후에 소개가 되었

다. Servlet은 Java를 기반으로 동적 웹 페이지를 구성하는 아주 훌륭한 도구였지만 다소 사

용하기 불편하고 이것저것 학습해야 할 분량도 많았다. 그래서 스크립트 언어로서의 JSP를

세상에 소개한 것이다. Java의 정확한 문법을 몰라도 고급 레벨이 아닌 중소형 규모의 웹 사

이트는 JSP 스크립트 언어로 작성이 가능하게 되었다. 하지만, [그림 3-8] 에서 보이는 것처

럼 결국 JSP도 Servlet이다. 즉, 다음과 같은 사항을 기억하자.

개발자에게 코딩하기 복잡한 Servlet 대신에 스크립트 언어인 JSP로

작성하게 하고 JSP/Servlet 컨테이너인 Tomcat이 내부에서 JSP 파

일을 Servlet으로 변환 및 컴파일하여 클래스 파일을 메모리에 적재한

후 실행하여 응답한다.

이와 같은 변환 및 컴파일 작업은 동적 웹 사이트의 획기적으로 개발시간 단축 효과를 이끌어

낸다.

여기서 잠깐 JSP 파일이 변환이 된 Java 파일, 즉 helloworld_jsp.java를 AcroEdit 으로 열

어 확인해 보자. 다음의 내용이 보일 것이다.

p a ck ag e o rg .a p a c h e .jsp .c h 0 2 ;

im p o rt ja v a x .s e rv le t .* ;im p o rt ja v a x .s e rv le t .h t tp .* ;im p o rt ja v a x .s e rv le t .js p .* ;

p u b lic f in a l c la s s h e llo w o r ld _ js p e x te n d s o rg .a p a ch e .ja sp e r .ru n t im e .H ttp Js p B a s e im p lem e n ts o rg .a p a c h e .ja s p e r .ru n t im e .J sp S o u rce D e p en d e n t {

.. . 중 간 생 략 ...

p u b lic vo id _ js p In it () {

.. . 중 간 생 략 ... }

p u b lic vo id _ js p D e s tro y () { }

p u b lic vo id _ js p S e rv ic e (H ttp S e rv le tR e q u e s t re q u e s t , H ttp S e rv le tR e sp o n se re sp o n se ) th ro w s ja v a .io .IO E x ce p t io n , S e rv le tE x ce p t io n {

.. . 중 간 생 략 ...

t ry { . . . 중 간 생 략 ...

o u t .w r ite ("\ r\ n " ) ; o u t .w r ite ("< h tm l> \ r\ n " ); o u t .w r ite ("< b o d y> \ r\ n " ); o u t .p r in t ln ("H e llo W o r ld !" ) ; o u t .w r ite (" < b r/> \ r\ n " ); o u t .p r in t ln ("안 녕 하 세 요 ." ); o u t .w r ite ("\ r\ n " ) ; o u t .w r ite ("< /b o d y> \ r\ n " ) ; o u t .w r ite ("< /h tm l> \ r\ n " ) ; } c a tch (T h ro w a b le t ) {

. .. 중 간 생 략 ...

} f in a lly { _ jsp x F a c to ry .re le a se P ag e C o n te x t (_ jsp x _p ag e _c o n te x t ) ; } }}

JSP 파일에 작성

한 내용이 이 곳

에 존재함.

위 코드를 보면 클래스명이 Java 파일명과 같은 helloworld_jsp 이며 JSP 파일에 적어 놓은

내용이 _jspService 멤버 메소드에 고스란히 보이는 것을 알 수 있다. 한편, out 객체의 write

메소드와 println 메소드가 적절히 그러한 JSP 파일의 내용을 출력시켜주는 역할을 하는 것도

알 수 있다. out 객체 등은 추후에 더 자세히 살펴 볼 것이다. 여기서는 단지 JSP 파일에 적어

놓은 내용은 Servlet의 Java 파일에 담겨진다는 사실 자체를 이해하면 된다.

3.2.2 JSP 파일 재요청시의 동작 과정

그렇다면 웹 브라우저에서 JSP 파일을 요청하면 매번 그림 3-6과 같이 JSP 파일을 Java 파

일로 변환하고 다시 class로 컴파일하는 과정을 거치게 될까? 사실 JSP 파일을 Java 파일로

변환하는 과정도 꽤 시간이 소요되는 과정이며 컴파일하는 과정 또한 상당한 시간이 요구된

다. 매번 이러한 변환과 컴파일을 거치면 웹 브라우저에서 JSP 파일을 요청한 후 응답을 받기

까지 매우 오랜 시간을 사용자가 기다려야 하는 단점이 있다. 이러한 단점을 JSP/Servlet 컨

테이너가 그대로 두지 않았을 것이다. 사실 [그림 3-8]과 같은 변환 및 컴파일 과정은 해당

JSP를 웹 브라우저에서 맨 처음 요청했을 때에만 이루어지는 과정이다. 만약 한번이라도 요

청했던 JSP 파일을 다시 임의의 사용자가 재요청하게 되면 JSP/Servlet 컨테이너인 Tomcat

은 [그림 3-9]과 같은 과정을 거친다.

[그림 3-9] JSP 재요청시의 실행 모습

[그림 3-9]에서 보여주듯이 한번이라도 요청을 했던 JSP의 재요청시에는 요청된 JSP 파일에

해당하는 클래스파일이 메모리에 적재되어 있는지만 확인하고 적재된 클래스를 바로 실행하

여 응답을 받아오게 된다. 여기서 중요한 사항은 A 사용자가 처음 어떠한 JSP를 요청하여 한

번이라도 응답을 받게 되면 해당 클래스가 메모리에 적재되는데, 이때 B 사용자가 같은 JSP

를 요청한 경우 메모리에 적재된 그 클래스에서 바로 응답을 줄 수 있다는 점이다. 그래서,

JSP로 작성된 웹 페이지의 대부분의 응답은 하드디스크에 대한 접근 없이 바로 메모리에서

응답을 주기 때문에 대체로 평균 응답 시간이 매우 짧다.

3.2.3 JSP 파일 수정 후 같은 JSP 재요청시의 동작 과정

한편, JSP의 다른 장점 중의 하나는 개발자가 일일이 소스 코드를 변경할 때 마다 컴파일해야

하는 불편 없이 JSP에서 약간의 수정을 하면 Tomcat이 알아서 변환 및 컴파일을 새롭게 해

준다는 점이다. JSP가 스크립트 언어이기 때문에 다른 여타의 스크립트 언어가 지닌 이러한

장점은 아마도 새롭게 느껴지지는 않을 것이다. 하지만, 아래 [그림 3-10]의 JSP/Servlet 컨

테이너에서 각 파일들을 수정하는 시각에 대한 예를 보면서 이러한 자동 변환 및 컴파일 과정

을 잘 이해해 보자.

[그림 3-10] JSP 파일 수정이후 처리 과정 이해

[그림 3-10]에서 소개된 각 단계에 대한 설명은 다음과 같다.

[1] helloworld.jsp 파일에 대한 작성을 완료한다.

[2] 처음으로 웹 브라우저에서 helloworld.jsp를 접근하여 실행한다. 이 때 Servlet 코드인

Java 파일과 클래스 파일이 차례대로 만들어진다. 그래서, 시간순서로 따지면 "JSP 파일

⇒ Java 파일 ⇒ 클래스 파일 "순서가 되어 클래스 파일이 가장 최신의 파일이 된다.

[3] JSP 파일을 일부 수정한다. Servlet 코드인 Java 파일과 클래스 파일은 아직까지 그 수

정이 반영되지 않는다. 그래서, 최신의 JSP 파일만 파일 수정 시간이 바뀐다.

[4] 웹 브라우저에서 helloworld.jsp를 다시 요청한다. 이 때 JSP/Servlet 컨테이너인

Tomcat은 반드시 helloworld.jsp 파일과 대응되는 클래스 파일이 있는지 살펴본 후

JSP 파일이 최신인지 클래스 파일이 최신인지 검사한다. [3]번 단계에서 JSP 파일을 수

정했기 때문에 JSP 파일이 더 최신 날짜/시각을 가진다. 그러므로 JSP 파일의 Java 파

일 변환 및 클래스 파일로의 컴파일을 다시 수행한다.

[5] 결과적으로 다시 각 파일의 시간순서는 "JSP 파일 ⇒ Java 파일 ⇒ 클래스 파일 "가 되

어 클래스 파일이 가장 최신의 파일이 된다.

위에서 설명한 과정은 JSP가 처리되는 전체 과정을 이해하는 데 있어서 중요한 사항이다. 즉,

JSP에 대한 요청을 받은 JSP/Servlet 컨테이너는 이미 해당 클래스 파일이 메모리에 적재되

어 있어도 그 클래스 파일이 JSP 파일보다 이후에 만들어진 최신 클래스 파일인지 반드시 확

인하여 수행 결과를 웹 브라우저로 보내준다는 사실에 주목하자.

3.2.4 종합적인 JSP 파일 처리 과정

[그림 3-11]는 이상의 JSP 처리 과정을 전체적으로 종합하여 보여주는 그림이다.

[그림 3-11] 전체적인 JSP 처리 과정

[그림 3-11]에서 마지막 부분에서 메모리에 적재된 Servlet 클래스를 실행하는 단계에서 만약

데이터베이스 처리 부분이 있다면 데이터베이스에 접근하여 데이터를 가져오는 과정이 추가

된다. 요즘에 구축되는 웹사이트들은 대부분 데이터베이스를 거치기 때문에 전체 JSP 처리

과정의 일부로 넣어 함께 이해하는 것이 좋다.

3.3 Servlet의 이해

3.3.1 Servlet의 생성 배경 및 장점

Servlet은 Java 플랫폼에서 컴포넌트를 기반으로 한 웹 어플리케이션을 개발할 때 활용하는

중요 기술이다. 무엇보다 Servlet이 중요한 이유는 JSP가 바로 Servlet을 기반으로 한 기술

이기 때문이다. 따라서 JSP를 보다 효율적으로 사용하려면 Servlet 개념 및 구조와 관련 기술

을 이해하는 것이 중요하다. 특히 JSP 모델-2와 같이 향상된 웹 어플리케이션 개발 패턴을

활용할 때는 Servlet에 대한 기본적인 개념을 숙지하고 있어야 한다. JSP 모델-2는 14장에서

다룰 예정이다.

또한 최근에는 Struts나 Spring과 같은 오픈소스 프레임워크가 주목받고 있으며, 이들 프레

임워크의 많은 부분이 Servlet으로 되어 있기 때문에 고급 웹 어플리케이션 개발을 위해서는

Servlet을 잘 배워두는 것이 좋다.

JSP가 등장한 가장 큰 이유는 Servlet이 가진 HTML 표현상의 불편함을 해결하기 위함이었

다. Servlet은 프로그램 내에서 HTML을 처리하기 때문에 간단한 표현을 변경할 때에도 컴

파일을 다시 해야 하는 문제가 있다. 이러한 이유로 프로그래밍에 익숙하지 않은 웹 디자이너

는 마음대로 화면을 수정할 수 없으며, 복잡한 HTML 소스를 프로그래머가 Servlet 클래스

내에서 관리해야 하는 문제가 따르게 된다. 이처럼 비즈니스 로직과 프리젠테이션 로직이 하

나의 Servlet 소스에 있다는 점은 개발과 관리 면에서 여러 가지 문제점을 안겨주었다.

이러한 문제점 해결을 위해 비즈니스 로직과 프리젠테이션 로직을 분리하기 위한 노력이 있었

고 이 때문에 JSP가 탄생하게 되었다. 물론, JSP 이전에는 별도로 만들어진 템플릿 엔진 등

을 이용하여 이러한 문제를 부분적으로 해결할 수 있었지만 사용 방법의 복잡성으로 인해 일

부에서만 활용되었다.

JSP는 처음 등장할 당시에는 Servlet을 대체하는 기술로서 주목받았다. 하지만 JSP는 실제

Servlet을 대체하는 기술이 아니라 상호보완적인 기술이다. 이 또한 JSP 모델-2를 학습하면

확실하게 이해를 할 수 있을 것이다.

Servlet을 모르면 JSP를 배울 수 없는가? 그렇지는 않다. Servlet을 모른다고 해서 JSP를 배

울 수 없는 것은 아니다. 하지만 JSP의 내부구조는 Servlet이므로 알아두면 도움이 된다.

Servlet을 잘 하려면 어떤 공부를 해야 할까? JSP도 마찬가지이지만 Servlet은 기본적으로

Java 언어 기반이므로 Java 언어에 대한 프로그램 실력을 쌓는 것이 좋다. 입출력, 네트워킹,

쓰레드, JDBC 등 다양한 Java API에 대한 경험을 해야 한다.

[그림 3-12] Servlet과 JSP의 기술 변천

웹 어플리케이션을 개발할 때 Servlet을 사용하면 좋은 점을 정리하면 다음과 같다.

[Servlet의 장점]

∙Java를 기반으로 하므로 Java API를 모두 사용할 수 있다.

∙쓰레드를 기반으로 하므로 웹 어플리케이션 서버 자원을 효율적으로

활용할 수 있다.

∙웹 어플리케이션에서 효율적인 자료 공유 방법을 제공한다.

∙비즈니스 로직과 프리젠테이션 로직을 분리할 수 있다.

∙컨트롤러와 뷰의 역할 분담으로 인해 웹 디자이너와 개발자 간의 효

율적인 업무 분담이 가능하다.

∙유지보수가 수월하다.

∙기능 확장이 용이하다.

∙Servlet 컨텍스트 리스너 및 필터 Servlet 등 고급 프로그래밍 기법

을 통해 보다 효과적인 웹 어플리케이션 설계가 가능해진다.

3.3.2 Servlet 동작 과정과 생명주기

Servlet 구조에서 가장 큰 특징은 Servlet 컨테이너다. 웹 서버는 Servlet 자체를 실행하지

못하므로 Java 가상머신을 내장한 Servlet 컨테이너(또는 Servlet 엔진)라는 실행환경이 필

요하다.

2장에서 JSP 학습을 위해 설치했던 Tomcat은 Java 언어로 만들어진 프로그램으로, 기본적

으로 간단한 웹 서버 기능을 가지고 있으며 주 역할은 Servlet 컨테이너이다. 물론 JSP 처리

를 위한 기능도 당연히 포함되어 있다.

[그림 3-13]을 통해 Servlet 동작과정을 살펴보자.

[그림 3-13] Servlet 구조

클라이언트 요청에 대한 Servlet 동작 과정은 다음과 같다.

➀ 컨테이너는 Servlet 클래스를 메모리에 적재하여 상주시킨다.➁ Servlet 클래스의 생성자 메소드를 호출해 인스턴스를 생성하여 메모리에 적재한다.➂ 생성된 인스턴스의 init() 메소드가 호출된다. init() 메소드는 Servlet 생명주기에서 단 한번만 실행된다. 따라서 init() 메소드에서는 각종 초기화 작업 등을 수행한다.

➃ Servlet에 대한 사용자 요청에 대해서는 web.xml 파일을 참조해 URL 매핑(URL

Mapping)을 확인하고 해당 Servlet 인스턴스로부터 스레드를 생성하여 service() 메소

드를 호출한다. 모든 사용자 요청에 대해 개별적인 service() 메소드가 호출되며 GET

또는 POST 요청을 구분하여 doGet()또는 doPost() 메소드가 호출된다. 따라서 Servlet

개발자는 doGet() 또는 doPost() 메소드에 대부분의 필요한 기능을 구현한다.

➄ destroy() 메소드는 Servlet 인스턴스가 더 이상 존재할 이유가 없어서 메모리에서 소멸될

때 호출된다. 이러한 상황에 필요한 작업이 있다면 이 메소드에 관련 내용을 구현한다.

JSP가 텍스트 파일 구조인데 비해 Servlet은 Java 클래스 구조다. 이는 Servlet이 일반 Java

소스의 구조를 가진다는 것을 의미하는 것이다. 따라서 Servlet은 컴파일 과정이 필요하고 특

정 클래스를 상속 받아야만 구현이 가능한 구조이기 때문에 Servlet을 완벽히 이해하려면

Servlet 클래스의 상관관계나 기본 구조를 이해해야 한다. 그리고 Servlet은 컨테이너와 유기

적으로 동작하기 때문에 컨테이너에서 Servlet의 상태에 따른 메소드 호출 관계를 중심으로

한 생명주기를 이해할 필요가 있다

1) Servlet API

Java Servlet API는 Servlet과 서버 사이의 인터페이스를 정의하고 있다. 모든 Servlet은

javax.servlet.Servlet 인터페이스를 구현해야 한다. 하지만 일반적으로 미리 정의된

javax.servlet.GenericServlet과 javax.servlet.http.HttpServlet 클래스 중 하나를 상속해서

구현한다. 대개는 HttpServlet을 상속하는 것이 유리하기 때문에 특별한 경우가 아니라면

HttpServlet을 상속받아 구현한다. HttpServlet은 GenericServlet의 하위 클래스로 HTTP

처리와 관련된 부가 기능이 추가된 구조다.

2) HttpServlet 구조

HttpServlet을 상속받아 구현하는 경우 Servlet 프로그램의 구조는 [그림 3-14]와 같다.

[그림 3-14] javax.servlet.http.HttpServlet을 상속받은 MyServlet 동작 구조

[그림 3-14]에서 MyServlet은 HttpServlet 클래스를 상속받아 만들어진 Servlet 클래스다.

Servlet 컨테이너는 service() 메소드를 호출하고, service() 메소드는 클라이언트 요청이

GET인지 POST인지 구분하여 각각에 대해 doGet() 또는 doPost() 메소드를 호출한다.

service() 메소드는 컨테이너가 자동으로 호출하기 때문에 개발자가 구현해야 할 부분은

doGet(), doPost() 메소드다. doGet()과 doPost()구현에 있어 클라이언트 특성을 고려해서

각각의 요청을 다르게 처리해줄 필요가 있을 경우에는 GET과 POST를 구별해야 하지만,

Servlet 자체에서는 GET과 POST를 구분해야 할 필요가 없는 경우가 더 많다. 이것은

Servlet에서 클라이언트로부터 요청, 또는 전달된 파라미터 값을 가져오기 위해서는 GET,

POST에 상관없이 request.getParameter()를 이용하면 되기 때문이다. 굳이 사용자 요청을

구분할 필요가 없다면 doGet()메소드에서 다시 doPost()를 호출하고 doPost() 내부에만 관련

처리 과정을 코딩하거나 service() 메소드를 오버라이딩해서 각각의 요청에 상관없이 특정 메

소드를 호출해서 처리하는 방법이 널리 사용된다.

HTTP 사용자 요청은 프로토콜에 정의된 명령에 의해 처리되는데 일반적으로 GET과

POST를 사용한다. 예를 들어, http://www.thinkonweb.com/index.html이라는 브라우저 요

청은 HTTP 프로토콜에서는 GET/index.html과 같이 서버에 전달된다. HTTP 프로토콜에

는 이외에도 HEAD, DELETE, OPTIONS, TRACE와 같은 요청이 정의되어 있다. Servlet

에서는 각각 doHead(), doDelete(), doOptions(), doTrace() 메소드를 통해서 이러한 요청을

처리할 수 있다. 그러나 GET/POST 이외의 요청에 대한 처리는 일반적인 웹 어플리케이션

개발에는 거의 사용되지 않는다.

3) GET 방식과 POST 방식

앞서도 잠깐 언급했듯이 HTTP에서 클라이언트 요청은 크게 GET 방식과 POST 방식으로

나뉜다. GET은 서버에 있는 정보를 가져오기 위해 설계되었고, POST는 클라이언트에 있는

정보를 서버로 올리기 위해 설계되었다. 하지만 GET 방식으로도 서버에 정보를 전달하는 것

이 가능하다. 두 방식은 HTTP 프로토콜에 규정되어 있으며 다음과 같은 특징이 있다.

- GET 방식

∙서버에 있는 정보를 가져오기 위해 설계된 방법이다(예를 들어 HTML, 이미지 등을 웹

브라우저에서 가져오기).

∙서버로 전달할 수 있는 데이터 크기는 최대 240Byte까지 가능하다.

∙QUERY_STRING 환경변수를 통해서 서버로 전달되는데, 다음 형식을 따른다.

∙요청 URL에서 ‘?’ 이후의 값들은 서버에서 QUERY_STRING을 통해 전달된다. ‘속성=

값’ 형태로 사용해야 하며 ‘&’는 여러 속성 값을 전달할 때 연결해주는 문자열이다.

∙요청 URL에 값들이 노출되기 때문에 보안 문제가 생길 수 있다.

- POST 방식

∙서버로 정보를 전달하기 위해 설계된 방법이다(예를 들어 HTML 폼에 입력한 내용을 서

버에 전달하기).

∙서버에 전달할 수 있는 데이터 크기는 제한이 없다.

∙URL에 값이 표시되지 않는다. 그래서 로그인 정보를 전달할 때에는 POST 방식을 사용

한다.

3.4 첫 번째 Servlet 프로그램 - helloworldservlet

본 절에서는 2장에서 설치한 Java, Tomcat, Acroedit를 사용하여 첫 번째 Servlet 프로그램

을 만들어 테스트해 볼 것이다. 첫 번째 Servlet 프로그램의 이름은 helloworldservlet 이며

만들어야 할 소스 코드 파일명은 HelloWorldServlet.java 이다. 이것은 JSP를 전혀 사용하지

않고 순수하게 Java 코드로 작성할 것이다.

Servlet 소스 파일을 작성하기 전에 우선 Servlet을 포함하여 JSP/Servlet 컨테이너에서 활

용할 목적의 Java 파일에 대한 컴파일 도구 역할을 하는 배치 화일인 'sjc.bat'을 직접 구성해

보자. 확장자가 bat으로 끝나는 파일은 윈도우즈 운영체제에서 실행이 가능한 파일이 되며 실

행 방법은 bat 파일에 적혀 있는 내용을 각 라인별로 차례로 수행하는 것이다.

원래 Java 파일을 컴파일해주는 프로그램은 Java를 설치할 때부터 Java 설치 폴더 밑의 bin

폴더에 있는 javac.exe 이다. 그럼 왜 sjc.bat과 같은 별도의 컴파일 도구를 구성하는가? 그

이유는 다음과 같다.

- 별도로 시스템 내에 CLASSPATH 환경 설정을 할 필요가 없다.

- javac의 -d 옵션을 활용하여 컴파일 결과인 클래스 파일이 위치할 곳을 지정하지 않아도

된다.

CLASSPATH란 javac가 컴파일 할 때 별도로 필요로 하는 jar 라이브러리가 있는 위치를

알려주는 시스템 환경 변수이다. CLASSPATH 라는 환경 변수 이름 자체가 javac와 약속이

되어 있어서 반드시 이 환경 변수에 jar 라이브러리 위치를 등록해야 한다. 사실 일반적으로

많이 활용되는 라이브러리는 [그림 3-15]과 같이 Java 프로그램이 설치된 폴더인

C:\Program Files\Java\jdk1.6.0_07 하위에 있는 jre 폴더 밑의 lib 폴더 안에 모여 있다.

[그림 3-15] 일반적인 jar 라이브러리들이 위치한 곳

일반적인 Java 프로그램을 작성하려고 한다면 별도의 CLASSPATH 지원 없이 javac 프로

그램 자체적으로 [그림 3-15]에 있는 jar 파일들은 자동으로 검색하여 필요한 내용을 참조할

수 있다. 특히 가장 많이 참조하는 라이브러리는 [그림 3-15]에서 보이는 여러 파일들 중

'rt.jar'이다.

하지만 Servlet 프로그램이 활용하는 라이브러리는 [그림 3-15]에서 보여주는 위치에 존재하

지 않고 [그림 3-16]처럼 Tomcat이 설치된 곳인 'C:\apache-tomcat-6.0.16\lib'에 위치한

다.

[그림 3-16] Servlet 프로그램이 참조하는 라이브러리들이 위치한 곳

Servlet 프로그램에서 참조하는 대부분의 라이브러리는 [그림 3-16]에서 보이는 jar 파일 중

에서 'servlet-api.jar' 이다. 그러므로 Java로 작성된 Servlet 소스 코드를 javac.exe 로 컴

파일하기 위해서는 CLASSPATH 환경 변수에 반드시 'C:\apache-tomcat-6.0.16\lib' 폴더

및 'servlet-api.jar' 파일을 등록해야 한다. 하지만 Servlet 소스 컴파일을 위하여 번거롭게

CLASSPATH 환경 변수을 윈도우즈 운영체제 시스템에 설정하는 것 보다 컴파일을 위한

javac를 실행할 때 다음과 같은 -cp 옵션 및 해당 jar 파일의 절대 경로를 적어주면 간단히

해결된다.

ja v a c -cp % C A T A L IN A _H O M E% \ lib \ se rv le t- a p i.ja r H e llo W o r ld S e rv le t .ja v a

위에서 '%CATALINA_HOME%'는 2장에서 설정한 CATALINA_HOME 환경 변수 값을

가져오는 것을 의미한다. 즉, '%CATALINA_HOME%'는 'C:\apache-tomcat-6.0.16'로

대치된다.

만약 다른 목적의 Java 파일 컴파일을 위하여 CLASSPATH를 환경변수로서 이미 설정해

놓은 것이 있다면 %CLASSPATH%라는 문구를 아래처럼 반드시 세미콜론(;)을 구분자로

사용하면서 -cp 옵션 앞에 제일 먼저 적어주면 기존에 설정해 놓은 CLASSPATH 환경변수

값을 함께 활용할 수 있다.

ja v a c -cp % C LA S S P A TH % ;% C A T A L IN A _H O M E% \ lib \ se rv le t- a p i.ja r H e llo W o r ld S e rv le t .ja v a

다시 말해서 위 javac 실행의미는 HelloWorldServlet.java 파일을 컴파일할 때 라이브러리

로서 'C:\apache-tomcat-6.0.16\lib\servlet-api.jar' 파일을 활용하겠다는 것이다.

한편, Java 파일을 컴파일하면 생성되는 클래스 파일의 위치 또한 중요하다. 이에 관한 사항

은 3-1절에서 이미 언급한 바 있는데 JSP/Servlet 컨테이너는 '\웹 어플리케이션 폴더

\WEB-INF\classes'에 Servlet과 Java빈즈와 관련된 클래스파일을 모아 둔다. 본 교재에서

는 웹 어플리케이션 폴더로서 jspbook을 활용하므로 javac를 사용할 때 -d 옵션 및

‘%CATALINA_HOME%\webapps\jspbook\WEB-INF\classes'를 다음과 같이 적어주면

컴파일 결과 클래스 파일을 원하는 곳에 정확히 위치시킬 수 있다.

ja v a c -d % C A TA L IN A _H O M E% \ w eb a p p s\ jsp b o o k\ W EB - IN F\ c la s se s H e llo W o rld S e rv le t .ja v a

지금까지 javac 컴파일러를 사용할 때 -cp 옵션 및 -d 옵션을 활용하여 라이브러리들이 있는

jar 파일 위치 및 컴파일 결과로 생성되는 클래스 파일의 위치를 지정하는 방법을 알아보았다.

이것을 종합적으로 하나로 합쳐놓은 내용이 바로 아래 보이는 sjc.bat 파일이다.

0 1-

ja v a c -cp % C LA S S P A T H % ;% C A TA L IN A _H O M E% \ lib \ se rv le t-a p i.ja r -d % C A T A L IN A _H O M E%\ w e b ap p s\ jsp b o o k\ W EB - IN F\ c la s se s % 1

[예제 3.2] Java설치 폴더\bin\sjc.bat

sjc.bat 파일이 저장되는 위치는 %JAVA_HOME%\bin으로서 'C:\Program Files\Java\jdk

1.6.0_07\bin'임을 주목하자. 바로 이 폴더가 javac.exe가 위치하는 곳이라 새로 만드는 컴파

일 도구도 이 곳에 위치시킨다. sjc.bat 내용에서 맨 마지막의 %1은 sjc.bat 파일을 실행시킬

때 인자로 들어오는 Java 파일명을 가리킨다.

3.4.1 Servlet 등록 및 URL 매핑

Servlet을 작성하여 실행하려면 반드시 JSP/Servlet 컨테이너에 등록을 시키고 관련 URL을

매핑하는 작업이 필요하다. 이러한 등록 과정 및 URL 메핑은 현재 작성중인 웹 어플리케이션

의 배치 정의자 역할을 수행하는 web.xml에 수행한다. 사실 이 부분이 JSP보다 Servlet으로

동적 웹 페이지를 만드는 것을 까다롭게 하는 과정이긴 하지만 반드시 필요한 과정이므로 차

근차근 익혀보자.

web.xml은 XML 문서이다. XML 문서는 여러 개의 엘리먼트들로 구성되며 각각의 엘리먼

트는 시작 태그와 종료 태그로 구성되어 있으며 이들이 명확하게 쌍으로 표현되어야 한다. 즉,

<servlet> 엘리먼트는 <servlet>와 </servlet>으로 표현된다. 다음 [표 2]는 Servlet 등록

및 URL 매핑을 위한 각 엘리먼트 종류 및 설명이다.

엘리먼트 설명

<servlet>

웹 어플리케이션 내에서 지칭하기 위

한 Servlet 이름과 실제 Servlet 클래스

이름을 매핑하는 역할을 한다.

<servlet-name>Servlet 이름</servlet-name>웹 어플리케이션 내에서 지칭하는

Servlet 이름을 명기한다.

<servlet-class>클래스 이름<servlet-class>실제 Servlet 클래스 이름을 명기한다.

확장자 class는 포함하지 않는다.

</servlet> <servlet>엘리먼트의 종료태그

<servlet-mapping>Servlet을 접근하기 위한 URL을 정한

다.

<servlet-name>Servlet 이름</servlet-name>URL 매핑을 원하는 Servlet 이름을 명

기한다.

<url-pattern>URL</url-mapping>

Servlet을 접근하기 위한 URL을 명기

한다. 보통 "/" 으로 시작되며 "/"의 의

미는 웹 어플리케이션의 루트를 의미

한다.

</servlet-mapping><servlet-mapping>엘리먼트의 종료

태그

[표 2] web.xml 내의 Servlet 등록 및 URL 매핑 관련 엘리먼트 설명

[그림 3-17] web.xml에 Servlet 등록 및 URL 매핑 방법

[그림 3-17]은 HelloWorldServlet.java 소스 코드가 컴파일된 HelloWorldServlet.class에

대한 Servlet 등록 및 URL 매핑 예제이다. <servlet-name> 엘리먼트가 두 번 나오는데 반

드시 이 두 엘리먼트의 내용을 정확히 일치해야 한다. 한편, 등록하고자 하는 Servlet 클래스

이 이름은 <servlet-class> 엘리먼트에 적어주는데 이 엘리먼트에 적어주는 내용은 클래스

이름과 정확하게 대소문자까지 일치해야 한다. 이 때 확장자는 명기하지 않는다. 한편,

<url-pattern> 엘리먼트에 현재 등록하는 Servlet에 대한 URL을 정하기 위해 사용되는데

그림에서와 같이 "/helloServlet"으로 URL을 정하면 실제 웹 브라우저에서 접근하기 위한

URL은 다음과 같다.

h ttp :/ / lo c a lh o s t :8 0 8 0 / jsp b o o k /h e llo S e rv le t

즉, <url-pattern> 엘리먼트의 내용 중 맨 앞의 "/"는 현재 웹 어플리케이션의 루트를 의미하

게 된다. 만약 <url-pattern> 엘리먼트의 내용이 "/servlets/helloServlet"이라면 웹 브라우

저에서 접근하기 위한 URL은 다음과 같아야 한다.

h ttp :/ / lo c a lh o s t :8 0 8 0 / jsp b o o k / se rv le ts /h e llo S e rv le t

이상 설명한 내용을 정리하여서 이제부터 하나씩 단계별로 첫 번째 Servlet 프로그램을 코딩

을 하고 실행을 해보자.

1) [그림 3-18]와 같이 탐색기에서 tomcat의 설치 폴더 하위의 jspbook폴더를 찾는다. 이 폴

더 밑에 WEB-INF 폴더를 만든다.

[그림 3-18] jspbook 폴더 밑의 WEB-INF 폴더 생성

2) [그림 3-19]처럼 WEB-INF 폴더 내에 classes 폴더와 java_sources 폴더를 만든다.

classes는 Tomcat과 약속이 되어져 있는 이름이기 때문에 정확하게 기입해야 하며

java_sources는 Servlet Java 코드를 모아놓을 폴더로서 개인이 알아서 그 이름을 정해도 되

는 폴더이다.

[그림 3-19] WEB-INF 폴더내에 classes 폴더와

java_sources 폴더 생성

3) java_sources 폴더 안에 다음 소스 코드를 입력하여 만든다. 파일명은

HelloWorldServlet.java으로 저장한다.

0 10 20 30 40 50 60 70 80 91 0-

1 11 21 31 41 51 61 71 81 92 0

im p o rt ja v a x .s e rv le t .* ;im p o rt ja v a x .s e rv le t .h t tp .* ;im p o rt ja v a .io .* ;

p u b lic c la s s H e llo W o rld S e rv le t e x te n d s H ttp S e rv le t { p u b lic v o id in it ( ) { S y s te m .o u t .p r in t ln (" In it !! !" ) ; }

p u b lic vo id d o G e t(H ttp S e rv le tR e q u e s t re q u e s t , H ttp S e rv le tR e sp o n se re sp o n s e ) th ro w s IO E x ce p t io n , S e rv le tE x c e p t io n { S y s te m .o u t .p r in t ln ("d o G e t ! !!" ) ; re sp o n se .se tC o n te n tT yp e (" te x t/h tm l" ) ; P r in tW r ite r o u t = re sp o n s e .g e tW r ite r( ) ; o u t .p r in t ln ("< h tm l> < b o d y b g co lo r= \ "y e llo w \ "> H e llo S e rv le t !< /b o d y> < /h tm l> " ) ; }

p u b lic v o id d e s tro y () { S y s te m .o u t .p r in t ln ("d e s tro y ! !!" ) ; }}

[예제 3.3] jspbook\WEB-INF\java_sources\HelloWorldServlet.java

06: Servlet 객체 최초 생성시 한번만 호출

10: Servlet 요청시 매번 호출

17: Servlet이 메모리에서 삭제될 때 한번만 호출

4) [그림 3-20]처럼 cmd창에서 java_sources 폴더로 위치한 후에 다음처럼 sjc.bat 도구를

사용하여 HelloWorldServlet.java 파일에 존재하는 Java 코드를 컴파일을 한다.

cd C :\ ap a c h e - to m ca t-6 .0 .1 6 \ w e b ap p s\ jsp b o o k\ W EB - IN F\ ja v a _ so u rc e s

s jc H e llo W o r ld S e rv le t .ja v a

[그림 3-20] 폴더 이동 및 Java 소스 컴파일

Note: cmd 창에서의 긴 파일경로명 쉽게 입력하기

"cd C:\apache-tomcat-6.0.16\webapps\jspbook\WEB-INF\java_sources" 명령처럼

상당히 긴 폴더 경로를 cmd 창에서 입력해야 할 때 불편이 따른다. 이럴 경우 탐

색기의 주소에서 복사(ctrl+c)를 해서 cmd창에서 붙여넣기를 하면 그 불편을 덜 수

있다.

[그림 3-21] 탐색기의 주소 활용

5) 위 컴파일 과정이 에러 없이 잘 되었는지 확인하고 에러가 있다면 수정을 한다. 컴파일이

성공적으로 끝났다면 컴파일의 산출물인 HelloWorldServlet.class가 WEB-INF 폴더 밑의

classes에 생성되었는지 [그림 3-22]처럼 확인한다.

[그림 3-22] Servlet 클래스 파일 생성 확인

6) WEB-INF 폴더 하위에 다음 web.xml 파일을 만든다.

0 10 20 30 40 50 60 70 80 91 01 11 21 31 41 51 61 71 81 92 0

< ?xm l v e rs io n = "1 .0 " e n co d in g = "u tf- 8 "?>< w e b -ap p xm ln s= "h ttp :/ / ja v a .su n .co m /xm l/n s / ja v a e e " xm ln s :x s i= "h ttp :/ /w w w .w 3 .o rg /2 0 0 1 /X M LS c h em a - in s ta n c e " x s i:s c h e m a Lo ca t io n = "h ttp :/ / ja v a .s u n .c o m /xm l/n s / ja v a e e h t tp :/ / ja v a .su n .co m /xm l/n s / ja v a e e /w e b -a p p _2 _5 .x s d " v e rs io n = "2 .5 ">

< d e s c r ip t io n > JS P B O O K E x am p le s . < /d e sc r ip t io n > < d isp la y -n am e> JS P B O O K E x am p le s< /d is p la y -n a m e > < se rv le t> < se rv le t-n a m e > h e llo S e rv le t< / se rv le t-n am e > < se rv le t-c la s s> H e llo W o r ld S e rv le t< /s e rv le t- c la s s> < /se rv le t> < se rv le t-m ap p in g > < se rv le t-n a m e > h e llo S e rv le t< / se rv le t-n am e > < u r l-p a tte rn > /h e llo S e rv le t< /u r l-p a tte rn > < /se rv le t-m ap p in g >< /w e b -a p p >

[예제 3.4] jspbook\WEB-INF\web.xml

13, 17: 반드시 두 Servlet 이름은 같아야 한다.

7) 웹 브라우저에서 [그림 3-23]처럼 결과를 확인한다. Servlet 실행을 위한 URL은 다음과

같다.

h ttp :/ / lo c a lh o s t :8 0 8 0 / js p b o o k /h e llo S e rv le t

[그림 3-23] 첫 번째 Servlet인 helloServlet 수행 확인

8) HelloWorldServlet.jsp의 11라인과 18라인에 System.out.println() 메소드를 활용하여 각

각 "init!!!"과 "doGet!!!"를 출력하는 것을 볼 수 있다. Servlet이나 JSP에서

System.out.println() 메소드를 활용하여 문자열을 출력하게 되면 Tomcat 실행 시에 보이는

cmd 창에 그 출력 내용이 나타난다. 현 상태에서 Tomcat 실행 cmd 창을 확인해보면 [그림

3-24]처럼 "init!!!"과 "doGet!!!"이 한 번씩 출력된다는 것을 알 수 있다. 이를 통하여 11라인

과 18라인이 수행되었다는 것을 알 수 있고 더불어서 HelloWorldServlet.java에 있는 init()

멤버 메소드와 doGet() 멤버 메소드가 한 번씩 호출되었음을 확인할 수 있다.

[그림 3-24] Tomcat 실행 cmd창에서 init()과 doGet()

멤버 메소드 실행 확인

9) 웹 브라우저에서 [새로고침]을 하거나 [F5]키를 여러 번 눌러서 다시 helloServlet를 재수

행하여 보자. 그러면 웹 브라우저 화면은 바뀌는 것이 없지만 Tomcat 실행 cmd 창에서 [그

림 3-25]처럼 "doGet!!!"이 여러 번 출력됨을 알 수 있다. 하지만, “Init!!!" 문자열은 더 이상

출력되지 않는다는 것도 알 수 있다. 즉, 웹 브라우저에서 Servlet을 재 호출할 때마다

doGet() 멤버 메소드만 여러 번 수행됨을 알 수 있다. 이와 같은 내용은 3.3.2 절에서 설명한

내용과 부합한다.

[그림 3-25] Tomcat 실행 cmd창에서 doGet() 멤버

메소드만 여러 번 실행됨을 확인