자바에서는 개발자가 프로그램에서 별도로 메모리 관리를 하지 않는다. 이것은 C/C++에서는없던 획기적인 것이었다. 자바의 메모리 관리 개념은  개발자를 열광케 하고, 나아가 자바가 세상을 지배하는 언어가 되는데 핵심 역할을 담당하였다

그러나 애석하게도 자바에서는 여전히 메모리 문제가 발생하고있다. C/C++처럼 빈번하지는 않지만 종종 OutOfMemoryError는 발생하고 있으며, 이러한 메모리 부족 에러는 운영자나 개발자가 가장 껄끄러워하는 문제 중에 하나로 인식되어있다.

1.1 자바의 메모리 부족 유형

Out Of Memory Error가 발생하는 원인을 보면 크게 (1)단지 메모리가 부족할 때 (2)Heavy 서비스가 수행되면서 혹은 (3) 메모리 LEAK에 의한 메모리 부족 때문으로 구분할 수 있다.

절대적인 메모리 부족

단지 메모리가 부족하다는 것은  설정된 메모리량이 요구되는 메모리량에 비해 부족하다는 것이다. 프로그램이나 기타 오류가 아닌 단지 값이 적게 설정되었다는 것을 의미하기 때문에 통상적으로는 -Xmx값을 늘려줌으로써 해결되는 것이 보통이다. 실제로는 의외로 JVM 시작시 메모리 옵션을 빠뜨리는 경우가 많다. 혹은 -Xmx256과 같이 메모리 단위(원하는 설정-Xmx256m)를 빠트리는 경우도 있다.  물론 옵션을 잘못 기술하는 것은 단순한 실수이지만, 자바 힙 메모리에 대한 경험이 전혀 없어서  단위 시간당 서비스 호출건수(Service Arrival Rate)에 비해 턱 없이 적은량의 메모리를 지정하는 경우도 종종 있다.

SUN/HP JVM에서는 perm 영역이 작아서 발생하는 경우가 있다. 메모리의 perm영역에는 클래스코드 등이 저장되는 공간으로  사용되는 클래스가 많은 경우에는 사이즈를 늘려 주어야 한다.

Heavy Application Service의 의한 부족

OutOfMemoryError는  응용서비스(ex Web Request 처리 로직)가 순간적으로 메모리를 과도하게사용함으로써 발생할 수 있다.

데이터 베이스에서 너무 많은 데이터를 로딩하거나 검색 조건이 잘못되어 검색서버에서 너무많은 텍스트를 조회하는 경우가 해당된다. 또 다른 경우로 과거에 upload/download프로그램에서 자주 발견되던 것으로 byte[] buffer에서 buffer의 크기를 너무 크게 설정함으로써 연속공간부족 현상(IBM JVM)이 발생하는 경우나,  동시에 여러 개의 요청이 발생하여 단위 시간당 절대사용량이 많아 OuOfMemory발생하는 경우를 생각할 수 있다. 물론 후자의 경우는 application이정상적으로 메모리를 많이 사용하는지 단지 프로그램 오류인지는 판별하기 어려울 수도 있다.

LEAK에 의한 메모리 부족

마지막으로 Memory Leak이 발생하여 메모리가 부족해지는 경우이다.  보다 정확하게 자바에서메모리 LEAK은 로직적으로 사용되지 않는 객체가 GC될 수 없는 strong reference에 의해 참조되어 메모리 사용량이 증가하는 상태를 말한다. 대부분 적절한 반환을 거치지 않아 발생한다.

대표적으로 JDBC관련 클래스를 사용하고 close()를 호출하지 않게 되어 발생하는 경우를 생각할 수 있다(물론 JDBC에 따라서 혹은 Web Application Server에 따라서 메모리 Leak이 발생하지 않을 수 도 있다.)

메모리 LEAK의 다른 사례로 Cache의 구현 로직에 문제가 있는 경우이다. CACHE에서 불필요한데이터의 제거 로직이 정상적으로 동작하지 않는 경우 OutOfmemoryError가 발생할 수있다.

Http Session에서 데이터가 증가하는 현상 또한 이 범주에 포함 시킬 수 있을 것이다.

 

1.2  OutOfMemoryError 발생시 원인 분석

화면이나 프로그램 로그에서 OutOfMemoryError를 보게 된다면 어떤 경우에 발생하는지를 정확히 판별해야 한다.

단지 설정이 잘못된 경우라면 통상적으로 JVM startup 혹은 startup이후 짧은 시간내에OutOfMemory가 발생하게된다. 따라서 서버를 리스타트 할 때 OutOfMemoryError를 보게 된다면 옵션 설정을 먼저 의심해 보아야 한다. 그러지만 PERM영역이 부족한 경우에는 약간 시간을두고 발생하게 되지만 특징은 HEAP메모리가 부족하지 않는데 OutOfMemoryError가 발생하면서 SUN/HP JVM이라면  PERM영역이 부족하지 않은지를 먼저 확인해야 할 것이다.

