서비의 다락방

대부분의 자바 프로그래머들은 JAR 파일의 기본 작동에 익숙하다. 하지만 JAR 파일 포맷의 막강한 힘을 아는 개발자는 드물다.

JAR 파일

JAR 파일 포맷은 대중적인 ZIP 파일 포맷을 근간으로 하여 많은 파일들을 하나로 모으는데 사용된다. ZIP 파일과는 달리 JAR 파일은 압축과 디스트리뷰션 뿐만 아니라 라이브러리, 컴포넌트, 플러그인 등의 전개와 캡슐화에도 사용되며 컴파일러나 JVM 같은 툴이 직접 사용하기도 한다. 전개 디스크립터 같이 JAR에 포함된 특별한 파일은 특정 JAR가 취급되는 방법을 툴에 지시한다.

JAR 파일은 다음과 같은 데에 사용된다:

JAR 파일 포맷은 많은 혜택과 기능을 제공하며 ZIP 또는 TAR 같은 전통적인 아카이브 포맷이 줄 수 없는 많은 것들을 제공한다. 이를 테면:

JAR의 압축과 압축풀기

jar 툴( jar 툴 참조)은 파일을 기본적으로 압축한다. 압축이 풀린 JAR 파일은 압축된 JAR 파일 보다 더 빠르게 로딩될 수 있다. 로딩 시간 동안 파일의 압축 풀기 시간이 줄어들기 때문이다. 하지만 네트워크를 통한 다운로드 시간은 압축이 풀린 파일이 더 길다.

META-INF 디렉토리

대부분의 JAR 파일에는 META-INF 디렉토리가 포함되어 있는데 이는 패키지의 저장과 보안 및 버저닝 정보 같은 확장 설정 데이터를 저장하는데 사용된다. META-INF 디렉토리의 파일과 디렉토리는 Java2platform에서 인식 및 인터프리팅되어 애플리케이션, 확장, 클래스 로더를 설정한다:

jar 툴

JAR 파일로 기본적인 태스크를 수행하려면 자바 개발 킷의 일부로 제공되는 Java Archive Tool (jar 툴)을 사용한다. jar 툴을 jar 명령어로 호출한다. 표 1은 일반 애플리케이션이다:

표 1. jar 툴의 일반적인 사용

위로

실행 JAR 파일

실행 JAR 파일은 특별히 설정된 JAR 파일에 저장된 독립적인 자바 애플리케이션이다. 파일을 추출하거나 클래스 경로를 설정하지 않고 JVM에 의해 직접 실행될 수 있다. 비 실행 JAR에 저장된 애플리케이션을 구동하려면 이를 클래스 경로에 추가하고 애플리케이션의 메인 클래스를 이름별로 호출해야한다. 하지만 실행 JAR 파일을 사용하면 이를 추출하거나 메인 엔트리 포인트를 알 필요 없이 애플리케이션을 실행할 수 있다.

실행 JAR 파일 만들기

실행 JAR 파일을 만들기는 쉽다. 모든 애플리케이션 코드를 하나의 디렉토리에 놓는 것으로 시작한다. 애플리케이션의 메인 클래스가 com.mycompany.myapp.Sample이라고 가정해보자. 애플리케이션 코드를 포함하고 메인 클래스를 구분하는 JAR 파일 생성이 필요하다. 이를 위해 라는 manifest 파일을 어딘가에(애플리케이션 디렉토리는 아니다) 만들고 여기에 다음 행을 추가한다:

Main-Class: com.mycompany.myapp.Sample

그런 다음 JAR 파일을 다음과 같이 만든다:

jar cmf manifest ExecutableJar.jar application-dir

실행 JAR 파일 시작하기

애플리케이션을 ExecutableJar.jar라는 실행 JAR 파일로 묶었으므로 다음 명령어를 사용하여 파일에서 직접 애플리케이션을 시작할 수 있다:

java -jar ExecutableJar.jar

위로

패키지 실링(sealing)

JAR 파일안에 패키지를 봉합(sealing)한다는 것은 이 패키지에 정의된 모든 클래스가 같은 JAR 파일에서 찾아져야 한다는 것을 의미한다. 이로서 패키지 작성자는 패키지된 클래스들의 버전 영속성을 강화할 수 있다. 봉합은 보안 조치도 제공하여 코드 탬퍼링을 탐지한다.

패키지를 봉합하려면 패키지용 Name 헤더를 추가한다. 그 뒤에 Sealed 헤더 값을 JAR manifest 파일에 대해 "true"로 한다. 실행 JAR 파일과 마찬가지로 manifest 파일을 적절한 헤더 엘리먼트로 지정하여 JAR를 봉합할 수 있다:

Name: com/samplePackage/
Sealed: true

Name 헤더는 패키지의 관련 경로명을 정한다. 파일이름과 구별되도록 "/"로 끝난다. Name 헤더에 뒤따르는 모든 헤더는 공백 라인 없이 Name 헤더에 지정된 파일이나 패키지에 붙는다. 위 예제에서 Sealed 헤더가 공백 라인 없이 Name 헤더 다음에 발생했기 때문에 Sealed 헤더는 com/samplePackage 패키지에만 붙는것으로 인터프리팅된다.

확장 패키징

확장은 자바 플랫폼에 기능을 추가한다. 확장 메커니즘은 JAR 파일 포맷에 구현된다. 확장 메커니즘으로 JAR 파일이 다른 필요한 JAR 파일들을 Class-Path 헤더를 통해 manifest 파일에 지정할 수 있다.

extension1.jar와 extension2.jar가 같은 디렉토리 안의 두 개의 JAR 파일에 있다고 가정해보자. extension1.jar의 manifest는 다음 헤더를 포함하고 있다:

Class-Path: extension2.jar

이 헤더는 extension2.jar의 클래스들이 extension1.jar의 클래스를 목표에 맞춘 확장 클래스로서 작용한다는 것을 나타내고 있다. extension1.jar의 클래스들은 extension2.jar가 클랫의 경로의 일부가 될 필요 없이 extension2.jar의 클래스를 호출할 수 있다.

예를 들어 ExtensionDemo 클래스를 레퍼런싱하는 ExtensionClient 클래스가 ExtensionClient.jar라고 하는 JAR 파일에 번들되었고 ExtensionDemo 클래스가 ExtensionDemo.jar에 번들되었다고 가정해보자. ExtensionDemo.jar가 확장으로 취급되기 위해서는 ExtensionDemo.jar는 ExtensionClient.jar의 manifest 안의 Class-Path 헤더에 리스트되어야 한다:

Manifest-Version: 1.0
Class-Path: ExtensionDemo.jar

위로

JAR 파일의 보안

JAR 파일은 jarsigner 툴을 사용하거나 java.security API를 통해서 직접 서명될 수 있다. 서명된 JAR 파일은 원래 JAR 파일과 정확히 같다. manifest만이 업데이트 된 것과 두 개의 추가 파일들이 META-INF 디렉토리에 추가된 것을 제외하고.

Keystore 데이터베이스에 저장된 인증을 사용하여 JAR 파일은 서명된다. Keystore에 저장된 인증은 패스워드로 보호된다.

