OK 괜찮아, 동네 개발자형

클라이언트 디플로이어 패키지를 사용해서 디플로이하기
Deploying using the Client Deployer Package
번역 translated by kenu_AT_okjsp.pe.kr

클라이언트 디플로이어는 운영이나 개발 서버에 웹 애플리케이션을 검증, 컴파일, 배치시킬 수 있는 패키지입니다. 이 기능은 자동 배치를 위해서 톰캣 매니저를 사용한다는 것은 알아야 겠죠.
The client deployer is a package which can be used to validate, compile, and deploy a web application to a production or development server. It should be noted that this feature uses the Tomcat manager for automatic deployment.

이 디플로이어는 카탈리나 매니저 앤트 태스크, 배치 전에 JSP 컴파일을 하기 위한 재스퍼 페이지 컴파일러, 그리고 웹 애플리케이션 배치 기술서를 검증하는 태스크를 포함하고 있습니다. 검증 태스크(org.apache.catalina.ant.ValidatorTask 클래스)는 파라미터 하나만 받습니다: 웹 애플리케이션의 기본 경로
The deployer includes the Catalina manager Ant tasks, the Jasper page compiler for JSP compilation before deployment, as well as a task which validates the webapp's deployment descriptor. The validator task (class org.apache.catalina.ant.ValidatorTask) allows only one parameter: the base path of an expanded web application.

디플로이어는 입력으로 펼쳐진 웹 애플리케이션을 이용합니다(아래에 나와 있는 디플로이어의 프로퍼티 목록 참조). 디플로이어가 프로그램으로 배치하게 되는 웹 애플리케이션은 톰캣에 특화된 배치 설정을 포함할 수도 있습니다. /META-INF/context.xml 안에 있는 컨텍스트 설정 XML 파일이죠.
The deployer uses an unpacked web application as input (see the list of the properties used by the deployer below). A web application which is programatically deployed with the deployer may include Tomcat specific deployment configuration, by including a Context configuration XML file in /META-INF/context.xml.

디플로이어 패키지는 다음과 같은 앤트 스크립트 타겟을 사용할 수 있습니다:

• compile (default): 웹 애플리케이션을 컴파일하고 검증합니다. 독립적으로 사용될 수 있고, 실행중인 톰캣 서버가 없어도 됩니다. 컴파일된 애플리케이션은 오직 관련된 톰캣 5.0.x버전의 서버에서만 실행됩니다. 다른 버전에서는 동작한다고 보장할 수 없습니다. 재스퍼에 의해 생성된 코드는 실행 컴포넌트에 의존하기 때문입니다. 또 하나 알아야 할 것은 이 compile 타겟은 웹 애플리케이션의 /WEB-INF/classes 폴더 안에 있는 모든 자바 소스는 자동으로 모두 컴파일 해 버린다는 것입니다.
• deploy: (컴파일 되든 안되든) 웹 애플리케이션을 톰캣 서버로 배치합니다.
• undeploy: 웹 애플리케이션을 제거.
• start: 웹 애플리케이션을 시작.
• reload: 웹 애플리케이션을 릴로드.
• stop: 웹 애플리케이션을 정지.

The deployer package includes a ready to use Ant script, with the following targets:
compile (default): Compile and validate the web application. This can be used standalone, and does not need a running Tomcat server. The compiled application will only run on the associated Tomcat 5.0.x server release, and is not guaranteed to work on another Tomcat release, as the code generated by Jasper depends on its runtime component. It should also be noted that this target will also compile automatically any Java source file located in the /WEB-INF/classes folder of the web application.
deploy: Deploy a web application (compiled or not) to a Tomcat server
undeploy: Undeploy a web application
start: Start web application
reload: Reload web application
stop: Stop web application

다음 프로퍼티는 시스템 프로퍼티나 또는 디플로이어 패키지의 루트 폴더에 있는 deployer.properties 파일을 통해서 지정할 수 있습니다:

• build: 기본적으로 사용되는 빌드 폴더는 ${build}/webapp${path} 입니다. compile 타겟의 실행이 마친 후, 웹 애플리케이션 WAR 파일은 ${build}/webapp${path}.war 에 만들어집니다.
• webapp: 컴파일되고 검증되고, 압축이 풀린 웹 애플리케이션이 담길 폴더. 기본 폴더명은 myapp 입니다.
• path: 웹 애플리케이션의 배치될 컨텍스트 경로. 기본값은 /myapp.
• url: 실행중인 톰캣 서버의 매니저 웹애플리케이션에 접근할 수 있는 절대 URL. 여기를 통해서 웹 애플리케이션을 배치(설치) 또는 제거할 수 있습니다. 정해지지 않으면 디플로이어는 로컬호스트에서 돌아가는 톰캣인스턴스의 주소 http://localhost:8080/manager로 접근하려 할 것 입니다.
• username: 톰캣 매니저 연결용 username.
• password: 톰캣 매니저 연결용 password.

The following properties can be specified, either as system properties, or by using a deployer.properties file located in the root folder of the deployer package:
build: The build folder used will be, by default, ${build}/webapp${path}. After the end of the execution of the compile target, the web application WAR will be located at ${build}/webapp${path}.war.
webapp: Folder containing the expanded web application which will be compiled and validated. By default, the folder is myapp.
path: Deployed context path of the web application, by default /myapp.
url: Absolute URL to the manager web application of a running Tomcat server, which will be used to deploy and undeploy the web application. By default, the deployer will attempt to access a Tomcat instance running on localhost, at http://localhost:8080/manager.
username: Username to be used to connect to the Tomcat manager.
password: Password to be used to connect to the Tomcat manager.

from: http://tomcat.apache.org/tomcat-5.0-doc/deployer-howto.html

지난 포스트에 이미지만 작뜩 붙여놓고 설명을 하지 못했습니다.
하지만 김풍주님의 도움으로 더 좋은 방법을 알게 되었습니다. 그리고 근원적인 이유도 함께 말이죠.

http://www.eclipse.org/webtools/faq/TomcatServerFAQ.php#info_10
주소에 나와있는 것인데, 톰캣에 왜 META-INF 디렉토리가 있었나 생각했었는데, 컨텍스트 관련한 설치 정보를 넣을 수 있더군요.

곧 좋은 기사를 하나 내놓을 수 있을 듯 합니다. 급방긋 ^_^

jdk1.5에 tomcat5.5 그리고 eclipseWTP1.5 버전에 해당됩니다.

 
이클립스 사이트에 붙어있는 배너입니다. 유로파, 목성이라는 뜻이죠. 목성의 위성입니다. 지난 해 칼리스토(Calisto)라는 프로젝트가 나왔을 때는 이해를 잘 못했는데, 3.3버전과 맥을 같이하는 유로파 프로젝트를 보고서는 어떤 존재인지 감을 잡았습니다.

이클립스의 단점은 잦은 패치로 인한 상관관계에 있는 프로젝트들의 버전 관리가 어렵다는 것입니다. 이에 대한 해결점으로 모듈 버전 간 의존성을 관리해주는 프로젝트가 바로 3.2버전과 함께한 칼리스토, 3.3버전에 맞춰진 유로파입니다.

http://download.eclipse.org/technology/phoenix/demos/install-wtp/install-wtp.html
여기 동영상을 참고로 하시면 금방 알 수 있을 것입니다.

유로파를 사용해서 설치하는 것을 약간의 설명과 함께 보겠습니다.
eclipse 3.3RC4를 받아서 시작하면 위와 같이 로고에 Europa가 적혀있는 것을 볼 수 있습니다. eclipse WTP all-in-one을 받지 않아도 다음과 같은 방법으로 WTP 플러그인을 설치할 수 있습니다.

메뉴의 Help > Software Updates > Find and Install... 을 선택합니다.

WTP 관련 프로젝트들을 설치할 것인데, 두번째 메뉴인 Search for new features to install 을 선택합니다.

Europa Discovery Site를 선택합니다. 그리고 우측 하단의 Finish 버튼을 가볍게 클릭.