만약 (2)경우라면 어떤 현상이 관찰될까? HEAP MEM 그래프를 보면 갑자기 메모리 사용량이급격히 증가하고 GC가 빈번해지는 현상이 관찰되는 것이 일반적이다. 시간에 따라 메모리 사용량이 증가하지 않고 어느 순간에 메모리 사용량이 급격히 증가하고 GC가 빈번해 지는 현상이발생한다면 특정 Application이 메모리를 과도하게 사용함을 추정할 수 있다. 다만 Active Service가 증가한 이후에 Memory사용량이 증가하고 GC가 빈번해지면 인과관계가 약간 불분명할 수는 있다 즉 다른 원인에 의한 Active Service가 증가하고 그 service들이 사용하는 메모리량이 많아서 OutOfmemoryError가 발생할 수는 있는데 사실 이런 경우는 빈번하지 않다.

IBM JVM인 경우에 HEAP에 여유가 충분하고 GC가 빈번해지지도 않으면서 갑자기OutOfMemoryError가 발생한 경우에는 fragmentation에 의한 연속공간부족을 의심할 수 있다.

마지막으로 메모리 LEAK은 HEAP그래프가 시간에 따라 증가되는 현상으로 나타난다. 시간이단 몇시간인 경우도 있으나 한 달이 넘는 경우도 있다. 메모리 사용량은 명시적으로System.gc()를 호출한 후 비교해야 한다.

단지 설정이 잘못되거나 너무 적은 메모리를 설정한 경우에는 설정을 수정함으로써 해결하면OK이지만 특정 Application에 의한 OutOfmemoryError나 Memory leak이 발생하는 경우에는 해결을 위해 보다 논리적 접근이 필요하다.

특정 application에 의한 불특정 시점에 OutOfMemoryError이 발생하는 것이 확인된다며 어떤application이 Memory Error를 발생하는지를 찾아야 한다. 만약 해당 Application이 upload나download와 관련있는 프로그램이라면 데이터를 제어하기 위한 버퍼 사이즈를 먼저확인하고단순히 DB를 사용하는 프로그램이라면 DB Access 데이터 량을 확인하는 것이 먼저이다.

 제니퍼는 OutOfMemoryError에 의한 서비스 종료가 발생하면 WARNING을 발생하고 에러 정보를 저장함으로 이것을 확인하는것도 방법이다. 통상적으로 메모리를 과도하게 사용한Application이 수행되면 순간적으로 해당 인스턴스의 응답시간/CPU사용량등이 증가하게되며XVIEW상에서 모든 프로그램의 응답시간이 급격하게 증가하는 현상을 관찰할 수있는데 이때가장 높은 곳(응답시간이 길거나/CPU사용량이 높음)에 위치하는 것이 문제의 Application인 경우가 많다. 따라서 일자별 XView 데이터 조회를 통해서 해당 시간대를 면밀히 관찰하면 쉽게 찾을 수 있다.

Memory Leak 이것은 원만큼 자바 튜닝이 공력이 붙지 않으면 해결하기 힘들다 긴 시간이 필요한데다가 개발 서버에서는 좀처럼 재연되지 않기 때문에 특히 어렵다. 메모리 릭은 원칙적으로HEAP DUMP를 분석하는 것이 가장 빠른 길이다.

과거 JAVA 1.4 에서는 IBM JVM에서만 HEAP DUMP가 가능했지만  JAVA1.5이상에서는 모든플렛폼에서 HEAP DUMP가 가능하다.

 제니퍼에서는 HEAP 사용량을 모니터링 하고 트랜잭션별 응답시간과 CPU사용량을 모니터링함으로써 메모리 문제 해결에 크게 도움이 될 수있다.

제니퍼를 통해서 OutOfMemoeyError가 어떠한 유형인지를 판별하고 만약 LEAK이 의심이 된다면 언제쯤 OutOfMemoryError가 발생할지 그리고 그메모리 부족이 서비스 응답시간에 영향은없는지를 모니터링 하여 안정적으로 시스템을 운영하면서 메모리 문제를 해결할 수 있다.

 

서비스의 성능과 그 상세 내역(프로파일)을 추적하는 것은 서비스 중심 프로파일링이라 하고 Java EE컴포넌트(즉 서블릿, EJB JDBC)단위로 성능과 그 상세내역(프로파일)을 추적하는것을 컴포넌트 중심 프로파일링이라 한다.

Service Base Profiling

서비스의 처리 로직을 상세하게 추적한다.  모든 프로파일 정보를 서비스 단위로 맵핑한다.서비스 단위로 프로파일 정보를 확인할 수 있다.

Component Base Profiling

프로파일 정보를 컴포넌트 단위로 수집한다. 따라서 프로파일 정보를 컴포넌트 단위로 확인할 수있다. 만약 서비스에 대한 프로파일 검토가 필요하면 서비스가 호출한 컴포넌트를 확인하고 이 컴포넌트의 프로파일을 확인한다.