JAR의 각 서명자는 JAR 파일의 META-INF 디렉토리안에 있는 .SF 확장자가 붙은 서명으로 표현된다. 이 파일의 포맷은 manifest 파일과 비슷하다. 메인 섹션과 개별 엔트리들로 구성되어 있다. 서명된 JAR에서 오는 파일을 확인하기 위해 서명 파일의 다이제스트 값은 JAR 파일의 상응 엔트리에 대비하여 계산된 다이제스트와 비교된다.

				Contents of signature file META-INF/MANIFEST.MF

Manifest-Version: 1.0
Created-By: 1.3.0 (Sun Microsystems Inc.)

Name: Sample.java
SHA1-Digest: 3+DdYW8INICtyG8ZarHlFxX0W6g=

Name: Sample.class
SHA1-Digest: YJ5yQHBZBJ3SsTNcHJFqUkfWEmI=

Contents of signature file META-INF/JAMES.SF

Signature-Version: 1.0
SHA1-Digest-Manifest: HBstZOJBuuTJ6QMIdB90T8sjaOM=
Created-By: 1.3.0 (Sun Microsystems Inc.)

Name: Sample.java
SHA1-Digest: qipMDrkurQcKwnyIlI3Jtrnia8Q=

Name: Sample.class
SHA1-Digest: pT2DYby8QXPcCzv2NwpLxd8p4G4=

디지틀 서명

디지틀 서명은 .SF 서명 파일의 서명완료된 버전이다. 디지틀 서명 파일은 바이너리 파일이며 .SF 파일과 같은 파일이름을 갖고 있지만 다른 확장이다. 확장은 디지틀 서명 유형에 따라 다양하고 (RSA, DSA, PGP). JAR 서명에 사용된 인증 유형에 따라 다르다.

Keystore

JAR 파일에 서명하려면 프라이빗 키를 가져야 한다. 프라이빗 키와 관련 퍼블릭 키 인증은 패스워드로 보호된 데이터베이스(keystores)에 저장된다. JDK는 Keystore를 구현 및 변경하는 툴을 포함하고 있다. Keystore의 각 키는 앨리어스에 의해 구분되는데 전형적으로 키를 소유한 서명자의 이름이다.

모든 Keystore 엔트리들은 고유 앨리어스로 액세스된다. 앨리어스는 Keystore에 엔터티를 추가할 때 keytool -genkey 명령어를 사용하여 지정되어 키 쌍을 만든다. 뒤따르는 keytool 명령어는 이와 같은 앨리어스를 사용하여 엔터티를 언급해야 한다.

예를 들어 "james"라는 앨리어스로 새로운 퍼블릭/프라이빗 키 쌍을 만들고 퍼블릭 키를 자가 서명된 인증으로 래핑하려면 다음 명령어를 사용한다:

keytool -genkey -alias james -keypass jamespass 
        -validity 80 -keystore jamesKeyStore 
        -storepass jamesKeyStorePass

jarsigner 툴

jarsigner 툴은 Keystore를 사용하여 JAR 파일에 대한 디지틀 서명을 만들거나 확인한다.

위 예제에서 처럼 "jamesKeyStore" Keystore를 만들었고 여기에 "james" 앨리어스와 키를 포함하고 있다고 가정해보자. 다음 명령어로 JAR 파일에 서명할 수 있다:

jarsigner -keystore jamesKeyStore -storepass jamesKeyStorePass 
          -keypass jamespass -signedjar SSample.jar Sample.jar james

이 명령어는 앨리어스가 "james"이고 패스워드가 "jamespass"인 키를 보내 Sample.jar 파일에 서명하고 SSample.jar라는 서명된 JAR를 만든다.

jarsigner -verify SSample.jar

위로

JAR 인덱싱(indexing)

애플리케이션 또는 애플릿이 다중의 JAR 파일들로 번들된다면 클래스 로더는 단순한 리니어 검색 알고리즘을 사용하여 클래스 경로의 엘리먼트를 검색한다. 클래스 로더가 존재하지 않은 리소스를 찾으려고 하면 애플리케이션 또는 애플릿 내의 모든 JAR 파일들은 다운로드 되어야한다. 큰 네트워크 애플리케이션과 애플릿의 경우 늦은 시작, 지연된 응답, 네트워크 대역 낭비를 초래한다.

JDK 1.3 이후 JAR 파일 포맷은 인덱싱(indexing)을 지원하여 네트워크 애플리케이션(특히 애플릿)의 클래스 검색 프로세스를 최적화했다. JarIndex 메커니즘은 애플릿 또는 애플리케이션에 정의된 모든 JAR 파일의 내용을 모아 첫 번째 JAR 파일의 인덱스 파일에 이 정보를 저장한다. 첫 번째 JAR 파일이 다운로드된 후에 애플릿 클래스 로더는 모아진 콘텐트 정보를 사용하여 JAR 파일을 효율적으로 다운로드한다. 이 디렉토리 정보는 INDEX.LIST라는 이름으로 간단한 텍스트 파일로 저장된다.(META-INF 디렉토리).

JarIndex 만들기

그림 2. JarIndex

다음 명령어를 사용하여 JarIndex_Main.jar, JarIndex_test.jar, JarIndex_test1.jar용 인덱스 파일을 만든다:

jar -i JarIndex_Main.jar JarIndex_test.jar SampleDir/JarIndex_test1.jar 

INDEX.LIST 파일은 간단한 포맷을 갖고 있으며 색인된 JAR 파일에 저장된 패키지 또는 클래스 이름을 포함하고 있다.(Listing 2):

JarIndex-Version: 1.0

JarIndex_Main.jar
sp

JarIndex_test.jar
Sample

SampleDir/JarIndex_test1.jar
org
org/apache
org/apache/xerces
org/apache/xerces/framework
org/apache/xerces/framework/xml4j

가사를 살짝 음미해 볼까요..

グラウンド驅けていく
운동장을 달려가는

あなたの背中は
너의 그 등이

空に浮かんだ雲よりも自由で
하늘의 구름보다 자유로워서

ノ-トにならんだ
노트에 써 있는

四角い文字さえ
네모난 글자들까지

すべてを照らす光に見えた
모든 걸 비추는 빛으로 보였어


好きという氣持が
좋아한다는 마음을

解らなくて
이해할 수 없어서

二度とは戾らない
두 번다시 돌아오지 않을

この時間が
지금의 시간에게

その意味を私に敎えてくれた
그 의미를 하나하나 배웠어


あなたと過ごした日日を
너와 함께 보낸 날들을

この胸に燒き付けよう
내 가슴에 새겨넣자

思い出さなくても
다시 떠오르지 않더라도

大丈夫なように
상관없을 정도로

いつかほかの誰かを
언젠가 다른 누군가를

好きになったとしても
좋아하게 되더라도

あなたはずっと
너만은 언제까지나

特別で
특별해서

大切で
너무 소중해서

またこの季節が巡ってく
또 이 계절이 돌아올 거야