미러링을 지원하는 사이트 목록이 나옵니다. 카이스트와 다음 커뮤니케이션이 고맙게도 지원하고 있지요.

이제 본론으로 들어왔습니다. Europa Discovery Site 의 +를 눌러서 확장시킵니다.

Europa에는 21개의 프로젝트가 들어있습니다. 아래쪽에 있는 웹 개발 관련 프로젝트를 선택하겠습니다. 스크롤바를 아래로 쭈욱.

Web and JEE Development 를 선택하려고 합니다. 펼쳐보면 다음과 같이 4개의 서브 프로젝트 모듈들이 보입니다. XML 편집기, WST, JST, 퍼시스턴스 API툴 4가지죠.

체크하는 순간 빨간색 표시의 x가 뜹니다. 해당 프로젝트에서 필요로 하는 다른 프로젝트의 모듈이 없기 때문입니다.

당황하지 말고, 우측에 있는 Select Required 버튼을 클릭합니다. 그러면 같이 설치되어야할 모듈들의 체크박스가 자동으로 체크됩니다. 빨간 표시도 더 이상 보이지 않습니다.
여기서 유로파의 진가가 나타납니다.

라이센스가 나옵니다. EPL로 알고 있습니다. CPL을 토대로 만든 라이센스죠. 상업적인 용도로 사용할 수 있다 정도가 되겠습니다. ^^; 남이 만든 것 가져다 쓸 때는 라이센스 체크는 기본입니다만 그 종류가 많다 보니 쉽지 않은 것도 사실입니다.

옵션 특성들입니다. Next를 클릭해서 다음으로 이동하죠.

설치가 이뤄집니다. 설치 경로를 바꿀 필요는 없겠죠.

필요한 파일을 다운로드 받습니다.

마지막으로 설치에 대한 확인 창이 뜹니다. Install All 버튼을 클릭합니다. Install 버튼을 클릭해서 하나씩 설치되는 것들을 확인하셔도 좋습니다. 어느 세월~에 하실랑가요. ㅋㅋ

드디어 설치입니다. Run inBackground 버튼을 클릭해 놓으면 이클립스에서 백그라운드로 동작하게 됩니다. 우측하단의 움직이는 프로그레스바를 클릭하면 관련 뷰가 뜹니다.

완료되었습니다. 이상이 없다면 이클립스 재시작 후에 Web Tools Platform을 사용할 수 있습니다.

웹이 보편화되면서 브라우저에서의 문자세트에 대한 얘기도 점점 많아지고 있습니다. 글자가 깨져 보이는 경우는 바로 이 문자세트가 맞지 않아서인데, 세상의 모든 언어들을 한 화면에 표시하기 위한 방식이 UTF8입니다. 물론 포토샵 등으로 이미지를 통해서 한 화면에 표시하는 방법도 있기는 하죠. 철푸덕. ^^;
동일한 내용의 파일이 문자세트에 따라 어떤 차이가 있는지 간략히 살펴보겠습니다.
필자가 좋아하는 에디터인 울트라에디트를 이용해서 적어놓은 글자들입니다. ctrl+H를 하면 16진수 형태의 코드로 보여지는데 다음과 같습니다.
컴퓨터가 내부적으로 기억하는 코드를 볼 수 있습니다. h에 해당하는 68은 16진수로 표기된 것이고 10진수로 바꾸면 6*16+8 = 96+8 = 104 입니다. 104번째 해당하는 문자라는 것을 알 수 있죠. 0D 0A 부분이 보일 텐데, windows에서 엔터를 치면 이렇게 두 문자(2 bytes)가 자동으로 만들어집니다. java에서 "\r\n" 이라고 하는 표시하는 것과 일맥상통하죠. 뒤 이어 한글은 두 자리로 되어있는데, "가"는 B0 A1, "나"는 B3 AA 로 컴퓨터가 기억하고 있다는 것을 알 수 있습니다.