※컴포넌트 기반 프로파일링의 문제

컴포넌트 기반의 프로파일링은 얼핏 보면 논리적이고 서비스 기반 프로파일링 보다 자세한정보를 보여줄 것 같다. 하지만 컴포넌트 기반 프로파일링은 컴포넌트의 특성 때문에 비효율적인 서비스 모니터링 방법이다.

컴포넌트의 수행시간의 대부분은 여전히 JDBC혹은 TP와 같은 외부 호출이다.

컴포넌트 기반의 프로파일링의 이유의 핵심은 성능 저하 원인을 SQL이나 TP호출 보다는 어떤 Java EE컴포넌트에서 기인할 것이라는 가정하기 때문이다.

하지만 실제 프로덕션 환경에서 성능저하의 원인인 대부분 외부 시스템 즉 SQL/TP/LDAP호출에서 기인하는 경우가 더 많다.. 

그래서 컴포넌트 중심 프로파일링을 하게되면 컴포넌트 단위의 프로파일을 보고 그것이 서비스에 어떻게 영향을 미쳤는지를 알기 위해서는 다시 서비스 프로파일을 보아야 한다. 즉 서비스->컴포넌트, 다시 컴포넌트->SQL/TP의 2중의 프로파일을 분석해야 한다.

서비스와 컴포넌트간의 맵핑을 해야하고 서비스와 SQL/TP 간의 맵핑은 어렵다.

컴포넌트는 서비스와 N:M관계이다  또한 컴포넌트와 SQL/TP관계도 N:M관계이다. 그리고  컴포넌트간의 호출관계도 발생한다 그만큼 그들간의 맵핑 정보는 복잡해지고 추적과 분석이 어려워 진다.

운영 담당자는 컴포넌트를 잘 모른다

어쩌면 이것이 가장 큰 문제 일수있다. 일반적으로 운영담당자는 Java EE의 전문가가 아니다. 개략적인 이해만 있을 뿐이다. 설령 JavaEE에 지식이 풍부하더라도 운영담당자가 개발에 참여하는 경우는 거의 없다. 당연히 운영 담당자는 애플리케이션 내의 컴포넌트 구성이나 상관관계에 대한 깊은 이해가 어렵다. 또한 이들에게는 Application Server Tier의 진입점인 서비스 로부터 끝지점인 DB/TP 연계 중심으로 성능을 이해하는 것이, EJB나 Servlet/JSP, JMS 등과 같은 컴포넌트 구성을 이해하는 것이 보다는 쉽다.

당연히 이들은 느린 서비스를 추출하고 그것의 수행내역을 개발자에게 검토 요청하는 것이가장 효과적일 것이다.

오버헤드를 피할 수 없다.

애플리케이션 서비스를 프로파일링해 보면 프로파일링 자체의 오버헤드도 있지만, 프로파일링정보의 목록을 관리하는 오버헤드도 크다. 그런데 컴포넌트 단위의 프로파일링에서는 각 컴포넌트 별로 프로파일링 목록을 관리해야 하기 때문에 프로파일링 목록이 엄청나게 많아진다.

그렇다고 프로파일링 컴포넌트를 필터링하게되면 분석정보의 유실이나 왜곡을 피할 수 없다. 

서비스 트랜잭션을 직관적으로 모니터링하자 그래서 XView를 만들었다

애플리케이션 모니터링을 처음 고민하기 시작할때가 
아마도 처음 장애해결에 나갔을 때 인것 같다.
DB,H/W,N/W,그리고 나(APP) 그렇게 4명이 시스템의 장애를
해결하기 위해 사이트에 나간적이 있었다.

첫날 사이트에 도착해서 이런저런 회의를 통해서 
문제가 심각하다는 이야기를 듣고 각자 하루 동안 현상을 수집하기로 했다
DB는 SQL툴을 열어 놓고 SQL문을수행하면서 결과를 수집하기 시작했다.
H/W는 수십개의 쉘을 돌리면서 결과를 수집하기 시작했다.
N/W담당자도 쉘과 몇개의 프로그램을 설치하고는 정보를 수집하였다.
그런데 나는(?) 다른 사람들은 운영서버에서 정보를 수집하는데
나는 개발자에게 소스를 받았다. 그리고는 소스를 읽어나갔다.

다음날... 4명은 탁자에 모였다.. 나를 제외한 모두는 
그래프를 들고서 다른 사람에게 현황을 설명하기 시작했다.
DB도 H/W도 N/W도 그런데 나는 그자리에서 나만 이해하는
소스 코드들을 들고 어쩔줄 몰라했다.. 그 많은 소스 중에서
문제가 쉽게 발견되지 않는 것이 당연하기는 했다..

어쨌거나.. 그때 나에게도 뭔가 툴이 필요하다고 느꼈다..
뭔가 빨리 깔아서 잠깐 모니터링 하고 다음날 이야기 할 수 있는
그런툴.. 문제를 빨리 잡을 수 있는 툴 그런것이 필요했다.