はじめて二人で話した放課後
처음으로 둘이 얘기했던 방과후

誰も知らない笑顔探していた
아무도 모르는 미소를 찾고있었어.

遠くであなたのはしゃいでる聲に
멀리서 들리는 너의 목소리에

なぜだか胸が痛くなったの
왜인지 가슴이 메어왔어


變わってゆく事を怖がってたの
변해가는게 무서웠어

ずっと友達のままいれる氣がした
항상 친구로 있어줄것만 같았어

終わってく物など無いと思った
끝나는것 따위 없다고 생각 했어.

果てしない時間の中であなたと出會えた事が
끝없는 시간속에 너와 만난게

何よりもあたしを强くしてくれたね
무엇보다 날 강하게 해 줬어

夢中でかける明日にたどり着いたとしても
정신없이 달려 내일이 온다해도

あなたはずっと
너만은 언제까지나

特別で
특별해서

大切で
너무 소중해서

またこの季節がやってくる
또 이 계절이 찾아올 거야




いつまでも忘れないとあなたが言ってくれた夏
절대 잊지않겠다고 말해줬던 여름

時間が流れ今頃あたしは淚がこぼれてきた
시간이 흘러 이제와 참을수없는 눈물이 흘러

あなたと過ごした日日をこの胸に燒き付けよう
너와 함께했던 날들을  가슴에 세겨두자

思い出さなくても
다시 떠오르지 않더라도

大丈夫なように
상관없을 정도로

いつかほかの誰かを
언젠가 다른 누군가를

好きになったとしても
좋아하게 되더라도

あなたはずっと
너만은 언제까지나

特別で
특별해서

大切で
너무 소중해서

またこの季節が巡ってく
또 이 계절이 돌아올 거야

원문 출처 : http://www.netbeans.org/kb/samples/rapid-ruby-weblog.html?me=1
입니다. 원문에 대한 저작권자는 제가 아니며 이글은 위 아티클에대한 2차 가공물임을
알려드립니다.



한 때 (지금도 여전하지만 ) 루비온 레일로 10여분만에 뚝딱하고 블로그를 생성하던
스크린캐스팅을 보고 경악을 금치 못했던 기억이 새록새록하군요.
(비록, 실제개발에서 얼마나 유용할지에 대한  그런 보여주기식의 스크린캐스팅에 심기가 불편하신 분들도 분명 계시겠지만요.)

netbeans.org 아티클 중에 넷빈즈와 jdk6.0상에서 루비를 이용하여 이와같은 작업을 해내는 기사가 있어 포스팅 합니다.

준비물은 JDK 6 과 NetBeans IDE 6.0 Milestone 8 그리고 Ruby Pack(넷빈즈에 포함) 입니다.

항목들 참 많기도 하다...

큰 카테고리별로 보면

Building : Ant 설정 항목이다. 넷빈즈 4.1은 Ant 1.6.* 대를 번들 하고 있으며 이곳에서
              다른 버전의 Ant를 설정 한다. 참고로 Ant 스크립트까지 여기서 설정 하진 않는다.
              구체적인 Ant 스크립트는 프로젝트를 생성 한 후 각 프로젝트 별로 설정 한다.
Collaboration : 넷빈즈 4.1 부터 번들되기 시작한 모듈로 넷빈즈에 채팅 기능이 들어가 있다고
               생각 하면 된다.. 하지만 IDE에 단순 채팅 기능이 들어가 있다면 큰 의미가 없을 것이다.
               Collaboration 은 다른 넷빈즈 개발자와 함께 같은 소스를 공유하고 함께 수정,컴파일,
               실행 해 볼 수 있다.. 자리를 바꿔가며 개발하는 XP가 아닌 자신의 PC에서 원격의
               상대방과 함께 진행하는 XP가 가능하다.
Editing : 말 그대로 IDE에 있는 편집기에 대한 각종 설정을 할 수 있다.
IDE Configuration : IDE메뉴와 메뉴아이콘에 대한 설정이 들어있으며 메뉴의 이동 삭제 추가 등을
                설정 한다.
Source Creation and Managemenrt : 각종 소스 타입에 따른 템플릿과 버전관리 시스템을
                관리한다.  기본적으로 등록되어 있는 템플릿만 100여개 남짓하며, 물론 기존 템플릿을
                수정 하거나 자신만의 템플릿을 등록 하는것도 가능하다.
                버전관리 시스템은 기본적으로 CVS, PVCS, Visual Source Safe 를 사용 할 수 있도록
                준비 되어 있다.
