developerWorks에 처음 로그인하면 developerWorks프로파일이 생성됩니다.귀하의 프로파일에서 동의하신 내용이 공개되지만 이 사항은 언제든지 변경 가능합니다. 귀하의 성명(숨김으로 체크되어 있어도 표시됩니다)과 디스플레이 이름은 게시한 컨텐츠나 사이트 엑세스시 표시됩니다.

모든 정보가 안전하게 전송되었습니다.

처음 developerWorks에 로그인할 때 프로파일이 작성되므로, 이를 위해 디스플레이 이름을 선택해야 합니다. 선택하신 디스플레이 이름은 developerWorks에 게시한 컨텐츠에 표시됩니다.

3글자 이상 31글자 이하의 길이로 사용 가능합니다. dW커뮤니티 내에서는 보안상 이메일주소를 제외한 다른 이름을 지정하셔야 합니다.

모든 정보가 안전하게 전송되었습니다.

My developerWorks：

나의 통지：

로그아웃

언어 선택：

Google Web Toolkit, Apache Derby, Eclipse를 사용하여 Ajax 애플리케이션 구현하기, Part 4: 전개 (한글)

애플리케이션과 Derby 데이터베이스 실행하기

Noel Rappin, Senior Software Engineer, Motorola, Inc.

Noel Rappin, Ph.D.는 Georgia Institute of Technology의 Graphics, Visualization, Usability Center 소속이며 Motorola의 시니어 소프트 엔지니어이다. wxPython in Action과 Jython Essentials를 공동 집필했다. Noel의 블로그는 10printhello.blogspot.com이다.

요약： 이 시리즈의 지난 세 편의 기술자료에서는 Google Web Toolkit (GWT)을 사용하여 단순하면서도 기능적인 웹 애플리케이션을 구현했습니다. 지금까지. 여러분은 GWT의 Hosted Mode를 사용하여 애플리케이션을 편집 및 디버깅하면서, 자바™ 전개 툴 내에서 웹 서버 환경을 시뮬레이트 했습니다. 안타깝게도, 웹 애플리케이션을 실행하기 위해 모든 사용자들이 Eclipse를 다운로드 해야 하는 상황은 비현실적입니다. 따라서, 이 글에서는, 자바 웹 애플리케이션 내에서 GWT 애플리케이션을 전개하는 방법을 설명하고, Apache Derby 데이터베이스를 사용하여 GWT를 구동하는 방법을 설명합니다.

이 연재 자세히 보기

여기에 태그 달기!

원문 게재일: 2007 년 4 월 24 일
난이도: 중급
페이지뷰： 1515 회
의견：

이 글에서, 여러분은 예제 서블릿 컨테이너로 무료로 사용할 수 있는 Apache Tomcat을 사용할 것이다. 다른 서블릿 컨테이너들도 비슷하게 작동할 것이다. 기존 서버에도 전개할 수 있다. 그렇지 않다면, 이 글의 참고자료 섹션에 Tomcat 다운로드 방법이 나와있다. Microsoft® Windows® OS를 실행하고 있다면, Tomcat은 비교적 사용이 간단한 Windows용 바이너리 인스톨러를 갖고 있다. Mac 또는 UNIX® 시스템을 사용하고 있다면 컴파일 된 버전이 있다. 이를 압축을 풀어 알맞은 장소에 두면 된다. (/usr/local이 일반적인 장소이다.) 몇 가지 환경 변수를 설정했다면, 준비가 된 것이다.

클라이언트 코드 컴파일 하기

일반적으로, GWT 애플리케이션을 Tomcat에 전개 단계는 두 단계로 이루어진다.

필요한 모든 파일들을 모아서, 이것들을 Tomcat이 볼 수 있는 곳에 놓는다.
GWT 페이지에서 호출하는 모든 서버 측 액션을 Tomcat에 인식시킨다.

이 프로세스는 생각했던 것 보다 더 많은 단계가 필요하고, 이 글을 쓰고 있는 현재, 이를 자동화 하는 공식적인 방법이 없다. 따라서, 본 기사에서는 수동 프로세스를 설명하도록 하겠다. 여러분이 이 글을 읽을 때쯤이면 보다 강력한 전개용 툴이 나왔을 것이라고 기대한다.