결과적으로 그 사이트의 문제는 EJB 프로그램을 잘못해서
메모리가 급격히 증가하고 그래서 발생한 문제 였다.
정말 운이 좋아서.. 우연히 전혀 비과학적으로 3일째 소스를 넘기다가 우연히 발견하여
문제를 해결하였다..
이런경우 우리는 "소 뒷발로 쥐잡았다"고 한다.

그런데 이러한 나의 고민은 이후에도 계속되었다.
몇개의 사이트에 문제 해결을 나가는 동안
나는 로그와 소스에만 의존해야 했다.
하드웨어의 로그는 구글에서 검색하면 대부분 나온다.
그러나 애플리케이션이 남기는 로그 인터넷 어디에도 없다 그사이트에만 있는 로그이다.
그렇게 힘들게 몇개의 시스템 문제해결에 참가한 후에

상용 툴을 설치해야 겠다고 생각하게되었다.
지금도 있는 몇개의 툴을 설치했다. 아니 정확하게는 
설치를 시도했다.. 하지만 일반적으로 나에게 주어진 시간은
2~3일 정도 그시간이 지나면 모든 사람은 내얼굴을 보면서
빨리 문제를 해결할 것을 종용한다.
나는 툴 설치를 포기하고 다시 로그와 소스에 의존하여
문제를 해결하였다.

그리고 나서는 안되겠다. 내가 필요한 것을 내가 만들어야 겠다고 생각했다
막상 툴을 만들려고 하니..
애플리케이션을 모니터링하려면 어떻게 해야할까..
아니 정확히는 무엇을 모니터링 할까 하는 원론적인
질문이 고민스러웠다.
CPU,MEM 이런것은 시스템 모니터링 툴들이 알려준다
SQL성능 이것은 DB가 잘 알려준다.
그러면 나는? 애플리케이션을 모니터링 해야 한다.
그런데 Application Server에 동작하는 프로그램은
모양이 비슷하다 사용자(브라우저) 요청을 받아서 결과를 리턴한다.
그 결과를 만들기 위해 DB도 가고 턱시도도 호출하고...
우리는 이런것을 트랜잭션이라고 한다. 
아마 서비스 트랜잭션이 더 맞을 것이다.

그래 나는 이 트랜잭션을 모니터링 해야 겠다. 그때만 해도
프로파일 툴이 일반화 되지 않았지만 
트랜잭션 프로파일링이 필요하다는 결론에 이르렀다.
그래서 일단 트랜잭션 별로 프로파일 정보를 로그파일에 
남겼다. 로그파일 명에 서비스 명과 응답시간을 넣어서
디렉토리에서 쉽게 찾을 수있도록 하였다 물론 프로파일링 툴을 적용하면
이것을 툴에서 할 것이다.하지만 원리는 같다.

그런데 문제가 있었다. 트랜잭션성능과 구간별 시간은 보이는데 애플리케이션 전체를
알 수 없었다 그트랜잭션 하나의 문제가 전체의 문제라는 확신을 할 수가 없었다.

만약 트랜잭션 전체의 성능을 보면 애플리케이션을 알 수 있을텐데
볼 수 없었다. 나는 트랜잭션 프로파일 하나하나를 리뷰했지만
동일 서비스가 트랜잭션에 따라 다른 응답시간을 보이고
이것들의 원인을 정확히 알 수 없었고 그것이 문제의 원인이라고
주장할 수 없었다.

문제는 트랜잭션의 성능을 한눈에 볼필요가 있었다.
즉 문제 핵심은 그많은 트랜잭션(초당 몇백개)의 성능을
어떻게 볼 수 잇게 하느냐가 문제였다 나는 그중에서 프로파일을
분석해야할 트랜잭션을 선별하거나 트랜잭션 간의 연관도를 알고 싶었다

서비스명이 같은 트랜잭션 끼리 묶어서 평균 응답시간을
라인 그래프로 보기도 하고 리스트박스에 표현도 해보았지만
한눈에 모든 트랜잭션을 관찰한다는 것은 어려웠다.

그러다가 유래카..^^ 트랜잭션의 성능을 점으로 표현하면될 것 같았다.
프로그램을 만들어서 모든 트랜잭션을 점으로 화면에 표현하였다..
세로축은 응답시간 가로축은 종료시간으로한 점 그래프를 만들고
그 중에서 점을 선택하면 그 점에 대한 프로파일 정보를 
확인할 수있도록 하였다.

이렇게해서 제니퍼의 XVIEW가 만들어졌다.
XVIEW는 모든 트랜잭션을 한눈에 개별적으로 확인할 수 있다.
현재 어떠한 툴도 트랜잭션 모니터링을 이렇게 하지는 않는다.