울트라에디트에서 이것을 utf8로 변환해보겠습니다. 다시 ctrl+H를 눌러서 일반텍스트 편집화면으로 되돌립니다.
메뉴의 파일(F)에서 "변환"을 선택하고 ASCII -> UTF8(Unicode 편집) 항목을 선택합니다.
파일의 코드셋이 변경되었습니다. 다른 이름으로 저장해보겠습니다.
파일의 크기가 바뀐 것을 감지하셨는지 모르겠네요. ^^; hello_utf8.txt로 저장을 했는데 이 파일을 열어서 ctrl+H를 해보면 다음과 같습니다.
h앞에 세 문자가 더 들어간 것을 볼 수 있습니다. "EF BB BF". 그리고 영어부분은 이전과 같은데 한글부분의 문자가 2바이트 단위에서 3바이트 단위로 늘어났습니다. 즉 "가"가 EA BO 80 이고 "나"가 EB 82 98 입니다.

정리를 하자면 같은 내용의 문자열을 표시한다고 해도 문자세트(코드세트, charset)에 따라서 내부적으로 기억하는 방식은 다르다는 것입니다.

한 가지 더, utf8편집을 위해서 ultraedit 만 필요한 것은 아닙니다. windows의 메모장에서도 편집이 가능합니다. 저장할 때 파일명을 적고 아래에 있는 인코딩을 ANSI에서 UTF-8로 정해주면 됩니다.