Tomcat의 루트 디렉토리에 위치한다. 그 디렉토리에서 한 단계 아래로 가면, webapps라고 하는 하위 디렉토리를 볼 수 있다. Tomcat 서블릿 컨테이너 내에서 실행되는 모든 애플리케이션은 그곳에 고유의 디렉토리를 갖게 된다. 따라서, webapps 내에 slicr 라고 하는 디렉토리를 만든다. 자바 서버 측 애플리케이션의 구조는 서블릿 표준에 의해 설정되고, 모든 서블릿 런너(runner)들은 같은 구조를 지원해야 한다.
slicr 디렉토리 내에, WEB-INF라고 하는 하위 디렉토리를 만든다. 이때 주의할 것은 해당 디렉토리 명이 대문자인 것에 주목하라.
GWT용으로 컴파일 된 JavaScript 페이지와 일반적으로 컴파일 된 자바 클래스를 slicr 디렉토리로 옮긴다. 먼저 자바 클래스를 옮기는 방법을 설명하겠다.
여러분의 통합 개발 환경(IDE), Apache Ant 또는 다른 것을 사용하여 평소대로 자바 코드를 컴파일 한다. 두 가지 옵션이 있다.

가장 빠른 옵션은 .class 파일의 전체 트리를 Tomcat 하위 디렉토리 webapps/slicr/WEB-INF/classes로 복사하는 것이다. Tomcat은 실행될 때 webapps 디렉토리의 classpath 변수에 자동으로 배치한다.
또는, 여러분이 선택한 툴로 컴파일 된 클래스를 JAR 파일로 변환한 다음, JAR 파일을 webapps/slicer/WEB-INF/lib 디렉토리에 둔다. Tomcat은 classpath 변수에 있는 디렉토리에 JAR 파일을 배치한다.

GWT 클라이언트 파일 컴파일 하기

다음에는, GWT 클라이언트 파일을 컴파일 및 이동한다. 여러분은 대부분의 작업을 Hosted Mode에서 하기 때문에 이 단계를 건너뛸 수 있으며, 코드를 컴파일 하는 가장 빠른 방법은 Hosted Mode 콘솔에서 Compile 버튼을 사용하는 것이다. 하지만 이러한 자동화 보다 편리한 다른 방법이 존재할 수도 있을 것이다.

본 시리즈 Part 1에서, GWT applicationCreator 스크립트를 사용하여 GWT 프로젝트를 만들었다. 그 당시 내가 GWT 프로젝트 파일과 함께 생성된 "두 개의 쉘 스크립트"가 있지만 자세하게는 설명하지 않겠다고 했었다.

생성된 쉘 파일들 중 하나가 Slicr-compile이다. Windows에서, 이 파일은 .cmd 라는 확장자를 갖고 있다. (일반적으로, 이것은 여러분의 프로젝트 이름-컴파일이 된다.) 명령행에서 파일을 호출하거나, OS에 따라 이를 클릭한다. 이 스크립트는 다음과 같은 아웃풋을 내놓기 전에 잠시 동안 아무 일도 하지 않는다.

Output will be written into ./www/com.ibm.examples.Slicr Compilation succeeded

여기에서는 GWT가 모든 클라이언트 측 자바 코드를 JavaScript 코드로 컴파일 하고 있다. 클라이언트 측 코드는 기본적으로 프로젝트의 클라이언트 소스 디렉토리에 있는 모든 모드이다. 하지만, <source path=path/> 폼의 태그를 추가함으로써 .gwt.xml 파일에서 그 디렉토리를 수정할 수 있다. 여기에서, path는 여러분이 추가하고자 하는 소스 경로이다. 여러분이 고유의 경로를 추가한다면, 기본 경로는 더 이상 포함되지 않으므로, 기본 경로가 필요하다면 이를 명확하게 추가해야 한다.

GWT 컴파일러는 자바 코드를 성공적으로 변환하지만, 일부 아이템들은 문제를 일으킨다. 다음 사항을 특히 주목하라.