XVIEW에서는 느린 서비스 혹은 같은 시간대에 수행된 트랜잭션들을 
직관적으로 확인하고 그들간의 상관관계를 확인할 수 있다

동일 서비스에 대해 느릴때와 빠를 때의 차이를 상대비교할 수있으며
트랜잭션간의 락이 발생하거나 자원의 부적이 응답시간에 어떻게
영향을 미치는지도 직관적으로 확인할 수 있다.

그뒤로 나는 애플리케이션 성능 바라보는데 한단계 수준 업이 되었다는 것을 느끼게 되었다.

2000년대 초기부터 2005년 무렵까지 엔터프라이즈 시스템 구축을 주도하던 키워드는 한마디로 COMPONENT였다. 
CBD에 관한 책들은 우후죽순처럼 쏟아져 나왔고 CBD를 이야기 하지 않으면 프로젝트는 시작될 수 없었다. 모든 개발관련툴은 CBD를 지원한다는 광고를 실어야 했고 CBD를 모르면 개발자로 참여할 수도 없었다. 

그런데 지금 CBD는 어디에 있는가?
엔터프라이즈 시스템에서 CBD는 더이상 키워드가 되지 못하고 있다. 4GL이나 3Tier와는 너무도 다른 양상이다. 컴포넌트 개념은 Technical 문제를 다루는 곳에서 존재하지만 이것은 여전히 예전의 라이브러리 개념과 별 차이를 보이지 못하며 정작 CBD가 주장하던 비즈니스 컴포넌트 개념은 온데간데 없다. 혹시 내가 모르는 곳에서 숨어서 꽃을 피우고 있나? 아닐 것이다.

사람들은 더이상 비즈니스 컴포넌트에 집착하지 않는다. 적당히 유야무야되었다는 것이 정확할 것이다. 이런 글을 쓰고 있는 나 또한 그 시절에 CBD가 미래를 열어 줄 것이라 확신했었다. 뭔가 내가 부족하기 때문에 컴포넌트 개념을 잘 이해 못하고 그래서 내가 참여했던 프로젝트에서 비즈니스 컴포넌트 개념이 정착되지 못하는 것이라 생각했었다.

그런데 내가 이 시점에 CBD를 이야기하는 것은 정말 과거의 우리 신념에 대한 반성이 없이 새로운 키워드를 찾으려고 노력한다는 것을 지적하고 싶다. 컴포넌트 개념이 정말로 나 스스로를 포함한 모든 사람을 위선으로 빠트리기 위한 거짓부렁에 불과했는가? 아니면 일정정도 의미가 있고 가치있는 개념이었는가?

우리는 공개적으로 반성하고 정리해야 할 것이다. 그래야 미래의 새로운 키워드에 대해서 비판적으로 수용할 수 있을 것이다. 

내가 현시점에 CBD를 보는 관점은 기술적으로는 의미잇는 성과를 이루었지만 비즈니스 컴포넌트 관점에서는 실패했다고 생각한다. 나는 CBD의 가장 성공 사례로 이클립스를 꼽는다. 수많은 솔류션이 이클립스로 통합되고 있다. 이클립스는 단순한 개발툴이 아니고 솔류션을 위한 프레임웍 혹은 컨테이너 역할을 하고 있다. 간단한 기능의 유틸리티는 이클립스 플러그인으로 개발하면 너무 훌륭하게 다른 유틸리티들과 함께 사용할 있다.
이런한 모습은 구글폰 같은 핸드폰에서도 나타나고 있다. 

과거의 CBD개념은 분명 100%실패한 개념이 아니라 다른 개념으로 진화해갈 것이고 언제가는 다시한번 세상을 풍미하지 않을까 하는 생각을 해본다. 
그런데 우리는 너무도 쉽게 쫓아가다가 너무도 쉽게 버리고 있는것은 아닌가? 
다시한번 CBD에 대한 개념정리가 공론화 되기를 바라는 마음에서 이글을 써본다.

1 개요

이클립스 RCP(Rich Client Platform)는 자바로 독립 응용 프로그램을 만들기 위한 강력한 도구를 제공한다. 응용 프로그램을 만들다 보면 본래 기능보다 메뉴라든지, 도구 모음(toolbar) 처리나 프로그램 설정 관리 같은 기능들을 구현하는 데 오히려 더 많은 노력과 시간이 투자되는경우가 많다. 이클립스 RCP는 이러한 문제로부터 프로그래머를 해방시킨다.

지금부터 이클립스 RCP를 활용해 예제 프로그램을 만드는 과정을 소개하고자 한다. 직접 따라 해보면, RCP를 이용해 그럴 듯한 프로그램 하나를 개발해볼 수 있을 것이다. 

 

2 예제 프로그램 생성하기

이클립스 RCP 프로그램을 시작하려면 예제 프로그램에서 출발하는 것이 좋다(물론 수정하다보면 나중에는 원본 예제가 모두 사라지게 되겠지만…).

 

프로젝트 생성

다음과 같이 플러그인 프로젝트를 만든다.

 