Testing : 넷빈즈에는 JUnit이 번들되어 있어 별다른 설정없이 유닛 테스트가 가능하며
               Update Center ( http://www.yunsobi.com/tt/subby/37 )를 통해
               NetBeans Extention JUnit 이나 Jellytools, Jemmy Module 같은
               3rd-party 테스트 모듈을 추가 할 수 있다.

위 에서 각 옵션 항목에 대해 간략 히 소개 했다.. 이번 강좌에서 저 몹션들을 모두 다루는건
무리일 것이다. 이번 강좌에는 넷빈즈를 처음열고 꼭 수정해야만 한다고 생각되고, 개발자들이
IDE에서 가장 많이 접하는 Editing 항목만 다루려한다.
나머지 부분은 강좌를 진행하면서 필요할 경우 그때그때 언급하기로 하겠다.

Editing - Editor Settings 항목을 펼치면 각 파일 타입에 대한 항목을 볼 수 있다.

오른편의 Global Key Bindings 항목을 연 화면이다.
소스를 편집하는 데 필요한 기능과 그에대한 단축키를 설정 할 수 있다.

파일 타입에 해당하는 Editor 항목을 열면 오른편 메뉴에서 Abbreviations 항목을 설정 할 수 있다.
말그대로 약어를 등록 해둘 수 있다. 위 화면을 예로들자면  
CSS파일 편집시 에디터에  bg 라고 타이핑 하면 background: 로 대치된다.

여기서 취향에 맞는 폰트와 색상을 지정하면 된다.  기본적으로 Monospaced 12 Plain

폰트를 사용하고 있다. Monospaced 폰트가 마음에 들지 않는 사람이라면 왼편 신택스 항목의
첫번째 Default 항목에서 Font를 수정하면 모든 신택스에 대해 일괄적으로 변경이 적용되며
각 신택스에 대한 고유한 설정은 신택스 항목을 선택하고 따로 변경 해 주면 된다.
위 화면에서 예시한 Java Keyword의 경우 bold의 Monospaced 라 글자를 알아보기 힘들다.
오른편 폰트 에어리어 아래쪽의 Inherit 항목을 체크하면 Default 항목으로 선택되어 있는
Font 항목이 적용 된다.
Background color 나 Foreground color 역시 각각 설정 가능하며 Inherit 항목을 체크 해
Default 값을 적용 할 수도 있다.

Java Keyword의 Font를 Default font인 Monospaced plain 을 inherit 했다.폰트가 깔끔해 졌다.
HTML,JSP,XML 역시 위와 같은 방법으로 원하는 형태로 에디터를 설정 하면 된다.

자.. 여기서 끝이 아니다. 한가지 더 짚고 넘어갈게 있다.
이 상태에서 프로젝트를 생성해서 에디터를  열고 소스를 편집하면 잘 눈 치채지 못하지만
사용하다보면 '어, 이거 왜 이렇게 해놨지?' 하고 생각 하게되는 부분이 있다.

보통 다른 편집기에서 tab 키를 일반 공백문자 4칸 혹은 8칸 크기로 설정해서 사용 할것이다.
넷빈즈의 경우도 다르지않다. 디폴트로 4칸의 공백문자 크기를 갖는데 문제는 에디터에서
tab 키를 누르면 공백문자 크기만큼 커서가 전진 하지만 tab문자로 전진하지 않고
space bar 를 네번 눌러 전진 한것처럼 동작한다.

혼자 개발 할때는 별 문제 될게 없다. 넷빈즈 에디터에서 열면 들여쓰기가 잘 된걸로 표현
될테니까..  하지만 보통은 협업으로 이루어지며, 다른 개발자도 넷빈즈를 사용한다고 볼 순 없다.
넷빈즈에서 에디팅한 소스를 다른 개발자가 다른 편집기에서 열어보면 짜증을 낼거다.
code indent는 잘 맞추어져있는데 탭을쓰면되는 곳에 왜 스페이스로 들여쓰기를 했냐고..
이 부분은 Editing - Indentation Engines 항목을 통해 교정이 가능하다.

Editing - Indentation Engines - Java Indentation Engine 항목을 클릭하여 오른편 Properties 항목을 보자.
첫번째 항목으로 Expand Tabs to Spaces 항목에 체크 되어 있다. 이 체크를 해제하면 비로소
tab 이 여타의 편집기에서 tab 키를 누른것처럼 기록 될 것이다.
항목 맨 아래쪽의 Statement Continuation Indent 는 여러줄에걸친 코드에서 다음줄로넘어간
경우 처음 탭 크기를 설정하는 부분이며
Number of Spaces per Indent 는 우리가 일반적으로 알고있는 tab에대한 space사이즈 설정부분이다.

마지막으로 짚고 넘어갈게 개발하다보면 자바소스를 특별히 인코딩 방식을 주어 개발해야하는 상황이 종종 발생한다.

Editing - Java Sources 에서 오른편 Default Encoding 항목에서 설정 할 수 있지만 특별한 경우가 아니라면 이곳에 인코딩 설정을 하는것은 추천하지 않는다.
지금까지 살펴본 옵션사항은 각각의 프로젝트에 따르게 적용되는부분이 아닌 넷빈즈 전체에 관한
설정이기 때문이다. 특별히 java 소스에 대한 인코딩이 필요한 프로젝트라면 프로젝트 생성 후
각 프로젝트에 대한 컴파일 인코딩옵션을 설정하는( -encoding UTF-8 , 이 방법 또한 이후 강좌에서 언급하겠다. ) 방식을 추천한다.

---------------------------------------------------------------------------

넷빈즈로 코드 한번 끄적여보기까지 많은 과정을 거쳐왔다...
여기까지가 준비 되었다면 프로젝트를 생성하고 코드를 작성 할 기본적인 준비가 되었다고 할 수 있다.
다음번 강좌부터는 본격적으로 코드와 함께 프로젝트 생성을 다루어 볼까 한다.

ps. 개인적인 지식에는 한계가 있기 마련입니다. 제가 잘못 생각하고 있거나 다른점이 있다면
바로바로 알려주세요.

교육의 목적으로 JAVA 코드를 작성해 보는게 아니라면(그렇다고 해도 역시 마찬가지지만)JAVA 개발에는 JDK외에 많은 외부 라이브러리를 가지고 개발을 진행한다.
외부 라이브러리의 클래스를 사용한 자바소스를 컴파일 하기 위해 환경변수 설정에 classpath 를 등록 하게 되는데..(너무 기본적인 내용이라 굳이 더 이상 언급하지 않겠다.)IDE를 사용 하게 되면 굳이 환경변수를 바꾸거나, 혹은 classpath 를 설정하는 배치 파일을 작성 할 필요가 없다.(심지어 환경변수에 classpath를 등록 할 필요조자 없다.)

이번 강좌에서는 넷빈즈에 외부라이브러리들을 등록하는 방법을 알아보자.
물론 이전 포스트에서 여러버전의 jdk를 등록하는게 가능했던것처럼 동일라이브러리라도
버전별로 혹은, 프로젝트에 필요한 라이브러리 단위등으로 관리 할 수 있음은 당연하다.

넷빈즈는 JDK를 플래폼 매니저가 관리한다면 외부라이브러리는 Library Manager 가 담당한다.
 

 Tool -> Library Manager 매니저를 선택하여 라이브러리 매니저로 이동한다.

  기본적으로 래이아웃, JSTL, JUnit 관련 라이브러리가 등록 되어 있다. 화면 하단의 New Library... 버튼을 클릭하여 라이브러리 등록 창을 연다.

 

라이브러리 매니저에서 관리할 라이브러리의 대표이름을 적는다.

새로 등록 한 라이브러리 이름을 선택하고 좌측의 classpath탭에서 Add JAR/Folder... 를 선택한다.

앞서 설정한 랑브러리 명칭에 포함해야 하는 jar 혹은 디렉토리를 하나 혹은 복수개를 선택하여 등록한다.

JAKARTA_COMMONS 라는 이름으로  자카르타 커먼스 프로젝트의 라이브러리 10개를 등록 했다.

JDK설정 편( http://www.yunsobi.com/tt/subby/38 )에서 했던것과 마찬가지로 해당 라이브러리에 대한 javadoc들을 등록한다.

숨바꼭질이라는 뜻의 카쿠렌보..
2004년 6월경에 출시한 24분짜리 단편 애닌데 이제야 감상하게 됐다.

특이한 점은 모든 화면구성을 3D로 처리한 후 카툰렌더링을 하여 2D 느낌이 나도록 구성 했다는 점이다.

(지금이야  카툰렌더링이 광고, 게임, PV등 다방면에서 쓰이고 있으니 뭐 그다지 새로운 기법은 아니다.)

제목은 숨바꼭질지만.. 장르는 어울리지 않게 호러물이다..
호러라고 해도 정말 오싹한 호러물은 아니다.

일본인에겐 익숙한 카미카쿠시를 숨바꼭질이란 소재에 적용하였고 등장하는 오니(우리말에 딱 들어맞는 대상이 없다. 도깨비 정도가 가장 어울릴까 )
들을 멋들어지게 표현하고 있어서 보는 내내 지겹지 않다.

다 보고나면 결말에 약간 아쉬움이 남을수도 있지만 독특한 소재의 애니를 찾는 사람이라면한번 볼만 할 듯,

자료를 찾다보니 작년 7월 21일 [kbs 독립영화관] 이란 프로그램에서 별의 목소리와 함께 카쿠렌보를 방영 했더랬다.
(관련 url : http://www.kbs.co.kr/1tv/enter/shortfilm/preview/index.html )

태터데스크 베타테스트 이벤트
"태터데스크와 함께라면 나도 편집장"

태터데스크 베타테스터에 응모하세요~  
응모자 중 100분을 추첨해 태터데스크를 2주간 우선적으로 사용해 보실 수 있는 기회를 드립니다.  베타테스터 전원에게 태터툴즈 기념품을, 우수 테스터 33명을 선정해 닌텐도 DSLite, 몰스킨 다이어리 등 푸짐한 상품을 드립니다~

<응모방법>아래의 빈 칸에 들어갈 문구를 채워서 완성된 문장을 여러분의 블로그에 올리신 후, 이 글에 트랙백 보내주세요. 태그는 '태터데스크' 입니다.

정답 힌트는 여기에..  :-)

원문 출처 : http://www.ibm.com/developerworks/kr/library/j-ajaxee/index.html

비동기식 통신 모델과 동기식 통신 모델을 효과적으로 혼합하기

IT 전문가 Patrick Gan이 Ajax 기술을 Java EE 웹 애플리케이션에 적용할 때 전체적인 개발 과정 속에서 발생할 수 있는 문제들을 점검합니다. 패턴에 기반하고 있는 Ajax의 비동기식 통신을 채택할 때의 문제들을 파악하는 것이 효과적인 Ajax 통합의 지름길입니다.

Asynchronous JavaScript + XML (Ajax)은 매우 새로운 기술이다. Java EE 커뮤니티를 비롯한 많은 웹 개발 커뮤니티에서 이에 대한 많은 소문들이 만들어지고 있다. Ajax 기술은 과도한 웹 페이지 리프레쉬를 줄임으로서 애플리케이션 가용성을 향상시키고 있다. 그리고 Ajax의 best-of-both-worlds 접근 방식은 클라이언트 측 코드와 서버 측 코드를 활용하여 웹 사용자에게 거의 완벽한 UI를 제공하고자 한다. Ajax는 웹의 부활(Web 2.0)에 있어 핵심 인에이블러로서 간주되고 있다.

부지런한 Java EE 개발자라면 아마도 Ajax에 대한 많은 하우투 문서를 섭렵하고 이것이 여러분의 애플리케이션에 가져올 향상에 대해서도 기대했을지 모른다. 하지만 어떻게 Ajax의 비동기식 통신 기반 패턴이 Java EE 애플리케이션에 맞을까? 이 글에서는 Java EE 애플리케이션의 디자인, 개발, 퍼포먼스, 테스팅에 Ajax를 채택했을 때 미치는 영향을 검토하여 해결책을 모색하고자 한다. 이렇게 하는 이유는 Ajax 사용을 금하려는 것이 아니라, 오히려 Ajax를 효과적으로 사용할 수 있도록 문제들을 해결하려는 것이다.

디자인 문제점

자바 커뮤니티는 좋은 디자인 패턴들을 웹 관련 애플리케이션 개발에 적용하려고 부단히도 애썼다. 가장 광범위하게 사용되는 패턴들 중 하나가 Model-View-Controller (MVC)이다. Apache Struts 같은 여러 오픈 소스 프레임웍들은 이러한 디자인 패턴/아키텍처에 기반하고 있다. (참고자료) MVC의 많은 장점들 중에는 관심의 분리(separation of concerns)와 과잉 코드의 감소를 들 수 있다.

관심의 분리를 통해, 애플리케이션 아키텍처에서 사전에 협상된 인터페이스를 사용하면서 각 개발자는 애플리케이션 개발 프로젝트에서 지정된 역할에만 집중할 수 있다. 예를 들어, 모델-레이어 개발자들은 JDBC, Enterprise JavaBeans (EJB), 데이터 영속성 기술과 관련 있는 자바 클래스 같은 기술에 초점을 맞춘다. 뷰-레이어 개발자들은 JavaServer Pages (JSP), 태그 라이브러리, 기타 표현 관련 기술에 초점을 맞춘다. 컨트롤러 레이어는 모델과 뷰 사이를 구분 및 중재하고 인커밍 요청들을 백엔드 호출로 라우팅 하면서 관심들을 깨끗하게 분리한다. 그림 1은 MVC 아키텍처 모습이다.

그림 1. MVC 아키텍처

Ajax를 Java EE 웹 애플리케이션에 도입하는 것에는 관심의 분리라는 의미가 내포되어 있다. (따라서 개발자 역할도 분리된다.) 어떤 경우, Ajax는 많은 양의 JavaScript 코드를 뷰-레이어(JSP) 페이지에 도입한다. 표 1은 Ajax가 적용되지 않은 MVC 뷰 레이어와 필요한 코드를 설명한다. 컨트롤러 레이어는 서블릿으로 구현되고 뷰 레이어는 JSP로 구현된 것으로 간주된다. (다음 개발 딜레마 처리하기 섹션에서는 동기식 요청과 비동기식 요청간 차이점을 설명하겠다.)

표 1. Ajax가 적용되지 않은 MVC: 전형적인 뷰-레이어 시퀀스와 관련된 코드 분량

Ajax를 이용한 MVC 뷰 레이어를 나타내는 표 2와 표 1을 비교해보자. 여기에서도 마찬가지로 컨트롤러 레이어는 서블릿에 의해 구현되고 뷰 레이어는 JSP로 구현된다.

표 2. Ajax를 이용한 MVC: 전형적인 뷰-레이어 시퀀스와 관련된 코드

Ajax를 사용하면서 뷰 레이어에서의 스크립팅 코드의 양이 증가하는 것을 볼 수 있다. 세 가지 큰 단점이 있다.

• JSP는 많은 JavaScript 코드를 필요로 한다.
• 디자인은 역할 영역의 분리를 무시한다.
• 디자인이 통합된 monolithic JSP (Model 1 접근 방식: 많은 HTML, CSS 코드, 이미지, 스크립팅 코드)를 사용한다. 이는 읽고 관리하기가 매우 까다로운 반패턴이다. (참고자료)

이러한 디자인 상의 단점을 피하거나 최소한 완화시킬 수 있는 여러 옵션들이 있다:

• 재사용을 고려한 디자인: Ajax의 스크립팅 코드는 피하기 힘들다. 스크립팅 코드를 기획 및 설계하여 최대한 재사용할 수 있도록 한다.
  
  
• 클라이언트 측에 MVC 방식 채택: 클라이언트 측에 MVC 방식 (Ajax in Action - 참고자료)을 사용할 수 있다. 이 방식은 관심의 분리 측면에서는 효과를 거둘 수 있지만 복잡해 질 수 있기 때문에 충분히 고려해야 한다.
  
  
• Ajax 프레임웍 사용: Direct Web Remoting (DWR)(참고자료) 같은 여러 오픈 소스 Ajax 프레임웍들은 최소한의 코딩으로도 Ajax 패턴을 Java EE 애플리케이션으로 잘 통합한다.
  
  
• 디자인의 유효성에 대한 재평가: Ajax는 웹 애플리케이션에 데스크탑 애플리케이션 애트리뷰트를 제공한다. 주어진 웹 애플리케이션에서 클라이언트 측 인터랙션 대부분이 Ajax를 활용한다. 애플리케이션은 데스크탑 애플리케이션으로서 보다 더 잘 설계될 것이다.

위로

개발 딜레마 처리하기

자바 웹 개발에 Ajax를 사용할 때 동기식(synchronous) 통신 모델과 비동기식(asynchronous) 통신 모델의 차이를 완전히 이해하는 것이 중요하다. (참고자료) 비동기식 통신 모델의 지원 부족은 클라이언트 측 개발, 웹 프레임웍과의 통합, 태그 라이브러리의 사용, IDE 사용, 쓰레딩 작동에 영향을 미칠 수 있다.

동기식 요청/응답 통신 모델에서 브라우저(웹 서버, 애플리케이션 서버, 웹 애플리케이션에 반(反)하는 개념)는 언제나 요청을 초기화 한다. 한편, 웹 서버, 애플리케이션 서버, 웹 애플리케이션은 인커밍 요청에 대응한다. 동기식 요청/응답 쌍이 처리되는 동안 사용자는 브라우저를 사용할 수 없다.

그림 2는 전통적인 웹 애플리케이션의 동기식 통신 모델을 나타내는 시퀀스 다이어그램이다. 서버의 생명 주기에서 클리어언트의 데이터 제출과 서버 측 프로세싱은 강결합 된다.

그림 2. 동기식 통신 시퀀스

비동기식 요청/응답 통신 모델에서, 웹 서버, 애플리케이션 서버, 웹 애플리케이션에 대한 브라우저 간 통신은 결합력이 약하다(decouple). 비동기식 요청/응답이 처리되는 동안 웹 사용자는 브라우저를 계속 사용할 수 있고 동시에 비동기식 요청이 처리된다. 비동기식 요청 프로세싱이 완료되면 비동기식 응답이 (웹 서버, 애플리케이션 서버, 웹 애플리케이션 에서) 클라이언트 페이지로 간다. 일반적으로 이 프로세스 동안에 실행은 웹 사용자들에게는 어떤 영향력도 없다. 응답을 기다릴 필요가 없다.

그림 3의 시퀀스 다이어그램은 비동기식 통신 모델을 묘사한 것이다. 첫 번째 dataSubmission(서버 측 프로세싱)과 리턴된 dataSubmission 모두 빨간색 원이 그려져 있다. 이 시퀀스들은 분리되어 있다. 이 그림에서는 중요한 요소들을 강조하고 있다. (쓰레딩 문제 참조) 다시 말해서 이 모드에서 다중 제출(쓰레드)가 빈번히 일어날 것 같다.

그림 3. 비동기식 통신 시퀀스

클라이언트 측에 미치는 영향

Ajax를 웹 애플리케이션에 도입할 때 개발 팀은 여러 가지 함정을 조심해야 한다. 대개는 생성된 HTML 페이지와 이것이 브라우저와 인터랙팅 하는 방식과 관련되어 있다. 이러한 문제들은 Chris Laffra의 Considering Ajax 시리즈에 잘 설명되어 있다. (참고자료)

• 스크립팅이 실행되지 않을 수 있다: 여러 가지 다양한 이유로 인해, JavaScript는 많은 사용자 브라우저에서는 실행되지 않는다.
  
  
• 크로스 브라우저 지원 때문에 많은 코드가 필요하다: 여러 브라우저들과 브라우저 버전들을 지원하는 애플리케이션은 스크립팅 코드가 많아져야 한다. 브라우저가 DOM 엘리먼트(그리고 그러한 엘리먼트를 연산하는 자바 스크립트 코드)를 인터프리팅 하는 방식에 미묘한 변수들이 존재하기 때문이다.
  
  
• JavaScript는 안전하지 않다: 대부분의 브라우저에서, HTML 페이지와 제휴된 JavaScript 소스 코드는 뷰 소스 옵션을 선택하면 볼 수 있다. Ajax 패턴을 사용할 때 스크립팅 코드의 로직이 민감하지 않은지를 확인해야 한다.

웹 프레임웍과의 통합

Ajax 개발을 자신의 Java EE 웹 프레임웍과 통합하려는 시도는 자연스러운 현상이다. 하지만 몇몇 Java EE 웹 프레임웍은 비동기식 통신 모델을 지원하지 않는다. 서블릿이 동기식 통신과 비동기식 통신을 처리하는 방법을 이해해야 한다. 그림 4는 전통적인 서블릿이 동기식 요청을 처리하는 모습이다.

그림 4. 동기식 요청을 처리하는 서블릿 시퀀스

그림 4는 Java EE 웹 개발자에게는 익숙할 것이다. 브라우저에서 온 요청이 처음에는 컨트롤러 서블릿의 service()에 의해 처리된다. 서블릿은 필요한 값을 HttpRequest (매개변수 또는 애트리뷰트로서)를 가져올 수 있다. 컨트롤러 프로세싱이 처리되면 결과는 HttpRequest (또는 HttpSession)로 보내지고 RequestDispatcher는 컨트롤을 페이지로 전달한다.

그림 5는 비동기식 요청을 처리하는 서블릿 시퀀스이다:

그림 5. 비동기식 요청을 처리하는 서블릿 시퀀스

그림 5의 시퀀스는 동기식 시퀀스와는 약간 다르다. 브라우저에서 온 요청은 처음에는 컨트롤러 서블릿의 service()에 의해 처리된다. 이 서블릿은 필요한 모든 값을 HttpRequest (매개변수 또는 애트리뷰트로서)에서 가져올 수 있다. 일단 컨트롤러 프로세싱이 끝나면 HttpServletResponse의 콘텐트 유형이 XML로 설정되어야 한다. 또한 컨트롤러 로직의 결과는 PrintWriter로 작성된다. 이 시점에서 RequestDispatcher의 사용이 바이패스(bypass)된다.

이것은 대부분의 Java EE 웹 프레임웍이 지원하지 않는 정확한 (비동기식) 시퀀스이다. 이것 때문에 Ajax와의 통합이 어렵게 된다. 비동기식 통신 모델을 지원하지 않는 포틀릿과 JavaServer Faces (JSF) 프레임웍도 같은 상황에 처해있다.

이러한 문제를 해결할 수 있는 몇 가지 옵션이 있다:

• 웹 프레임웍과의 공존: 빌트인 Ajax 지원을 기다리거나 자신의 프레임웍에 Ajax를 강제적으로 지원하는 대신 개별 서블릿으로 모든 비동기식 요청들을 처리할 수 있다. DWR이 이 방법을 사용한다. 이 방식의 단점은 Ajax 요청이 프레임웍의 기능들을 쉽게 활용할 수 없다는 점이다.
  
  
• 웹 프레임웍과 통합하기: 확장을 사용하거나 커스텀 확장을 작성하여 웹 프레임웍과 통합할 수 있다.
  
  
• Ajax를 지원하는 프레임웍으로 마이그레이션: 새로운 프레임웍이 비동기식 통신 모델을 지원하기 시작했다. 이중 하나가 Apache Shale 이다. (참고자료)

태그 라이브러리

자바 웹 애플리케이션 개발 시 일반적으로 태그 라이브러리(taglibs)를 많이 사용한다. 많은 Java EE 웹 프레임웍과 마찬가지로 taglibs는 비동기식 통신 모델을 지원하지 않는다. XMLHttpRequest를 통해서 제출된 데이터를 HttpServletRequest로 트랜슬레이트 할 방법이 없다. 본질적으로 비동기식 통신을 지원하지 않는 taglibs는 Ajax XMLHttpRequest 호출이 실행되는 동안 기능을 하지 않는다. 여러분에게 주어진 옵션은 다음과 같다.

• 비동기식 모델을 지원하지 않는 taglibs를 사용하지 않는다: taglibs로 만든 코드를 HTML/JavaScript 코드로 마이그레이션 한다. (웹 애플리케이션이 taglibs에 많이 의존하는 경우 이 방법을 사용하면 뷰-레이어의 페이지 크기만 늘어난다.)
  
  
• 문제를 해결한다: 이 문제에 대한 해결책을 갖고 있는 Ajax 프레임웍을 사용한다. 그 한 가지 예가 DWR이다. (ExecutionContext.forwardToString() 참조) 이 경우 여러분이 사용했던 taglibs를 계속 사용할 수 있다.
  
  
• Ajax 지원 taglibs를 사용한다: Ajax JSP Tag Library (AjaxTags) 같은 비동기식 모델을 지원하는 taglibs를 사용한다. (참고자료)

IDE를 이용한 개발과 디버깅

많은 JavaScript 디버깅 툴은 JavaScript 솔루션을 개발할 때 도움이 된다. 하지만 전통적인 자바 개발 환경에서는 XMLHTTPRequest의 가치와 Ajax와 관련된 특징을 확인할 수 없다.

한 가지 방법은 AJAX Toolkit Framework (ATF) (참고자료)을 사용하는 것이다. ATF는 강화된 JavaScript 에디팅 기능을 갖춘 Eclipse 플러그인이다. 편집 시 신택스 검사를 할 수 있고, Mozilla 웹 브라우저, DOM 브라우저, JavaScript 디버거 등이 내장되어 있다. ATF에는 Personality Builder가 있는데 이것은 임의의 Ajax 런타임 프레임웍용 IDE 기능의 구현에 도움이 되고 ATF에 있는 런타임 환경에 추가된다.

쓰레딩 문제

전형적인 동기식 웹 애플리케이션에서 버튼이나 링크 클릭에 다소 긴 처리 시간이 필요하다. 인내심이 없거나 경험이 없는 웹 사용자들은 버튼과 링크를 한 번 이상 클릭하여 여러 개의 폼 제출을 실행하곤 한다. 이것이 프로세싱 속도를 높일 것이라고 생각하면서 말이다. 사용자들은 (데스크탑 애플리케이션 처럼) 더블 클릭이 필요하다고 생각한다. 웹 애플리케이션에서의 여러 폼 제출은 어떤 경우에는 무해하다. 하지만 어떤 경우에는 심각한 쓰레딩 문제나 경쟁 조건(여러 쓰레드가 코드 블록의 실행을 위해 경쟁하는 것)을 야기할 수 있다. 예를 들어, 뱅킹 애플리케이션에서 Transfer Funds 버튼을 여러 번 클릭하면 원치 않는 다중 이체 결과를 초래할 수 있다.

동기식 통신 모델과 비동기식 통신 모델 모두를 지원하는 웹 애플리케이션은, 기능이 올바르게 분석 및 기획되지 않으면, 비슷한 문제에 봉착한다. 두 개의 통신 모델을 지원하는 애플리케이션은 해당 페이지에서 서버 측 호출을 혼합한다. (완전한 동기식, 완전한 비동기식, 동기식과 비동기식의 혼합). 여러 번 클릭되는 상황에서 비동기식 호출은 보다 느리게 처리된다. 애플리케이션이 이를 방지하지 않는다면 사용자는 비동기식 쓰레드가 처리되고 있는 동안 동기식 호출을 처리한다. 이 페이지는 리프레시 되지 않아 페이지가 더 이상 작동하지 않기 때문이다. 웹 페이지상의 같은 버튼이나 링크에서 나오지 않았더라도 같은 상황이 서버 측 코드에 쓰레딩 문제를 야기할 수 있다. (다중 클릭 문제와 비슷함)

뱅킹 애플리케이션의 자금 이체 페이지 예를 들어보자. (그림 6)

그림 6. 자금 이체 예제

빨간색 Transfer Funds 버튼은 Ajax 호출을 실행한다. Logout 링크(노란색)는 동기식 호출을 실행한다. 성급하거나 경험이 없는 사용자는 빨간색 버튼과 노란색 링크를 연속적으로 클릭하면 (그리고 두 링크 모두 공통 경로를 갖고 있다고 생각한다면) 경쟁 조건이 발생한다.

일반적으로 이러한 상황을 방지할 수 있는 두 가지 방법이 있다. 첫 번째는 클라이언트 측 솔루션이다. 링크나 버튼이 실행되면 JavaScript를 사용하여 추가의 페이지 제출이 현재 쓰레드가 실행을 종료할 때까지 금지되었는지를 확인한다. 두 번째 솔루션은 서버 측 코드의 동기화에 의존하여 경쟁 조건을 지키면서 멀티 쓰레드 제출을 허용하는 것이다. 이 문제를 해결할 때 동기화를 적용한다면 Java EE 웹 컴포넌트(서블릿, 포틀릿, JSF)가 멀티 쓰레딩 된다. 코드의 큰 섹션을 동기화 할 때 주의하라. (특히 요청/응답 프로세싱과 관련된 코드) 실제로, 동기화를 잘못 사용하면 애플리케이션이 싱글-쓰레드 애플리케이션으로 변하고 쓰루풋도 줄어든다.

위로

퍼포먼스 함정 피하기

Ajax를 사용하면 Java EE 웹 기반 애플리케이션의 퍼포먼스에도 영향을 미친다. 요청 당 추가 쓰레드를 허용하게 되면 두 가지 리소스가 영향을 받는다.

우선, 서블릿 컨테이너에 있는 쓰레드 풀(thread pool))이 영향을 받는다. 쓰레드 풀은 웹 컨테이너에서 동시에 실행할 수 있는 최대 쓰레드의 수를 지정한다. 클라이언트 요청에 쓰레드가 필요하다. 하지만 클라이언트 요청이 사용자 요청과 언제나 같은 것은 아니다. 브라우저는 사용자 요청 당 여러 클라이언트 요청을 필요로 할 수 있다. 예를 들어, 사용자가 제출한 폼에 여러 클라이언트 요청이 필요하다. (폼 값 제출, GIF 파일 가져오기, JavaScript 파일 가져오기, CSS 파일 가져오기) 동기식/비동기식 요청이 동시에 제출될 수 있다면 사용자 요청당 (Ajax 요청에 대해) 적어도 한 개 이상의 쓰레드 소비를 지원할 수 있다는 의미이다. 사용자 요청당 한 개 이상의 쓰레드를 추가하는 것이 가능하지만 애플리케이션이 로딩중이면 결과는 자명하다. (사용자 요청 당 추가 쓰레드가 평균 사용자 카운트 만큼 배가될 것이다.) 분명 서블릿 컨테이너의 퍼포먼스에 영향을 미칠 것이다.

또 한가지 리소스는 데이터베이스 커넥션 풀(database connection pool)이다. 전형적인 Java EE 웹 애플리케이션은 사용자 요청에 대해 두 가지 유형의 시퀀스를 실행한다. 가벼운(shallow) 요청과 무거운(deep) 요청이다. 가벼운 요청은 서버 측 코드를 실행하는 웹 페이지에서 기원한 요청이지만 요청을 완료하기 위해 (데이터베이스 같은) 영속 스토어에 액세스 하지 않는다. 무거운 요청은 서버 측 코드를 실행하는 웹 페이지에서 기원한 요청이고 요청을 완료할 때 영속 스토어에 액세스 한다.

무거운 요청 시퀀스(데이터베이스 연결이 필요함)에서, 더 많은 쓰레드를 허용하면 데이터베이스 커넥션 풀링에는 다음과 같은 요소들이 영향을 받는다.

• 커넥션을 기다리는 쓰레드의 평균 수
• 커넥션을 기다리는 평균 시간 (밀리초 단위)
• 커넥션을 사용하는 평균 시간

결국, 커넥션 풀의 크기나 커넥션 수를 늘려야 한다.

위로

테스팅

자바 개발자들은 Java SE와 Java EE 코드에 단위 테스트를 수행하는 것을 중요하게 생각하고 있다. Ajax 때문에 브라우저에 내장된 JavaScript의 양이 많아지면서 견고한 단위 테스팅 프레임웍이 절실히 요구된다. JsUnit, Selenium, HttpUnit 등을 사용할 수 있다. (참고자료)

이러한 프레임웍들은 웹 페이지 상에서 DOM 엘리먼트를 조작하는 JavaScript 함수에 대한 단위 테스트를 개발하는 장치를 제공한다. 또한 단위 테스트를 테스트 슈트로 그룹핑 할 수 있다. Selenium의 브라우저 호환성 테스팅 기능으로 다양한 브라우저와 운영 체계에서 JavaScript 함수를 테스트 할 수 있다. 이것은 JavaScript와 Iframes를 사용하여 테스트 자동화 엔진을 브라우저에 삽입한다. 이 기술은 JavaScript가 작동되는 브라우저에 적용해야 하고 다중 브라우저와 브라우저 버전들을 지원하는 애플리케이션에 특히 유용하다. Selenium과 JsUnit 모두 연속 통합(continuous integration)을 지원한다. JavaScript 단위 테스트와 테스트 슈트를 자동화 구현 프로세스에 통합할 수 있다.

위로

결론

다른 기술이나 패턴과 마찬가지로 Ajax를 Java EE 애플리케이션에 적용할 때 장단점이 있다. 이 글에서는 Ajax를 Java EE 웹 애플리케이션으로 통합하는 것에 대한 큰 그림을 보여주었다. Ajax의 비동기식 통신 모델은 전통적인 Java EE 웹 애플리케이션의 동기식 모델과는 매우 다르다. 따라서 Ajax를 채택하기 전에 문제가 되는 부분에 대한 충분한 고려가 있어야 한다.

Java EE 프레임웍과 유틸리티 지원은 계속 발전한다. Ajax가 지원되는 프레임웍을 활용하여 통합 시 생기는 복잡함을 줄여야 할 것이다. JSF 기반 Apache Shale과 서블릿 기반 DWR을 계속 주목하기 바란다.

기사의 원문보기

• Ease the integration of Ajax and Java EE

참고자료

교육

• Web-Tier Application Framework Design
  
  
• Using Custom Tags to Avoid Scriptlets
  
  
• Synchronous Asynchronous communication
  
  
• Direct Web Remoting
  
  
• Ajax for Java developers
  
  
• Ajax JSP Tag Library
  
  
• Apache Struts
  
  
• Apache Shale
  
  
• "Shale isn't Struts Anatomy of a Shale application
  
  
• Considering Ajax, Part 1 Considering Ajax, Part 2
  
  
• Ajax in Action
  
  
• JsUnit Selenium HttpUnit
  
  
• The Java technology zone

제품 및 기술 얻기

• AJAX Toolkit Framework
  
  

토론

• developerWorks blogs
  
  
• Ajax discussion forum
  
  

2007.6.28. 갱신 : 현재 1111mb.com 사이트가 열리지 않고 있습니다.
대안으로 www.freeweb7.com 을 이용하실 수 있습니다.
가입 절차는 1111mb 와 유사하기때문에 아래 글 대로 진행 하시면 됩니다.

오늘 소개하고자 하는건 무료로 웹계정과 트래픽을 제공하는 괜찮은 호스팅 사이트입니다.

제가 처음 이곳을 알게된건 촬영한 사진을 웹상에 게시하는데 사용중인 계정에서 상당한 트래픽 압박을 받고 있어서 입니다.

국내의 모 호스팅 서비스를 이용하고 있는데..( 지금 보시는 서비의 다락방과 서비의 photo gallery 는 해외 유료 계정입니다.^^ )
 그 당시 일트래픽 1.5gb를 신청한 상태였고(지금은 재 신청을 통해 500mb짜리로 돌려 놓았습니다만..)
평소에는 과분할 정도의 트래픽이지만 특정일 혹은 특정 게시물이 있거나 회원수가 꽤 되는 동호회에 이미지를 게시 할 경우 트래픽이 모자란 경우를 자주
당하게 됩니다.
트래픽을 늘이면 되지만 그때까지도 상당히 트래픽을 늘인 상태였고 단지 하루 ,이틀 폭주하는 트래픽을 감당하기위해 트래픽을 더 늘이는건
돈낭비 라는 생각이 들었습니다.

그런때에 이 호스팅을 찾게 된 겁니다.

사이트 주소는 http://www.1111mb.com http://www.freeweb7.com 입니다.
사이트명이 1111mb 이건 이 서비스가 처음 생겼을때는 무료로 1111mb의 계정을 주었던 듯합니다.

• 5000mb 용량제공(무려 5gb).
• 월 50000mb 트래픽( 50gb ).
• 광고 없음.
• 계정id.1111mb.com 도메인 제공.
• FTP 이용 가능.
• PHP 4 지원.
• 10mb MySql. 10개의 MySQL DB( 용량제한 없음 )
• 99.9% 업타임 지원.
• 등등..
  

입니다.

제가 처음 가입할 당시에는 계정은 2gb를 제공 했으며 html파일을 업로드하고 브라우저에서
열어보면 위아래로 광고가 붙어 있었는데 지금은 용량도 늘고, 광고도 사라졌습니다.

무료계정치곤 꽤 괜찮다는 생각이 들어 가입절차를 밟았습니다.

가입에 필요한 정보는 id, password 그리고 계정 활성알림 메일을 받을
email 주소가 다입니다.