GWT 클라이언트 코드는 Java 1.4와 호환이 되어야 한다. 다시 말해서, generics도, autoboxing도, 새로운 for-each 루프도 없다는 의미이다. 아마도, 향후 Java 1.5 호환에 대하여 지원 될 것이다.
최소한의 Java Standard Library의 하위 세트만 지원된다. 지원되는 라이브러리 클래스들은 java.util과 java.lang 패키지로 제한된다. 이 모든 패키지들이 지원되는 것은 아니다. 특히, java.lang.reflect 패키지는 지원되지 않는다. 본 시리즈 Part 2에서 설명했지만, 제한이 된다는 의미는, 데이터베이스 코드 같은 아이템들을 시스템의 다른 부분에 두어야 한다는 것을 의미한다.
만일 당신이 정규식(regular expression)을 사용한다면, 자바 규칙이 아닌, JavaScript 규칙을 사용하여 런타임 시 인터프리팅 된다.
자바 직렬화(serialization)는 지원되지 않는다. GWT 원격 프로시저 메커니즘이 대신 사용된다. (Part 3)
부동 소수점 숫자와 긴 변수 유형의 정의에는 차이가 있다. 엄밀한 부동 소수점을 필요로 하는 계산은 서버 측에서 처리되어야 한다.
GWT 컴파일러는 자바 assert 문을 무시한다. 또한 synchronized 선언도 무시된다. JavaScript 인터프리터가 쓰레딩을 지원하지 않기 때문이다.

컴파일 아웃풋 연구

여러분의 자바 코드가 그러한 요구 사항들을 처리했으며, 컴파일이 성공했다고 가정하고, 컴파일 스크립트의 결과를 따라서, ./www/com.ibm.examples.Slicr 디렉토리에 아래 파일들이 생성된 것을 확인할 수 있다.(Listing 1) 물론, 약간의 일부 파일 이름들이 다를 수 있다.

Listing 1. GWT 컴파일 결과

                
1A0A627040909C0818A7A71B13246DCD.cache.html
1A0A627040909C0818A7A71B13246DCD.cache.xml
587B8CC6CF487EBD41844000481528BF.cache.html
587B8CC6CF487EBD41844000481528BF.cache.xml
64AF143E1C4C5866446137A8C42B4609.cache.html
64AF143E1C4C5866446137A8C42B4609.cache.xml
B01955141995DDAD97AFC2941024CE4E.cache.html
B01955141995DDAD97AFC2941024CE4E.cache.xml
Slicr.html
com.ibm.examples.Slicr.nocache.html
gwt.js
history.html
tree_closed.gif
tree_open.gif
tree_white.gif

쉬운 것부터 보자. Slicr.html은 여러분이 코딩하고, 공용 디렉토리에서 직접 복사했던 HTML 페이지이다. 공용 디렉토리에 있는 무엇이든 여기에 놓여진다. 세 개의 .gif 파일들이 있고, 이것은 세 개의 위젯들을 실행할 때 GWT에서 사용된다. Slicr 애플리케이션에는 트리 위젯이 없기 때문에, GWT가 이러한 이미지들을 아웃풋에 둔다고 생각할 수 있다. 나머지 파일들의 경우, history.html에는 상태를 관리하고 Back 버튼 작동을 보존하는 JavaScript 코드가 있다. gwt.js와 nocache.html 파일에는 GWT 애플리케이션을 시작하고 로딩하도록 설계된 보일러플레이트 코드가 포함되어 있다.

16 진수 숫자의 이해하기 힘든 이름들을 가진 파일들을 보자. 여섯 개의 HTML/XML 쌍이 있다. .html 파일을 열면 알아보기 힘든 많은 JavaScript 코드를 볼 수 있다. Listing 2는 이것을 무작위로 선택한 것이다.

Listing 2. JavaScript 코드

                
function ob(pb,qb){z();pb.F = qb;return pb;}
function rb(sb,tb,ub){z();sb.D = ub;sb.F = tb;return sb;}
function vb(){}
_ = vb.prototype = new f();_.jb = C;_.hb = E;_.i = 'java.lang.Throwable';
_.j = 1;_.D = null;_.F = null;function wb(xb){mb(xb);return xb;}
function yb(zb,Ab){ob(zb,Ab);return zb;}
function Bb(Cb,Db,Eb){rb(Cb,Db,Eb);return Cb;}

이것은 GWT 컴파일러에 의해 JavaScript 코드로 컴파일 된 자바 코드이다. 다섯 개의 HTML/XML 쌍이 있고, 각자 주요 웹 브라우저 렌더링 엔진들을 위한 것이다. Firefox/Gecko (신구 버전들), Windows Internet Explorer, Opera, Safari가 바로 그것이다. XML 파일들은 일부 데이터 유형 매핑을 관리하기 때문에 이 엔진에 대한 정확한 데이터 유형이 사용된다. 이해하기 힘든 부분은 브라우저로 보내져야 할 텍스트 파일의 크기를 압축하는 것이다. 사용자가 브라우저에서 GWT 페이지를 선택할 때, 보일러플레이트(boilerplate) 페이지에 있는 JavaScript 코드는 여러분 브라우저의 정확한 코드 버전을 자동으로 가져와서 로딩한다.