1.  Select a wizard: Plug-in Project를 선택하고 Next 클릭

2.  Plug-in Project: Project Name에 MyRCP를 입력하고 Next 클릭

3.  Plug-in Content: Rich Client Application 부분을 Yes로 수정 후 Next 클릭

4.  Templates: RCPMail Template을 선택하고 Next 클릭

5.  RCP Mail Template: 그냥 Finish 클릭

 

이렇게 하면 아래와 같이 간단한 전자메일 클라이언트가 만들어진다.

 

그림 1. 예제 프로젝트 생성 모습

 

 화면 중앙의 ‘Launch an Eclipseapplication’ 부분을 클릭하면 MyRCP가 실행된다.

 

3 전자메일 클라이언트를 파일 탐색기로 개조하기

이클립스 RCP는 상당 부분을 설정만으로 가능하며, 프로그래밍을 하더라도 응용 프로그램의메뉴, 도구 모음 등은 최소한의 코드로 짤 수 있게 되어 있다. 여기서는 프로그램적 요소를 중심으로 수정해 MyRCP 프로그램을 간단한 파일 탐색기 형태로 만들어 볼 것이다.  이렇게 함으로써 간단한 RCP프로그램의 구조를 파악할 수 있을 것이다

그림 2. MyRCP 최초 실행 모습

 

3.1 전자메일 리스트 창을 파일 탐색기로 수정하기

예제 프로그램에서 왼쪽 네비게이션 창 부분을 파일 탐색기로 수정해 보자. 예제 프로그램의NavigationView.java를 열어보면 jface로 프로그래밍이 된 것을 확인할 수 있다. 물론 jface를사용하면 편리한 점이 많으나 여기서는 swt를 사용해 간단한 파일 탐색기를 만들어 보겠다(jface를 사용하면 좀더 풍부하게 그리고 효과적으로 응용 프로그램을 작성할 수 있으므로RCP프로그램을 잘하려면 jface를 익혀두는 것이 좋다).

NavigationView는 ViewPart의 자식 클래스이므로 createPartControl(Composite) 와setFocus()에 파일 탐색기 기능을 하는 코드를 작성하면 된다(참조 NavigationView.java)

 

그림 3 NavigationView를 수정하여 실행

 

레이지 로딩(lazy loading) 구현하기

NavigationView에서 보면 트리 컴포넌트를 구현할 때 간단한 팁이 들어 있다. 파일 리스트를트리 형태로 보여 줄 때 목록을 모두 읽을 필요는 없다. 성능 저하를 막기 위해 참조가 발생했을 때 자식 정보를 읽어 들이도록 코딩된 모습을 확인할 수 있다.

 

private void buildChildItem(TreeItem item,File file, boolean isroot) {

       if(isroot)

               item.setText(file.getAbsolutePath());// 아이템이 루트이면 절대 경로를 라벨로 사용

       else

               item.setText(file.getName());// 아이템이 루트가 아니면 이름만 라벨로 사용

        if(file.isFile()) {

                           item.setText(1,formatSize(file.length()));

                           item.setText(2,formatTime(file.lastModified()));

         }

             item.setImage(getImage(file));

             item.setData("path",file);

             if (hasChild(file)) {

                           item.setExpanded(false);

                           newTreeItem(item, 0); // 더미 아이템

             }

}

 

트리에서 특정 노드의 자식을 보여 줄 때 해당 아이템에 자식이 존재하는지만을 확인한 후 만약 자식이 존재한다면 더미 아이템을 추가해 놓고 펼침(expand) 상태를 false로 해 놓는다. 그렇게 하면 해당 트리 아이템에 자식이 존재한다는 [+] 표시가 보이게 된다. Expand 이벤트가발생할 때 이 아이템이 더미 아이템을 삭제하고 실제 자식 아이템들을 보여준다.

다음으로 해당 아이템이 펼쳐질 때 이전에 방문했는지를 검사하여 방문한 적이 없는 아이템에 대해서만 방문 기록을 세팅을 하고 buildChild를 통해 자식 트리를 초기화한다.

 