아, Mac에서는 Smultron (http://smultron.sourceforge.net/)이라는 편집기를 사용하고 있습니다.
읽어주셔서 감사합니다. ^^

브라우저 하단에 위치한 debug 패널을 창으로 띄워서 사용할 수 있습니다.
control + F12(Mac은 command + F12) 단축키를 이용하면 바로 새로운 창으로 띄울 수 있습니다.
모니터를 두 개 사용하는 경우 좋은 효과를 볼 수 있습니다. ^^;(하나 지르고 싶다.)

하단에서 창으로 띄우는 방법은 검색칸 옆의 꺽쇠 아이콘을 클릭해도 됩니다.

related: http://www.getfirebug.com/using.html

웹개발을 하면서 데이터의 전달은 중요한 디버깅 요소입니다.
어떤 데이터들이 전달이 되었는지 firebug에서도 확인할 수 있습니다.


버그를 기준으로 하단 회색줄의 Net 탭을 클릭합니다. 상단의 메뉴들이 변하는데, 요약하면 다음과 같습니다.
All: 모두 나옵니다.
HTML: 이미지, CSS, JS 다 빼고 html 만 목록에 보입니다.
CSS: CSS 파일목록만 보입니다.
JS: JavaScript 파일들만 보입니다.
XHR: XmlHttpRequest 의 줄임인데, Ajax의 중심이죠. Ajax호출정보만 따로 모았습니다.
Images: 이미지 목록만 나타납니다. 아래 목록에서 썸네일을 볼 수 있죠.
Flash: 현대 웹에서 중요한 자리를 꿰찬 swf 목록이 주르륵.

목록을 클릭하면 탭이 또 보입니다. 이노무 탭 세상. 다 탭이래요. 탭댄스라도.. 또깍따그닥.
파라미터가 있는 주소면 Params 탭이 보입니다. Post방식일 때는 post라고 나옵니다.
아래 정리된 파라미터 이름과 그 옆에 값들이 보일 겁니다.

멋진 살충제입니다.
아, 살충제를 개발한 Joe Hewitt님이 Yahoo UI 팀에 fulltime firebug개발자로 이직하신다고 하네요.
n모사의 nzeo님 생각나네요. ㅎㅎ 그런 직장에 들어가기 전에는 side-job으로 firebug를 개발하셨는데, 아주 잘 되었네요. 돈 받으면서 자기가 키운 프로그램을 계속 키운다는 행복한 개발자의 이야기였습니다.

JSP 디버깅은 환경설정이 거의 반을 차지합니다. eclipse WTP 에서 JSP 개발환경을 구축하는 것은 따로 설명하겠습니다. 일단 이 환경만 구축이 되면 JSP디버깅은 java 디버깅과 크게 다르지 않습니다.
디버깅은 JVM내부를 들여다 볼 수 있어야 합니다. eclipse WTP에서 WAS를 구동하게 되면 WAS의 메모리를 들여다 볼 수 있습니다. 이것에 기반하여 JSP 가 돌아가는 WAS의 메모리 값을 확인하는 것이 기본입니다.

debugjsp 라는 프로젝트를 만들었습니다. 프로젝트 아이콘을 보시면 debugjava 프로젝트와 다른 것을 알 수 있는데, 조그마한 지구 모양과 J 모양은 웹 관련 java프로젝트라는 의미입니다. 웹 페이지를 돌리기 위해서 웹서버가 필요한데 그것은 Servers 프로젝트가 담당합니다. jsp프로젝트에서 만들 수 있습니다. 로컬 PC에 설치된 Tomcat 같은 WAS를 이용하는 프로젝트입니다.

debug할 jsp 페이지를 하나 만들어보겠습니다.

JSP 파일은 debugjsp project 내에 WebContent라고 자동 생성된 디렉토리 아래 놓아둡니다. project명을 따라서 context가 정해지는데 일단 /debugjsp 라는 것이 URL에 따라다닌다는 정도만 기억하십시오. debug.jsp 파일을 만듭니다.

똑같은 알고리즘 3번째 보니까 토나올 것 같지 않나요? ㅎㅎ;
일단 샘플이 재밌어야 공부할 맛 나는데, 제가 나이가 많이 들었나 봅니다. ^^;
다음과 같은 화면이 보이겠죠.

소스도 다 되었겠다 이제 디버그 모드로 움직여 봅시다. 아 출발하기 전에 중단점 하나 찍어줘야죠. 브레이크댄스 아니, 브레이크포인트. JSP에서는 scriptlet부분에 중단점이 찍힙니다. HTML태그나 javascript 라인에는 중단점을 찍을 수 없습니다. 다 되는 거 없냐구요? 만드세요. ^^;
아주 방법이 없는 것은 아닙니다. JSP와 javascript의 실행환경이 다르다고 전에 말씀을 드린 적이 있습니다. 때문에 디버그 모드가 따로 분리되어야 됩니다. 서버쪽에서 일어나는 행동은 eclipse의 debug를 사용하고 브라우저쪽의 디버깅은 firebug를 사용하면 양쪽 모두 디버깅을 할 수 있습니다.

적당한 곳에 중단점을 찍으셨으면 보일겁니다. 괜히 bookmark 찍어놓고 "아 조타" 이러지 마세요. 디버깅하고 북마크하고는 찍은 것 빼고는 다르니까요. debug.jsp파일명에서 메뉴를 불러냅니다. 컨텍스트 메뉴 하단에 Debug As 라고 보일 것이고, 확장을 하면 Debug on Server 가 보입니다. 아래 그림을 보시면 소심하게 찍혀있는 중단점 보이시죠? ^^; 전 찍었습니다. 휘릭~! 아, 도망가면 안 되지 강좌는 끝내야죠. ㅎㅎ


디버그 퍼스펙티브로 볼 것이냐고 이클립스가 물어올 겁니다. 가야죠. 다음과 같이 보일 겁니다. java debug랑 똑같습니다. 다른 게 있다면 Variables쪽에 보이는 것이 엄청 많다는 것과 Tomcat WAS의 Thread가 적나라하게 보입니다.

이후 step over, step into, step return 등은 java와 동일합니다. 이로써 jsp까지의 디버깅 방법은 간략하게 알아보았습니다. 어설픈 설명 보시느라 수고 많으셨습니다.

좋은 하루 되세요.


참고: 빵세님의 Eclipse 3.2 WTP + resin 환경에서 jsp디버그
http://bangse.tistory.com/5

이클립스를 씁니다.
좋은 툴이 있는데, 콘솔에서 힘들게 디버깅하는 것은 내키지 않는 일입니다.
$JAVA_HOME/bin/jdb.exe 얘기하는 겁니다. 사실 잘 쓰기 힘듭니다. 아직 그런 상황은 겪지 않아서겠죠.

eclipse에서 Java프로젝트를 만들어서 다음과 같이 구구단을 만들어 보겠습니다.

소스2 Multiplication.java

구구단에 환장한 사람 같네요. 사용하는 예제마다 구구단이라니. ^^; 그래서 좀 색다르게 해봤습니다. 영어 좀 썼습니다. Multiplication Table. 계속 가죠. ^^;
이클립스에서는 이렇게 보입니다.


브레이크포인트를 찍어보겠습니다. for문이 시작되는 라인의 앞쪽 여백에 더블클릭을 하면 다음과 같이 점이 찍힙니다.
이제 디버그 모드로 들어가보겠습니다.
파일을 선택하고 컨텍스트 메뉴를 열면 Debug As 라는 메뉴가 보입니다. 거기에서 Java Application 을 선택합니다. 화면은 ㅎㅎ MacOS X입니다. Windows 도 마찬가지입니다. 아, 리눅스도요. 모두 이클립스 세상입니다. ㅎㅎ;
퍼스펙티브가 바뀐다고 창이 하나 뜨는데, 바꿔줍니다. 다음과 같이 화면 레이아웃이 바뀌면서 디버그 퍼스펙티브로 변경됩니다.


Debug 뷰 패널에 우측 상단에 보이는 아이콘들은 디버그 흐름을 컨트롤하는 기능들입니다. 지난 번 말씀드린 Step Into(F5), Step Over(F6), Step Return(F7) 기능과 좌측에 Resume을 확인할 수 있습니다. Drop to Frame이라는 새로운 메뉴도 보일텐데, 해당 메소드의 시작부터 다시 실행할 수 있는 기능입니다. 디버그를 종료하고 다시 시작하는 것이 아니라 현재 디버깅하는 메소드의 첫부분으로 다시 돌아가서 실행하는 기능입니다.

우측 Variables 뷰에는 변수들의 내용이 있습니다. 이클립스 디버깅에 관한 것은 차후에 더 알아보도록 하겠습니다.

다음 글은 JSP 디버깅입니다. 기대하십시오.

디버그(debug)는 쉽지 않은 작업입니다. 벌레 잡는 일이 프로그램에서 가장 정성이 많이 들어가는 작업이기도 합니다.

1. 디버그의 기본
2. 자바스크립트 디버그
3. Java debugging
4. JSP debugging

이 네 가지에 대해서 글을 써보려고 합니다.
디버그의 기원은 초기 계전기 사이에 있는 죽어있는 나방이 컴퓨터의 오작동을 일으켰고, 그 나방을 제거하자 정상 작동한 것에서 유래를 찾고 있습니다. 말 그대로 de+bug 입니다. ㅎㅎ

프로그래밍을 할 때 정상적인 데이터가 들어왔을 때를 기준으로 설계를 합니다. 하지만 프로그램을 실행할 때 발생하는 예상하지 못했던 경우로 인해 버그가 발생합니다. 숫자입력을 기대했는데, 문자가 들어오는 경우나 자료실을 운영하는데 서버의 하드디스크가 꽉 차는 경우를 예로 들 수 있습니다.

전자의 경우는 프로그램 수정을 통해서 디버그 하기 용이합니다. 후자의 경우는 하드디스크 공간 확장 내지는 불필요한 파일 삭제 등의 조치가 필요한데, 제가 설명하려는 영역에서 제외합니다.

프로그램을 디버깅하기 위해서는 버그를 발생시키는 코드와 그 때 사용된 테스트 값이 필요합니다. 버그를 재현할 수 있다면 프로그램의 약점을 파악한 것입니다. 따라서 디버깅이 쉽게 됩니다. 가장 어려운 경우는 간헐적으로 발생하는 버그입니다. 어떤 이유로 발생하는지 파악하기 어렵기 때문에 디버깅이 아주 어렵습니다. 범인 집 앞에 잠복해 있는 형사의 심정이라고 할까요.
디버깅을 의학에 비유한다면 내시경과 같습니다. 전신마취하지 않고 내시경 받아보셨나요. 아주 죽습니다. 디버깅도 프로그램을 한줄씩 살펴보는 작업이 동반되는데, 아주 고된 작업이 되기 쉽습니다.


debugging에서 알아야 할 용어들을 먼저 소개합니다.

• breakpoint : 중단지점입니다. 실행 모드가 아닌 디버그 모드에서 프로그램을 중지하게 되는 지점의 표시입니다.
  보통 ide에서 소스 라인 맨 앞 여백을 더블클릭하면 생깁니다. 다시 더블클릭하면 없어집니다. resume을 실행하면 다음 중단점을 만날 때까지 실행됩니다.
• step over : 한줄을 실행합니다. 함수가 있어도 실행 후 다음으로 넘어갑니다.
• step into : 함수 내부로 들어갑니다.
• step out : 함수를 끝까지 실행시키고 호출시킨 곳으로 되돌아 갑니다.
• resume : 디버그로 한 줄 한 줄 실행시키는 트레이스 모드를 그만두고 실행모드로 전환합니다.

일단 기본적인 용어는 이상과 같습니다. 디버거의 종류에 따라 확장된 기능들이 있지만 기능이 소개될 때 같이 언급하겠습니다.
다음은 자바스크립트 디버깅을 설명하기 위한 소스입니다.

소스 : debug1.html (UTF-8)

간단히 자바스크립트를 테스트할 수 있는 html과 javascript 코드입니다. input버튼을 클릭하면 doPrint() 자바스크립트 함수를 호출합니다.
디버깅을 위해서는 디버깅 도구가 필요합니다. firefox의 플러그인 firebug를 사용해보겠습니다.

소스1 debug1.html 파일을 만들고 firefox로 엽니다. 우측 하단의 firebug플러그인 활성화 영역을 클릭하여 그림1과 같이 firebug영역을 활성화합니다. 여러 개의 탭 중에서 Script 탭을 열면 HTML 소스와 함께 Script 소스들이 보입니다.

그림1 firebug script tab

디버깅은 쉽습니다. 그림2와 같이 JavaScript 함수의 내부인 14라인에서 앞쪽의 회색부분을 클릭하면 브레이크 포인트가 걸립니다. 디버그 준비 끝입니다.

그림2 JavaScript Debug Breakpoint

 
브라우저에서 버튼을 클릭하면 이 함수가 호출되는 소스인데 한 번 눌러보시면 화면에 브라우저 내의 객체들과 변수들이 그림3과 같이 firebug의 우측 패널에 나타납니다. 아울러 브레이크 포인트가 찍힌 곳에 화살표가 나타나면서 JavaScript의 실행이 중단 됩니다.

그림3 Debug start

id가 place인 element의 속성들을 확인할 수 있습니다. 여기서 디버깅을 계속하기 위해서 다음 아이콘들을 사용할 수 있습니다.

그림4 debug icons

하늘색 아이콘은 continue (F8) 입니다. resume 이라고 앞 서 설명드린 기능인데 다음 브레이크포인트를 만날 때까지 실행하게 됩니다. 만약 다음 브레이크포인트가 없다면 "기냥 고"가 되겠죠. ^^; 그 옆 아래로 향하는 아이콘은 Step Over (F10) 입니다. 한 줄 실행하고 대기하게 됩니다. 그 옆의 오른쪽으로 향하는 아이콘은 Step Into (F11), 라인에서 함수를 만나면 그 함수 안으로 비집고 들어가는 기능입니다. 그렇다면 나머지 한 개의 아이콘은 말 안해도 되죠? ㅎㅎ. 기냥 고?
삐질까봐 말씀드립니다. Step Out (F12) 인데 비집고 들어갔던 함수에 볼 게 없다면 나와야죠. 함수에서 밖으로 빠져나오게 됩니다.
흠... Step Over 를 실행해보죠. F10 키를 눌러도 됩니다. count 변수는 어디 숨었을까요? 함수 바깥에 있는 전역변수이기 때문에 this 안에 있습니다. 그림5를 참고하세요.

그림5 debug step over

to be continued...