Eclipse Lab : 팀 블로그

커스텀 컨트롤을 만들 때 주로, Canvas를 상속받게 되는 데, 이 컨트롤이 애니메이션 요소를 갖고 있다면, 화면이 심하게 깜박거리는 것을 볼 수 있습니다. 이와 관련한 질문에는 더블 버퍼링을 쓰라는 답변이 많고, 코드까지 딸려있는데, 그래도 플리커링은 멈추지 않습니다. Canvas는 paint이벤트를 받으면, 스타일 플래그를 대조하여 SWT.DOUBLE_BUFFERED 값이 0이면 무조건 화면을 지우고 다시 그리기 때문에, 버퍼에 랜더링된 이미지를 한번에 찍는다 해도, 그 전에 지우는 과정이 눈에 보이기 때문입니다.

아래와 같이 생성자를 변경하면, 그리기 코드에 수동 버퍼나, 오프 이미지등과 같은 테크닉을 사용하지 않더라도 자동으로 더블 버퍼됩니다.

Canvas c = new Canvas(parent, SWT.DOUBLE_BUFFERED);

한 컴포넌트가 다른 컴포넌트와 닿는 접점으로 아주 흔하게 사용되는 것 중 하나가 바로 리스너 패턴입니다. 커플링도 적은 편이고, 이해하기도 쉬운 편이지요. 이클립스 같이 전사적인 블라인드 협력이 이뤄지는 구조에서는, 이러한 접점들을 안전하게 관리하는 것이 매우 중요합니다.

원칙1. 당신의 리스너가 완벽할 것이라는 기대를 버리시라.

그렇습니다. 우리는 인간이기 때문에, 거의 반드시라고 해도 좋을 정도로 실수를 하곤 합니다. 대부분의 실수는 지역적인 장해만을 발생시키지만, 컴포넌트의 접점에 문제가 발생할 경우, 그 지점과 연관된 모든 부분이 엉망이 되어 버릴 수 있으며, 심각 한 경우 사용자가 작업을 더 이상 진행 할 수 없게 되어버리기도 합니다. 그러므로 컴포넌트 접점은 좀 더 각별한 주의를 기울여 보호할 필요가 있습니다.

for(int i=0; i<100; i++){
	doSomething(i);
}

위의 코드를 예로 들어 봅시다. 만약 doSomething이라는 메서드가 i가 17일 때 문제를 일으켜 익셉션을 던진다고 가정 해 봅시다. 이 경우 정상적인 작업 83개가 17번 작업 때문에 모두 수행되어버리지 않게 됩니다.

이벤트를 제공하는 컴포넌트들은 여러개의 리스너를 가지고 있습니다. 만약 한 리스너가 문제를 일으킨다면, 아직 이벤트를 공급 받지 못한 나머지 모든 리스너들은 제대로 반응하지 못할 것이고, 이 후 같은 이벤트 통지역시 모두 마비 되어버리고 맙니다. 이 문제를 해결하기 위해서, 저는 불신과 배척이라는 테크닉을 이용합니다.

불신과 배척

불신과 배척의 철학은 아주 간단합니다. 기본적으로 리스너를 믿지 않으며, 문제를 일으킨 놈은 퇴출시켜 버립니다. 자 그 구현을 볼까요?

private Set<Listener> listeners;