fileTree.addListener(SWT.Expand, newListener() {

             publicvoid handleEvent(final Event event) {

                           finalTreeItem item = (TreeItem) event.item;

                           if (item.getData("visited") ==null) { // 이전에 방문했는지 확인

                                        item.setData("visited","true"); // 해당 아이템에 방문했음을 설정

                                        buildChild(item);

                           }

             }

};

 

3.2 메시지 창을 파일 뷰어로 수정하기

예제에서 오른쪽 메시지 창은 View.java에 구현되어 있다. 이것을 매개변수로 파일 이름을 받아 화면에 파일 내용을 보여주는 파일 뷰어로 수정한다(참조 View.java)
. 단지 선택된 파일을 읽어 들이는 것이기 때문에 기술적으로 복잡할 것은 없지만 다만 열리는 창에 파일 이름을 전달하는 방법이 간단한 팁이라 할 수 있다.

 

MyRCP 프로그램의 텝윈도우 Open Logic

기본적으로 각 뷰는 독립적인 컴포넌트다. 따라서 다른 창에서 명시적으로 정보를 전달하기보다는 이벤트 모델을 통해 창들간에 데이터를 전송하는 것이 좋은 방법이나 여기서는 뷰의Secondary ID로 파일 이름을 전달하는 약간의 트릭을 이용해 전달하고 있다.

 

public static HashMap selection = new HashMap();

public static void openView(String viewId,String path) {

             if(path == null)

                           return;

             IWorkbenchWindowwindow = MyRCPPlugin.getDefault().getWorkbench()

                                        .getActiveWorkbenchWindow();

             selection.put("" +path.hashCode(), path);

             try{

                           window.getActivePage().showView(viewId,"" + path.hashCode(),

                                                     IWorkbenchPage.VIEW_ACTIVATE);

             }catch (PartInitException e) {

                           MessageDialog.openError(window.getShell(),"Error",

                                                     "Erroropening :" + e.getMessage());

             }

}

 

Secondary ID에는 특수 문자를 사용할 수 없기 때문에, HashMap에 파일 이름의 해시를 저장하고 뷰에서 해시 코드를 사용해 넘겨진 파일 이름을 알아내는 방식을 취하고 있다. 이 방식을 이용할 경우selection(HashMap)의 element 수가 계속 늘어날 여지가 있다.

다음 코드는 뷰의 createPartControl()에서 전달되는 Secondary ID를 이용해 파일 이름을 알아내고 화면에 출력하는 것이다.

 

public void createPartControl(Compositeparent) {

             Stringhash = this.getViewSite().getSecondaryId();

             Stringpath = (String)Perspective.selection.get(hash);

             if(path == null)

                           return;

…

 

3.3 시작 메뉴 수정 및 초기화

이제 메뉴를 수정한다. 최초의 전자메일 프로그램에서 사용하던 불필요한 메뉴를 제거하고시작할 때 필요 없는 뷰가 열리지 않도록 로직을 수정한다.

 

메뉴 구조 수정

메뉴와 도구 모음에 관한 프로그램 코드(ApplicationActionAdvisor.java)를 보면, 매우 직관적으로 구현되어 있기 때문에 고치는 데 어려움이 없을 것이다. 만약 메뉴나 도구 모음 아이템을 추가하고자 한다면 원본 코드에 존재하는 로직을 참고해 동일한 형태로 프로그램을 짜면된다. fillMenuBar(MenuBar 초기화)에서 exitAction과 aboutAction만을 남기고 나머지는 모두 주석 처리한다. 그리고 fillCoolBar(CoolBar 초기화)도 수정해 exitAction과 aboutAction을실행할 수 있도록 변경한다.

 

화면 크기 수정

예제 프로그램을 보면 화면 영역이 두 개 있는데 왼쪽은 25%, 오른쪽은 75%를 차지하고 있다. 프로그램이 시작할 때 이렇게 열리는 화면 영역의 크기를 조정하기 위해서는Perspective.java에서 createInitialLayout(IPageLayout layout)을 수정한다.

layout.addStandaloneView(NavigationView.ID,false, IPageLayout.LEFT, 0.25f,editorArea);를layout.addStandaloneView(NavigationView.ID, false, IPageLayout.LEFT, 0.5f, editorArea);로수정하면 프로그램이 시작될 때 두 개의 화면 영역이 각각 50%를 점유하게 된다. 그리고folder.addView(View.ID);를 주석 처리하면 시작할 때 불필요한 메시지 화면이 열리지 않는다.

 

그림 4 화면 영역 비율을 수정하여 시작한 모습

 

4 MyRCP 익스포트하기

이제 MyRCP를 독립 프로그램으로 실행하기 위해 익스포트한다.

4.1 제품 만들기

만들어진 프로그램을 설정을 통해 익스포트하면 그것이 독립 응용 프로그램이 된다.

 

제품 설정 파일 생성

프로젝트에서 마우스 오른쪽 버튼을 클릭해 New->Product Configuration을 선택한다.

 

그림 5 제품 Configuration 생성

 

‘New Product Configuration’ 화면에서 MyRCP를 선택하고, ‘File name’에 MyRCP.product를 입력하고 Finish를 클릭한다. 그러면 독립 프로그램으로 실행하기 위한 각종 설정 값들을 지정할 수 있는 화면이 열린다.

생성된 MyRCP.product의 설정은 세 개의 탭으로 구성되어 있는데, 간편하게 Overview와Configuration 두 개의 탭만 설정하면 익스포트할 수 있다.

 

오버뷰 설정

Overview 탭 화면에서 프로그램 이름 같은 기본 정보를 설정한다.

 

그림 6 오버뷰 설정

 

‘Product ID’의 오른편 New 버튼을 클릭하면 ‘New Product Definition’ 화면이 나타난다.

그림 7 제품 정의

 

먼저 ‘Defining Plug-in’ 오른편의 Browse를 클릭하여 ‘Plug-in Selection’에서 MyRCP를 선택하고 OK를 누른다. 둘째로 ‘Product ID’에 임의의 값을 입력한다. 예제에서는 MyRCP를 입력했다. 그리고 Finish를 선택하면 아래와 같이 각 필드에 입력 값들이 등록되는 것을 볼 수 있다.

 

그림 8 오버뷰가 입력된 모습

 

설정

MyRCP.product에서 Configuration 탭을 선택하면 아래와 같이 비어있는 화면을 볼 수 있다. MyRCP를 독립 응용 프로그램으로 실행하기 위해서는 필요한 플러그인들이 전부 같이 익스포트되어야 한다.

 

그림 9 설정

 

Add 버튼을 누르면 플러그인을 선택하는 화면이 보인다. 이 때 MyRCP(제품에 포함되어야 하는 기본 플러그인)를 선택한다.

 

그림 10 MyRCP 플러그인 추가

 

MyRCP 플러그인이 동작하려면 의존 관계에 있는 다른 플러그인이 모두 추가돼야 하지만 이클립스에는 이 작업을 자동으로 수행해 주는 기능이 있다. 화면에서 ‘Add RequiredPlug-ins’을클릭하면 이미 추가된 MyRCP가 동작하기 위해 필요한 모든 플러그인들이 자동으로 추가된다.

 

그림 11 필요한 플러그인 자동 추가

 

제품 익스포트 및 실행

MyRCP를 독립 응용 프로그램으로 수행하기 위해 익스포트를 해야 한다.

 

그림 12 익스포트

 

MyRCP.product의 Overview 화면에서 Exporting 영역의 ‘Eclipse Product export wizard’를 클릭해 익스포트를 수행한다.

 

그림 13 익스포트 위치 지정

 

Export 창에서 ‘Archive file’에 적절한 경로를 입력하고 Finish를 클릭하면 익스포트가 수행된다. 익스포트된 파일을 적당한 디렉터리에 풀어서 실행하면 된다.

 

4.2  기타 유용한 팁 몇 가지

사소하지만 처음 RCP를 만들 때 공유하고자 하는 내용을 정리해 보았다.

 

설정 사용하기

이클립스에서는 환경 설정을 위한 기능을 제공하고 대부분의 설정 정보는 이곳에 넣는 것이일반적이다. 그러나 java –Dxxx=100과 같이 사용하고자 한다면 configure/config.ini에 값을 넣고 System.getProperty(“xxx”)형태로 프로그램에서 읽어 사용할 수 있다.

 

메모리 지정하기

MyRCP도 자바 프로그램이기 때문에 메모리 지정이 필요하다 익스포트 전에MyRCP.product의 Configuration 탭에서 지정할 수도 있지만, 메모리 옵션을 바꾸려고 매번 익스포트할 수는 없다.

메모리를 포함한 JVM 옵션은 eclipse.ini에 저장되어 있다. 그런데 만약 Configuration 탭에서JVM 옵션을 지정하지 않으면 eclipse.ini 파일 자체가 만들어지지 않는다.

 

탭 모양 바꾸기

실행한 화면을 보면 탭이 이클립스와 모양이 다른 것을 볼 수 있다. 이것을 수정하려면plugin_customization.ini 파일에 속성 설정이 필요하다. configuration/config.ini 파일에 필요한설정을 넣고 그것을 프로그램에서 사용하면 효과적이다. config.ini에org.eclipse.ui/SHOW_TRADITIONAL_STYLE_TABS=false가 설정되면 탭 모양이 이클립스처럼 부드럽게 변경된다. 속성을 적용하려면 plugin_customization.ini가 MyRCP 플러그인에같이 패키징되어야 한다.

 

그림 14 MyRCP 프로젝트 구조

 

그림 15 빌드 목록에 plugin_customization.ini 추가

 

Build.properties 파일을 열어 위와 같이 바이너리 빌드에서 체크해 주면 같이 패키징된다.

그림 16 탭 모양이 바뀐 MyRCP

 

다시 MyRCP를 실행하면 바뀐 모양을 확인할 수 있다.

 

결론

RCP초보자라면 지금까지 간단한 샘플을 통해서 RCP에 대한 몇가지 의미있는 가치들을 발견할 수 있었을 것이다. 응용프로그램을 자바로 하면서도 4GL보다 나은 프로덕을 쉽게 만들수있다는 것은 정말 강력한 매력이다.

아직은 RCP가 시장에서 붐은 아니지만 이클립스 RCP를 접한 사람중에서 그가치를 높게 평가하지 않는 사람은 없다. 자바 개발자라면 RCP를 접해두는 것은 꼭 필요하고도 가치있는 일이다.

View.java

NavigationView.java

MyRCP_src.zip

MyRCP_exe.zip