GWT 페이지를 전개하려면, www/com.ibm.examples.Slicr 디렉토리에 있는 모든 파일들이 Tomcat Home/webapps/slicr 디렉토리로 복사되어야 한다. 이것은 클라이언트 측을 관리한다.

위로

서버 측 전개하기

전에 서블릿 개발을 해봤다면, GWT 프로세스의 이 부분은 익숙할 것이다. 여러분이 작성했던 서버 측 코드 역시 서블릿 애플리케이션이며, Servlet 표준을 사용하여 전개된다.

우선, 일반 자바 컴파일러를 사용하여 모든 자바 코드를 컴파일 해야 한다. 두 가지 옵션이 있다.

모든 .class 파일들을 Tomcat Home/webapps/WEB-INF/classes 디렉토리에 둘 수 있다.
또는, 모든 .class 파일들을 점JAR 파일에 결합하고 그 파일을 Tomcat Home/webapps/WEB-INF/lib 디렉토리에 둘 수 있다.

컴파일 된 코드에는 GWT를 사용하여 이미 컴파일 했던 클라이언트 측 코드가 포함되어야 한다. 여러분은 서버 측에서 그러한 클라이언트 클래스 일부를 사용하여 데이터 전송에 활용한다.

또한, 여러분이 사용하는 서드 파티 라이브러리들을 같은 /lib 디렉토리에 놓을 수 있다. 이 디렉토리에는 언제나 gwt-servlet.jar 파일이 포함되고, 이것은 GWT 배포판에 포함되어 있다. 이 파일에는 애플리케이션에 필요한 모든 GWT 사용자 파일들이 들어있다.

주: 원래의 GWT 배포판에는 이 파일이 들어있지 않다. 하지만, gwt-user.jar 파일을 해킹하는 것을 포함하고 있는 웹 전개 명령을 보고 Tomcat을 손상시키는 서블릿 클래스를 제거한다. GWT 배포판이 최신의 것이라면, 이 단계는 불필요 하다.

이 경우, Derby 배포판의 일부이며, Derby 데이터베이스 클래스를 포함하고 있는 derby.jar 파일도 필요하다. 여러분이 입력한 토핑 데이터를 잃지 않기 위해 Derby 데이터베이스를 이동하려면, 본 시리즈 Part 2에서 Derby가 만들었던 slicr 디렉토리 데이터베이스를 배치한다. (Part 2의 지시를 따라가면, 이 디렉토리는 /src 디렉토리와 같은 레벨에 있는 프로젝트 탑 레벨 밑에 있어야 한다.) 디렉토리를 어디에 두는 가는 문제가 되지 않지만, Derby용 JDBC URL 을 정의하는 ToppingServiceImpl 클래스의 라인은 그 위치를 반영해야 한다.

public static final String PROTOCOL = "jdbc:derby:[LOCATION OF SLICR DB DIRECTORY]/slicr;";

필자는 Derby 데이터베이스를 Tomcat webapps/slicr 디렉토리 안에 배치했고, 여기는 WEB-INF 디렉토리와 같은 레벨이다. 따라서 필자의 코드는 다음과 같다.

public static final String PROTOCOL = "jdbc:derby:/usr/local/apache-tomcat-5.5.20/webapps/slicr/slicr;";

web.xml에서 서버 측 호출 정의하기

코드가 Tomcat 서블릿 컨테이너에 보이게 한 다음, Tomcat 웹 서버가 이해할 수 있는 용어로 GWT 애플리케이션에서 모든 서버 측 호출을 정의해야 한다. Tomcat 애플리케이션의 web.xml 파일에 있는 서블릿들 처럼, 그러한 서버 측 호출을 정의해야 한다. gwt.xml 파일에서 정의된 서블릿의 경우, 다음과 같다.

<servlet path="/toppings" class="com.ibm.examples.server.ToppingServiceImpl"/>

web.xml 파일에 <servlet>과 <servlet-mapping> 태그를 만들어야 한다. Listing 3은 GWT 프로젝트용 모든 web.xml 파일을 보여주고 있다. ToppngService 서블릿용 태그들이 포함되어 있다.