private void fireEvent(Event e){
  Listener[] listenerArray = listeners.toArray(new Listener[listeners.size()]);

  for(Listener eachListener : listenerArray){
    try{
      eachListener.eventOccured(e);
    catch(Exception e){
      listeners.remove(eachListener);
      debug(eachListener + " 말썽쟁이를 쫒아냈어요.");
    }
  }
}

자 이제 한 줄 씩 살펴 볼까요? 우선 리스너 세트를 바로 이터레이트 하지 않고, 배열에 담은 다음 이터레이션 했습니다. 그 이유는 간단 합니다. 만약 리스너가 이 이벤트로 인해, 자기 자신을 리스너 그룹에서 제외하거나, 다른 리스너를 참가시킬 경우, 컨커런시 문제가 발생하기 때문이죠. 이미 for 문이 참조중인 컬렉션이 for 문이 도는 도중 변경 되어버리면 for 문은 어쩔 줄 몰라하게 되겠죠?

다음은 이터레이션 내부를 봅시다. try 로 모든 개별 리스너에게 통지할 때마다 문제를 감지하는 군요. 그렇다면 한 리스너가 문제를 일으킨다 하더라도, 다른 리스너들이 피해를 입지 않겠네요. 게다가 문제를 일으킨 녀석은 리스너 그룹에서 빼 버리는 군요. 저는 그저 추방했지만, 몇 번 더 기회를 줘 본다던지와 같은 재미있는 대응도 가능하겠죠?

장해 복구

그런데 이벤트에 대응하는 리스너가 UI를 변경하는 일은 흔히 있는 일입니다. 리스너의 개발자는 자기 자신이 UI 스레드 내에서만 호출될 거라며 바보같은 고집을 피우고 있을 지도 모릅니다. 하지만 정말 예상하지 못하게도, 다른 스레드에서 이벤트가 발생하는 경우는 종종 있습니다. 이렇게 흔히 발생할 수 있는 오류에 대해서는 다음과 같은 대응도 시도 해 볼 수 있습니다. 만약 발생한 예외의 종류가 InvalidThreadAccessException 이라면, UI 스레드에 동기화 하여, 이벤트를 한 번 더 전달 해 줘 보는 것이지요. 물론, 상태가 중복적으로 수정된다던가 하는 문제가 발생할 수도 있습니다. 도전과 실험은 여러분의 몫입니다.

결론

이클립스는 수많은 블라인드 협력을 통해 운영되는 독특한 공간 입니다. 자신이 실수를 하지 않았다고 해서, 자신의 클라이언트가 실수를 했다고 해서, 마비되는 컴포넌트를 작성해서는 결코 안되며, 좋은 이클립스 개발자가 되려면 이러한 경우 자신의 잘못으로 인정할 수 있는 반성이 필요합니다. 엔드유저가 격게될 피해를 최소화하는 것은 무엇보다 중요한 일입니다. 자신의 코드를 잘 만드는 것도 중요하지만, 협력의 준비가 되지 않은 코드는 아무리 우수하더라도 많은 이의 골칫거리가 될 뿐입니다.

어댑터 패턴

어댑터 패턴의 기본 전략 중 하나는, 한 객체가 특정한 영역에서만 의미를 갖는 기능집합을 요구 받을 때, 원래의 객체로 부터 분리된 어댑터 객체에게 그 임무들을 위임하는 것입니다. 이렇게 함으로써, 객체는 본래의 간결함을 유지 할 수 있으며, 개발자는 본인이 개발하지 않은 컴포넌트에 대해서도, 다른 영역에 참가시키는 것이 가능합니다.

기능영역 -> 컴포넌트: getAdapter();
컴포넌트 -> 컴포넌트: 어댑터 생성
컴포넌트 --> 기능영역: adapter
기능영역 -> 기능영역: 쓰임새 수행

일반적으로 어댑터 질의는 그림처럼 IAdaptable 인터페이스의 getAdapter(Class) 메소드를 통하여 이루어집니다. 하지만, 이 경우에, 어댑터 질의에 응답하는 주체가 객체 그 자체가 되기 때문에, 어댑터가 추가되거나 변경될 때 마다, 객체의 코드가 변경되어야 합니다. 이 경우엔 유연한 협력이나, 블라인드 확장(원래의 컴포넌트가 어떻게 구현되었는지 전혀 모르는 상태에서 기능을 확장시키는 것)이 불가능 합니다. 그러나 서로 모르는 사람들이 가장 많이 참여하는 프로젝트인 이클립스에서는, 이러한 상황이 매우 빈번하게 일어납니다. 이 문서는 모델과 어댑터간의 디커플링을 달성 하는 방법과 원리를 설명합니다.

어댑터 질의를 플랫폼에 위임

이런 문제를 해결하기 위해서 이클립스에서는 어댑터 질의를 플랫폼에게 위임하는 전략을 사용합니다.

기능영역 -> 컴포넌트: getAdapter()
컴포넌트 -> 어댑터매니저: 위임
어댑터매니저 -> 확장점: 팩토리 찾기
확장점 -> 확장점: 확장 탐색
확장점 -> 어댑터팩토리 : 생성
어댑터팩토리 -> 어댑터팩토리: 어댑터 생성
어댑터팩토리 --> 컴포넌트: adapter
컴포넌트 --> 기능영역: 쿼리 응답

이클립스에서 어댑터블한 객체들은 다음과 같은 기본 구현을 가지고 있습니다.

public Object getAdapter(Class adapterType){
	...
	return Platform.getAdapterManager().getAdpater(this, adapterType);
}

두 번 째 줄에서 보이는 바와 같이 이 객체는 어댑터 질의를 Platform에게 위임시킵니다. 따라서, 개발자는 플랫폼에 어댑터 공급 방법을 알려줌으로써, 원래 객체를 수정하지 않고도 어댑터를 추가 공급할 수 있습니다. 이렇게 어댑터를 추가적으로 공급하는데 쓰이는 확장점이 바로 런타임 어댑터 (확장점ID: org.eclipse.core.runtime.adapters) 입니다. 이 확장점은 특정한 타입의 객체에 대해, IAdapterFactory를 등록할 수 있게 해 줍니다. 마찬가지로 여러분이 만든 컴포넌트도 런타임 어댑터를 지원하려면, getAdapter()의 마지막 부분에 마찬가지의 코드를 삽입해야 합니다.

어댑터 팩토리

public interface IAdapterFactory {
	public Object getAdapter(Object adaptableObject, Class adapterType);
	public Class[] getAdapterList();
}

어댑터 팩토리는 위와 같은 메소드 구성을 가집니다. getAdapterList()는 이 어댑터 팩토리가 어떠한 종류의 어댑터 질의를 처리 할 수 있는지를 나타내고, getAdapter()는 실제로 어댑터를 만들어 플랫폼에 제출하는 역할을 합니다. 확장점 정의에보면, 이미 가능한 어댑터 종류에 대한 노드들이 있는데도 불구하고 구현 클래스도 질의를 받는 인터페이스가 있는 이유는, 확장점 뿐만 아니라, 프로그래밍으로도 어댑터를 등록할 수 있게 하기 위해서 입니다.

정리

하는 김에 같이 줏어먹기

Platform.getAdatper(...) 는 현재 활성화된 플러그인들 중에서만 런타임 어댑터 팩토리를 찾아내어 작동합니다. 만약 모든 플러그인과 연동되게 하려면, loadAdpater(...)를 사용해야 합니다. 이 경우, 어댑터 질의 과정중에 다른 플러그인이 활성화 될 수도 있다는 점을 염두에 둬야합니다.

Core Expression

만약 코어 익스프레션에서 adapter 노드를 사용한 경우에, 런타임 어댑터로 등록된 어댑터들만 리턴값이 넘어옵니다. 주의하세요.

Job

Job은 Job Manager에 의해 스케쥴 되고 실행 될 수 있는 작업 단위이다. 하지만 라이프 싸이클이 작업 주기에 한정되지는 않는다. Job이 한 번 완료되고 난 후에, 다시 스케쥴 될 수도 있다.

Job의 기본 사용법

1. Job을 상속 받아 적절한 작업을 기술 한다.
2. 해당 Job의 인스턴스에 schedule()을 호출하여 작업을 스케쥴 한다.
   

Job job = new MyJob("테스트 작업");
job.schedule();

Job은 현재 동작을 가리키는 상태를 가진다. Job이 처음 만들어졌을 때 상태는 NONE이 된다. 실행을 위해 스케쥴 되면, WAITING 상태가 되며, 수행중에는 RUNNING이 된다. 수행이 완료되거나 취소 되면 다시 NONE상태가 된다.

Job은 SLEEPING 상태로도 진입이 가능한다, 사용자가 Job.sleep()을 호출하거나, Job.schedule(delay)의 형태로 지연시간을 갖고 스케쥴 된 경우 이 상태가 된다. WAITING 상태인 Job들만 SLEEPING 상태로 넘어갈 수 있다. 이 Job들은 Job.wakeUp()으로 깨울 수 있으며 WAITING 상태로 돌아간다.

Job들은 우선순위를 가질 수 있지만, 높은 우선순위가 낮은 우선순위보다 먼저 수행된다는 보증을 가지고 있지는 않다. 

schedule

스케쥴 메소드는 현재 상태에 따라 다음과 같이 작동한다:

• NONE - 상태가 없는 경우: 스케쥴 된다
• WATING - 스케쥴 되었지만 아직 실행되지 않은 경우: 아무일도 하지 않음
• RUNNING - 실행중인 경우: 수행이 완료 된 후, 다시 스케쥴 됨, 이 상태에서 다시 스케쥴이 오더라도 한 번만 스케쥴 된다.

Job Manager

Job Manager는 Job들에 대해 스케쥴링, 쿼링, 관리 및 록을 제공하며, 다음과 같은 서비스를 공급한다:

• 대기중(WAITING)인 Job들이 실행 될 수 있게금, 큐를 관리한다.
• Job Family 라고 불리는 작업 그룹을 관리하도록 해 준다.
• 리스너들이 잡의 진행상황을 통보 받을 수 익도록 해 준다.
• Job이나 Job Family가 끝나기를 기다리는 클라이언트에게 피드백을 공급한다.

Schedule Rule

스케쥴 룰은 Job이 스케쥴 될 때 함께 JobManager 에 선포되어 효력을 발휘하고, 잡이 끝나면, 해당 잡이 제공했던 스케쥴 룰의 효력도 끝난다. Job은 스케쥴링 룰을 가질 수도 있고, 가지지 않을 수도 있다. 스케쥴링 룰이 없다면, 아무때에나 스케쥴 되고 수행 될 수 있음을 의미한다.

스케쥴 룰은 일반적으로, 특정한 리소스에 대해 배타적으로 작업들이 수행될 되어야 할 때 사용한다. Job.setRule(IScheduleRule)을 통해 Job의 스케쥴링 규칙을 정해 줄 수 있다. 스케쥴링 룰은 서로 포함 또는 배제라는 관계를 갖는데 각각 contains(IScheduleRule)과 isConflicting(IScheduleRule)로 구현된다.

• contains: 한 스케쥴 룰이 다른 스케쥴 룰을 포함한다는 것은 - 편의상 포함되는 룰을 자식, 포함하는 룰을 부모라 한다 - 부모 룰이 선포되어 운영되는 도중, 자식 룰이 함께 선포될 수 있음을 의미한다. 일반적으로 룰이 다른 룰에 대해 아는 것이 없을 경우에는 반드시 false를 리턴해야 한다.
  
• conflict: 두 스케쥴링 룰은 동시에 선포될 수 없으므로, 충돌하는 스케쥴 룰을 가진 Job들은, 먼저 수행된 Job이 끝나 해당 스케쥴링 룰의 운영이 끝난 다음 스케쥴 된다.
  

• 특정 리소스에 대해 록을 제공하는 룰
  ResourcesPlugin.getWorkspace().getRuleFactory().createRule(IResource)
  이는 매우 유용하면서 필수적인 도구이다. 이를 이용하여, 적절한 lock을 확보하지 않는다면, SVN이나 CVS 플러그인 들이 끔찍한 반응을 해 올 수도 있다.
  

IFile testFile = ....
// testFile 을 동시에 두 작업이 접근하지 못하도록 하는 룰
IScheduleRule fileAccessRule =
    ResourcesPlugin.getWorkspace().getRuleFactory().createRule(testFile);

Job job = new HandleFileJob();
job.setRule(fileAccessRule);

job.schedule();

// 이클립스 AutoBuildJob의 생성자
AutoBuildJob(Workspace workspace) {
	super(Messages.events_building_0);
	
	// 워크스페이스 루트 자체를 룰로 지정한다.
	// 빌드가 끝나기 전까지 어떤 다른 Job도 워크스페이스에 접근 할 수 없다.
	setRule(workspace.getRoot());

	setPriority(BUILD);
	isAutoBuilding = workspace.isAutoBuilding();
	this.workspace = workspace;
	this.preferences.addPropertyChangeListener(this);
}

Job의 종류

작업이 진행되는 배경적 특성에 따라 몇 가지 유용한 부모 Job 클래스들이 공급된다.

• WorkspaceJob: 워크스페이스 잡은, 잡이 종료될 때 까지 발생하는 모든 리소스 변경 통지를 멈춰두었다 작업이 완료된후 일시 통보하는 기능을 가진다. 만약, 수많은 파일을 일괄적으로 변조하는 작업을 수행할 때 이러한 조치를 취하지 않는다면, 자동 빌딩이 끝 없이 스케쥴되는 골치 아픈 광경을 볼 수 있게 될 것이다.
  
• WorkbenchJob: 원래는 워크벤치가 소멸되거나 완전히 준비되기 전에 작업이 수행되는 것을 방지하기 위해 고안 되었지만, 작업이 UI수정을 포함할 때도 많이 쓰인다. UI 스레드와 동기화되어 실행되기 때문이다. - 워크밴치가 시작 되자 마자 무언가가 실행되게 하고 싶다면, 이를 상속하는 것이 좋다.

Job Family

Job 들은 필요에 따라 특정 분류그룹을 가질 수 있으며, 여러 그룹에 속할 수도 있다. public boolean belongsTo(Object family)를 오버라이드 하여, 특정 Job이 어떤 패밀리에 속하는지 기술 할 수 있다. Job.getJobManager()는 패밀리 객체를 통한 Job 찾기등의 API를 공급하기 때문에, 각 Job들이 스캐쥴되거나 실행될때마다 같은 그룹에 속한 Job의 상태에 따라 반응하게 하는 것이 가능하다. 예를 들어, 여러번의 업데이트 Job 중 가장 마지막에 스케쥴 된 Job만 실행되게 할 수 있다.

ChangeRecorder

// 임의의 ecore 모델을 하나 만든다.
Person jiyul = MyFactory.eINSTANCE.createPerson();
jiyul.setName("Jiyul");

// 롤백 디스크립션 작성 시작
ChangeRecorder recorder = new ChangeRecorder(jiyul);

// 모델을 변경 시킴
jiyul.setName("Sid Vicious");

// 녹화 종료
ChangeDescription rollbackDescription = recorder.endRecording();

// 녹화된 내용을 역으로 적용
rollbackDescription.apply();

System.out.println(jiyul.getName());

트랜잭션 처리

ChangeRecorder recorder = new ChangeRecorder(model);
try{
	모델을 조작하는 코드들이 여기에 위치한다...
}catch(Exception e){
	// 모델을 다루는 작업 도중 문제가 발생한 경우 롤백 시킨다.
	recorder.endRecording().apply();
}

ChangeDescription

// 녹화 종료
ChangeDescription description = recorder.endRecording();

// 변경된 내용을 xml로 출력
ResourceSet rs = new ResourceSetImpl();
XMLResource resource = 
    (XMLResource) rs.createResource(URI.createFileURI("test.xml"));
resource.getContents().add(description);
resource.save(System.out, new HashMap<Object, Object>());