Listing 3. Web.xml

                
<?xml version="1.0" encoding="UTF-8"?> 
<web-app> 
    <servlet> 
        <servlet-name>ToppingService</servlet-name> 
        <servlet-class>
            com.ibm.examples.server.ToppingServiceImpl
        </servlet-class> 
    </servlet> 
    <servlet-mapping> 
        <servlet-name>ToppingService</servlet-name> 
        <url-pattern>/toppings</url-pattern> 
    </servlet-mapping> 
</web-app>

web.xml 파일에서, gwt.xml 파일에 주어진 두 가지 정보는 두 개의 다른 태그들로 나뉜다. 이것은 Java make-everything-as-verbose-as-possible 이니셔티브에 입각한 것이다. <servlet> 태그는 그 서블릿의 완전한 클래스 이름을 취하고, <servlet-mapping> 태그는 GWT 파일에서 정의했던 URL 경로 이름을 취한다. 두 개는 공통 servlet-name 애트리뷰트를 통해 통합되고, 이는 여러분이 일관성을 유지한다면, 여러분이 좋아하는 어떤 이름도 사용할 수 있다. 하지만, 실제 서비스의 GWT 이름 같은 단순한 네이밍 규약을 사용하는 것이 좋다.

물론 파일의 생성은 순수한 텍스트 조작부터 XML Document Object Model (DOM) 조작에 이르기까지 어떤 메소드에 의해서도 자동으로 수행될 수 있다. 이 파일을 작성했다면, 이것을 Tomcat WEB-INF 디렉토리에 둔다. Slicr 전개가 완료되고, 여러분은 Tomcat을 시작하고 URL을 타이핑 하여 애플리케이션을 테스트 할 수 있다. (http://localhost:8080/slicr/Slicr.html) 성공했다면, 본 시리즈의 Part 3에 있는 것과 똑 같은 Slicr 페이지를 보게 된다.

전개 문제 해결

문제	원인
URL에 타이핑 할 때 어떤 것도 볼 수 없다.	원인은 Slicr.html 페이지가 올바른 장소에 있지 않기 때문이다. `Welcome to Slicr`가 있지만, GWT JavaScript 파일들을 잘못 배치한 경우이다.
페이지의 왼편에 헤더 외에 토핑 패인 상에 어떤 것도 볼 수 없다.	서버 호출이 실패한 것이다. Tomcat 로그로 가서 문제를 진단해야 한다. (또는 콜백에서 `OnFailure()` 메소드를 변경하여 에러 메시지를 패인에 프린트 한다.) 첫 번째 가능성은 Slicr 자바 클래스 파일이 제 장소에 없는 것이고, 이는 서블릿이 로딩되는 것 조차 막는다. (web.xml 파일이 올바르게 설정되지 않을 경우에도 이 같은 일이 발생한다.
Derby 오류가 생겼다.	JDBC URL이 Derby 데이터 디렉토리의 위치와 매치하는지 확인하라.

지금까지 전체 프로세스를 설명했다. 많은 단계들이 있었지만, 어떤 것도 특별히 복잡한 것은 없다. 스크립트, Ant 태스크 또는 프로젝트에 맞는 다른 방법을 사용해서 전개를 자동화 하는 것이 좋다. 참고자료 섹션에서 예제를 볼 수 있고, 다양한 자바 IDE가 점점 GWT를 지원하고 있다. 원버튼(one-button) 전개로 여러분의 고민거리를 해결할 수 있다.

위로

결론

GWT 시리즈를 통해서 간단한 웹 애플리케이션을 구현해 보았다. 이 과정에서 풍부한 클라이언트 작동을 갖춘 강력한 웹 애플리케이션을 생성하는 데이터베이스 백엔드에 GWT를 사용하는 방법을 배웠다. 네 편의 기술자료를 끝마쳤지만, 아직 GWT의 극히 일부분만 본 것이다. JUnit 테스트 통합, JavaScript Serialized Object Notation (JSON) 데이터 교환을 통한 다른 웹 서비스 사용하기, 새로운 GWT 국제화 기능 같은 강력한 기능들 역시 검토해 보기 바란다. GWT 개발은 계속 성장하고 있고, 새로운 기능과 툴들이 계속 추가되고 있다. 여러분도 애플리케이션 구현에 필요한 툴을 찾아가기 바란다.

기사의 원문보기