이 글은 Neil Bartlett 의 연재 글 “Getting started with OSGi”의 번역본입니다.

* 파트 1 – 첫번째 번들 : Your First Bundle

* 파트 2 – 프레임워크와 연동하기 : Interacting with the Framework

* 파트 3 – 번들간의 의존관계 : Dependencies between bundles

* 파트 4 – 서비스 등록하기 : Registering a Service

* 파트 5 – 서비스 사용하기 : Consuming a Service

* 파트 6 – 동적으로 서비스 추적하기 : Dynamic Service Tracking

에 이어 7번째 글입니다. 오탈자 및 이상한 번역은 댓글로 남겨주세요

Getting started with OSGi : OSGi 시작하기 파트 7 – 선언적 서비스 소개하기

저자 : Neil Bartlett < njbartlett at gmail dot com >

역자 : 권 정혁 < guruguru at gmail dot com >

글원본 : http://www.eclipsezone.com/eclipse/forums/t96740.html – Getting started with OSGi : Introducing Declarative Services

매우 늦어져 버린 “Getting Started with OSGi” 시리즈에 오신걸 환영합니다. 이번 회는 선언적 서비스에 대해 알아볼것이므로 매우 재미있을 것입니다.

선언적 서비스(Declarative Services , DS) 스펙은 OSGi 의 새로운 부분중의 하나로서, 번들간의 서비스를 연결할때 생기는 이슈들의 결과로 생겨났습니다. 이 작업이 어렵다는 것이 아니라 ( 제 예전 튜토리얼들이 보여주었을꺼라고 희망합니다. ) 꽤 많은 양의 반복적인 코드(boilerplate)를 필요로 하기 때문입니다. 또한, 쓰레드 문제때문에 조심해야 하며 이는 쉽게 당신의 발에 총을 쏠수 있게 된다는 것입니다. (shoot yourself in the foot, 역주: 쉽게 실수할 수 있다는 것으로, 그냥 원문대로 번역했습니다. http://burks.bton.ac.uk/burks/language/shoot.htm 참고하세요)

이 문제를 해결하기 위한 초기 시도는 Humberto Cervantes 와 Richard Hall 이 만든 툴인 Service Binder 였습니다. Service Binder 는 automated service dependency management(자동 서비스 의존관계 관리) 를 소개하여 개발자에게 자신들의 서비스만을 작성하는데 집중하도록 했습니다. 서비스간의 연결은 선언적으로 처리되었고, 이 선언들은 XML 로 작성되었습니다.

선언적 서비스의 스펙은 Service Binder 에서 발전된것으로 이제는 OSGi 버전 4.0 이상에선 표준이 되었습니다. 그럼, 이제 이것이 우리에게 무엇을 해줄수 있는지 보죠.

지난회에서 말씀드렸듯이, 이제 커맨드 라인에서 모든것을 하는 것이 힘들어졌으므로 지금부터는 Eclipse SDK 를 사용하도록 하겠습니다. 그렇지만 제가 소개하는 것들이 정말 Eclipse 에 종속적이지는 않다는것을 기억해주세요. 비록 Eclipse 가 우리가 하려는 것들을 많이 도와주기는 하지만, 어떤 흑마법도 없으며, 여기서 보시는 어떤 것도 NetBeans 나 IntelliJ 또는 오래된 vi 라도 가능합니다.

첫번째로 할일은 선언적 서비스에 대한 Equinox 구현을 다운로드 하는것입니다. 안정적인 Eclipse 버전을 사용하고 있으시다는 가정하에 ( 이글 쓰는 시점에서는 3.2.2 ), 다운받기 링크는 여기 입니다. 다른 버전을 사용하고 계시다면, 여기 Equinox 의 상위레벨 다운로드 페이지 에서 맞는 버전의 org.eclipse.equinox.ds_x.x.x_xxxxx.jar 파일을 찾으셔야 합니다. 다운로드가 끝나면, Eclipse가 설치된 디렉토리 하부의 plugins 디렉토리에 복사하고 Eclipse 를 재시작 하세요. 만약에 여러분이 Eclipse plug-ing 개발에 약간 알고 계신다면, 이 Jar 파일을 Target Platform 폴더에 넣으셔야 합니다. “Target Platform”이 뭔지 모르신다면, 아무 걱정마시고 그냥 plugins 폴더에 JAR 파일을 넣어주세요.

자 이제 새로운 번들을 만들 것입니다. Eclipse 에서 Plug-in 프로젝트 위자드를 이용해서 새로운 프로젝트를 생성합니다.

1. 메인 메뉴에서 File -> New -> Project 를 선택합니다.
2. Plug-in 프로젝트를 선택하고 Next를 누릅니다.
3. 프로젝트의 이름을 SampleExporter 라고 입력합니다.
4. 아래쪽 “This plug-in is targeted to run with” 항목 밑에, “an OSGi framework” 를 선택하고 그 옆 드롭다운리스트에서 “standard” 를 선택하세요. 이 단계는 꼭 필요한>것은 아니지만, 우리가 실수로라도 다른 OSGi 프레임워크 구현들이 기본으로 가지고 있은 기능(Out-of-the-box)외의 것들을 사용하지 못하도록 막아줍니다.
5. Next 를 누릅니다. 다음에 나오는 Wizard 페이지에서, “Generate an activator…” 의 체크박스를 해제하고, Finish 를 누릅니다.

이제 우린 빈 번들 프로젝트를 하나 가지게 되었으므로, 코드를 추가해 봅니다. 일을 쉽게 하기위해 , 모든 자바 런타임에 들어있는 인터페이스인 java.lang.Runnable 을 이용하는 서비스를 만들어 봅니다. 이클립스 단축키를 이용해서, 아래코드를 브라우저에서 직접 복사한후에 SampleExporter 프로젝트에 있는 src 폴더를 선택하고, Edit->Paste 를 선택해보세요. Eclipse 가 패키지와 소스파일을 만들어 줄것입니다.

package org.example.ds;
public class SampleRunnable implements Runnable {
 public void run() {
   System.out.println("Hello from SampleRunnable");
 }
}

지금까지는 특별한게 없습니다만, 이제 재미있어지는 부분이 나옵니다. 우린 SampleRunnable 을 서비스로 선언하는 XML 파일을 생성할 것입니다. 프로젝트 최상단에 OSGI-INF 라는 폴더를 만들고 그 안에 samplerunnable.xml 파일에 아래 내용을 복사하세요.

<?xml version="1.0"?>
<component name="samplerunnable">
 <implementation class="org.example.ds.SampleRunnable"/>
  <service>
   <provide interface="java.lang.Runnable"/>
  </service>
</component>

이것은 우리가 DS 에서 보게될 간단한 선언 형식중 하나입니다. 내용인 즉슨, java.lang.Runnable 의 인터페이스를 이용하여 OSGI Service Registry에게 서비스를 제공하는 samplerunnable 이라는 컴포넌트가 있고, 컴포넌트의 구현 클래스는 org.example.ds.SampleRunnable 이라는 것입니다. 마지막 단계는 Declaratie Services 런타임에게 XML 파일의 존재를 알리는 것입니다. 우린 이것을 번들의 MANIFEST.MF 에 필드를 추가함으로써 가능합니다. Manifest를 열고(프로젝트에서 우측버튼 클릭후 PDE Tools -> Open Manifest를 이용해보세요), 직접 manifest 편집이 가능한 MANIFEST.MF 탭으로 가서 아래 라인을 추가합니다.

Service-Component: OSGI-INF/samplerunnable.xml

그리고는 파일을 저장합니다. 이전회에서처럼, manifest 의 맨 마지막 빈줄을 매우 중요합니다. 하지만 이전과는 다르게 만약 당신이 잊는다해도 Eclipse 가 에러메시지를 출력할 것입니다.

더 진행하기 전에, Equinox 를 실행해서 이것이 동작하는지 봅시다. Run 메뉴로 가서 “Run…” 메뉴를 선택해서 다이얼로그가 열리면 “Equinox OSGi Framework” 를 왼쪽 트리에서 선택하고 New 버튼을 누릅니다. 만약 여러분이 Eclipse 에는 경험이 있지만, OSGi 개발은 안해보셨다면, 이 런쳐 다이얼로그는 약간 이상해 보일것입니다. Bundles 라고 이름붙여진 첫번째 탭은 Launch 설정에서 어떤 번들이 선택될 지, 초기화시에 자동으로 시작할지,아니지를 결정할수 있게 해줍니다. 최소의 세트를 가지려면, Deselect All 을 누르고, 아래 번들들만을 선택합니다.

• SampleExporter (Workspace 항목 하부에)
• org.eclipse.equinox.ds (Target Platform 항목 하부에)

이 번들들이 우리가 관심을 가지고 있는것이지만, 이들은 의존관계를 가지고 있으므로, Add Required Bundles 를 눌러서 다른 번들들을 선택되게 합니다. “Validate bundles automatically prior to launching”(실행시 자동으로 번들 검증) 을 선택하는것도 좋은 생각입니다. 마지막으로 Run 을 선택하면 바로 osgi> 프롬프트가 Eclipse 콘솔에 표시될것입니다. OSGi 프레임워크가 실행중이므로, 이전에 배웠던 커맨드들을 사용해 볼수 있습니다.

우리 서비스가 등록되었나요 ? services 명령으로 확인해 볼수 있습니다. 서비스 리스트중에-아마도 마지막쯤에-아래와 같은것을 보실수 있습니다.

{java.lang.Runnable}={component.name=samplerunnable, component.id=1, service.id=22}
  Registered by bundle: initial@reference:file:..../SampleExporter/ [5]
  No bundles using service.

네 등록되었습니다! 주목할건 서비스 등록이 Declarative Services 번들에 의해서가 아니라 우리 번들에 의해 이루어 졌다는 것입니다. 실제로 DS 가 우리 번들을 대신하여 등록해준것입니다. 뒤에 어떻게 그렇게 하는지를 살펴볼 것이지만, 이 레슨의 목적은 우리 서비스의 사용자가 어떤 특별한 일을 할 필요가 없다는것입니다. 실제론 사용자는 우리가 Declarative Services 를 사용하고 있다는것을 알 필요도 없습니다. 사용자 또한 원한다면 Declarative Services 를 사용할 수 있지만, 또한 그냥 OSGi 코드를 직접 이용할 수도 있습니다.

또 하나 주목할것은, 우리의 번들에는 어떤 OSGi 관련 자바 코드도 없다는 것입니다. 다른말로, 우리가 생성한 클래스는 POJO 이고, 이것이 Declarative Services 의 주요 기능입니다.

이번회는 여기까지입니다. 이번 레슨이 너무 기초적인것이라 미안합니다. 다음회에서는 DS 를 이용하여 어떻게 서비스를 사용하는지 알아봄으로써 DS가 제공하는 파워와 편리함을 알수 있을것입니다.

이 글은 Neil Bartlett 의 연재 글 “Getting started with OSGi”의 번역본입니다.
* 파트 1 – 첫번째 번들 : Your First Bundle
* 파트 2 – 프레임워크와 연동하기 : Interacting with the Framework
* 파트 3 – 번들간의 의존관계 : Dependencies between bundles
* 파트 4 – 서비스 등록하기 : Registering a Service
* 파트 5 – 서비스 사용하기 : Consuming a Service
에 이어 6번째 글입니다. 오탈자 및 이상한 번역은 댓글로 남겨주세요

Getting started with OSGi : OSGi 시작하기 파트 6 – 동적으로 서비스 추적하기

저자 : Neil Bartlett < njbartlett at gmail dot com >
역자 : 권 정혁 < guruguru at gmail dot com >

글원본 : http://www.eclipsezone.com/eclipse/forums/t91059.html – Getting started with OSGi : Dynamic Service Tracking

EclipseZone OSGi 미니 시리즈에 돌아오신걸 환영합니다.

지난번에는 Martin Fowler 의 시나리오(특정감독에 의해 제작된 영화를 찾는 MovieFinder 에 의존하는 MovieLister)를 이용해서 어떻게 서비스를 사용하는지를 알아봤습니다. 또한, MovieLister 가 MovieFinder 의 인스턴스를 찾지 못할때 무엇을 해야하는지를 통해 동적인 OSGi 서비스의 본질에 대해 살펴보았습니다.

우리가 지난번에 고려하지 않았던 다른 것이 있습니다. 만약 한개 이상의 MovieFinder가 있다면? 즉, 어떤 번들이라도 MovieFinder 인터페이스를 구현하는 서비스를 등록할수 있고, 레지스트리 입장에선 모든 번들은 같습니다.

우린 문제를 간단히 무시할 수도 있고, 실제로 지난번엔 그렇게 했습니다. ServiceTracker 에게 getService()를 호출함으로써, 우린 서비스 레지스트리에 의해 선택된 임의의 MovieFinder 인스턴스를 받게 됩니다. 이 선택에 영향을 줄수있는 여러가지 방법이 있지만(예를 들어, SERVICE_RANKING 속성을 서비스 등록시에 지정함으로써), 사용자로서의 우리는 이 선택에 대한 완벽한 조정능력을 가지지는 못합니다. 그리고 실제로 더 많은 조정능력을 가지게 되는것은 좋은게 아닙니다. 즉 우리는 MovieFinder 의 어떤 인스턴스라도 사용할수 있어야 한다는것이죠. 우리가 처음부터 인터페이스를 사용하는 이유이기도 합니다.

대신에 여러개의 서비스 인스턴스들에 대해 인지하고 사용하는 것은 때때로 유용할수도 있습니다. 예를 들어, 여러개의 MovieFinder 인터페이스가 가용하다면 MovieLister 가 이용할수 있는 영화 데이타에 대한 여러개의 소스가 있다는것을 의미합니다. 검색시에 이들을 모두 이용함으로써, 더 넓고 유용한 검색결과를 사용자에게 제공할 수 있게됩니다.

마지막에 논의했던 문제로 다시 돌아가서, 만약 MovieFinder 서비스가 사용 불가하다면 어떤일을 하는것이 맞을까요 ? 우린 MovieFinder 가 가용하지 않을때 listByDirector 메소드가 호출될때마다 null 을 리턴하는 간단한 방법을 사용했습니다. 하지만 MovieFinder 가 존재하지 않는다면 MovieLister 의 메소드 호출도 볼가능하게 하면 어떨까요 ?

MovieLister는 MovieFinder 와 마찬가지로 서비스입니다. 만약 MovieFinder 서비스가 사라진다면, MovieLister 도 같이 사라지게 하는건 ? 다시 말해, 우린 MovieLister 서비스가 MovieFinder 에 대해 “1 대 다” 관계를 가지기를 원했습니다. 마지막 튜토리얼에서 우린 “0 대 1” 관계였습니다.

MovieListerImpl 를 변경해봅시다. 아래 코드와 교체하세요.

package osgitut.movies.impl;
import java.util.*;
import osgitut.movies.*;
public class MovieListerImpl implements MovieLister {
  private Collection finders =
   Collections.synchronizedCollection(new ArrayList());
  protected void bindFinder(MovieFinder finder) {
   finders.add(finder);
    System.out.println("MovieLister: added a finder");
 }
  protected void unbindFinder(MovieFinder finder) {
   finders.remove(finder);
   System.out.println("MovieLister: removed a finder");
 }
  public List listByDirector(String director) {
    MovieFinder[] finderArray = (MovieFinder[])
     finders.toArray(new MovieFinder[finders.size()]);
    List result = new LinkedList();
    for(int j=0; j < finderArray.length; j++) {
      Movie[] all = finderArray[j].findAll();
      for(int i=0; i < all.length; i++) {
        if(director.equals(all[i].getDirector())) {
          result.add(all[i]);
       }
     }
   }
   return result;
 }
}

이제 우린 MovieListerImpl 에서 OSGi 에 대한 의존성을 없앴습니다. 이젠 순수 POJO 입니다. 어쨋든, 이 클래스는 누군가 또는 어떤것이 MovieFinder 서비스를 찾아서 bindFinder 메소드를 통해 제공되어야 합니다. 이렇게 하기위해서 osgitut/movies/impl/MovieFinderTracker.java 라는 새로운 파일을 아래와 같이 작성합니다.

package osgitut.movies.impl;
import org.osgi.framework.*;
import org.osgi.util.tracker.*;
import osgitut.movies.*;
public class MovieFinderTracker extends ServiceTracker {
  private final MovieListerImpl lister = new MovieListerImpl();
  private int finderCount = 0;
  private ServiceRegistration registration = null;
  public MovieFinderTracker(BundleContext context) {
   super(context, MovieFinder.class.getName(), null);
  }
  private boolean registering = false;
  public Object addingService(ServiceReference reference) {
   MovieFinder finder = (MovieFinder) context.getService(reference);
    lister.bindFinder(finder);
    synchronized(this) {
     finderCount ++;
      if (registering)
        return finder;
      registering = (finderCount == 1);
      if (!registering)
       return finder;
    }
   ServiceRegistration reg = context.registerService(
   MovieLister.class.getName(), lister, null);
    synchronized(this) {
     registering = false;
      registration = reg;
    }
   return finder;
  }
 public void removedService(ServiceReference reference, Object service) {
   MovieFinder finder = (MovieFinder) service;
    lister.unbindFinder(finder);
   context.ungetService(reference);
    ServiceRegistration needsUnregistration = null;
   synchronized(this) {
     finderCount --;
      if (finderCount == 0) {
       needsUnregistration = registration;
        registration = null;
      }
    }
   if(needsUnregistration != null) {
      needsUnregistration.unregister();
    }
  }
}

이 클래스는 지난번에 얘기했던 ServiceTracker 클래스를 오버라이드 해서, ServiceTracker 가 서비스 등록/삭제시 동작하는 방식을 커스터마이즈 합니다. 특징적으로, MovieFinder 서비스가 추가될때 addingService 메소드가 호출되고 , MovieFinder 가 제거될때 removedService 가 호출됩니다. 우리가 오버라이드 할수 있는 메소드중에 modifiedService 도 잇습니다만 여기선 필요하지 않습니다.

이 두개의 메소드에 대해선 살펴볼만한 가치가 있습니다. 첫째로 addingService 에선 전달받은 인자가 실제 서비스 구현 개체가 아니라 ServiceReference 입니다. ServiceReference는 인자로 전달될수 있는 가벼운 핸들이며, 서비스에 대한 속성(서비스 등록시에 전달했던)를 읽는데 사용이 가능합니다. 결정적으로, ServiceReference 를 얻는것은 OSGi 프레임워크가 해당 서비스의 레퍼런스 카운트를 증가시키지 않습니다. Java Reflection API 에 있는 WeakReference 클래스와 비슷하게 생각하시면 됩니다.

예제에서 우리가 ServiceReference 로 할 첫번째 작업은 MovieFinder 서비스 개체를 얻는것입니다. 이를 위해서 우린 다시 BundleContext 를 필요로 합니다. (OSGi 프레임워크와 관련된 모든 작업은 BundleContext 인터페이스를 통해 이뤄진다는걸 명심하세요. ) 편리하게도 슈퍼클래스인 ServiceTracker 가 BundleContext 에 대한 레퍼런스를 context 라고 이름붙인 protected 멤버로 가지고 있으므로 바로 사용할 수 있습니다.

다음으로 우리가 위에서 정의한 MovieListImpl 의 bindFinder 메소드를 가지고 파인더를 바인딩 합니다. 그리고 MovieListerImpl 자체를 MovieLister 인터페이스로 서비스에 등록합니다. 이미 서비스가 등록되지 않았을때만 서비스를 등록하고 있다는 걸 주의하세요. 이번 시나리오 에선 한개의 MovieLister 가 여러개의 MovieFinder 서비스를 추적하기를 원합니다.

마지막으로 메소드에서 리턴합니다. 여기에 흥미있는 부분이 있습니다. addingService 의 리턴타입은 그냥 Object 입니다. 우린 무엇을 리턴해야 할까요 ? 사실은 ServiceTracker 는 상관하지 않습니다. 우리가 원하는 어떤것을 리턴해도 됩니다. 어쨋거나, 우리가 addingService 에서 리턴하는 객체는 modifiedService 나 removedService 가 호출되었을때 우리에게 다시 주어집니다. 그러므로 removeService 메소드의 첫번째 줄을 보시면, 우리가 객체를 MovieFinder 로 캐스팅하는것을 볼수있습니다. 이렇게 해서 리스터로 부터 unbound 될수 있는것이죠. 그리고는 만약 추적하는 finder 들이 0개가 되었을때 MovieLister 서비스를 등록해제 합니다.

일반적으로, 우리가 addingService 에서 한 일들은 removedService 메소드에서 되돌려 놔야 합니다. 그러므로, addingService 메소드에서 리턴할것은 우리가 무슨일을 했는지를 알수있도록 도와주는 것이야 합니다. HashMap 에서의 Key가 될 수도 있고, ServiceRegistration 객체일수도, 이번 경우처럼 실제 서비스 객체일수도 있습니다.

removedService 의 마지막 단계로, 우리가 “가져왔던(Got)” 서비스를 “돌려줘야(Unget)” 합니다. 이는 서비스 레지스트리가 서비스 사용 카운터를 줄이게 해서, 카운터가 0 이 되었을때 서비스가 해제될수 있도록 하기위한 것이므로, 매우 중요합니다.

자 이제 우린 Activator 가 필요합니다. osgitut/movies/impl/TrackingMovieListerActivator.java 입니다.

package osgitut.movies.impl;
import org.osgi.framework.*;
public class TrackingMovieListerActivator implements BundleActivator {
 private MovieFinderTracker tracker;
 public void start(BundleContext context) {
    tracker = new MovieFinderTracker(context);
   tracker.open();
 }
  public void stop(BundleContext context) {
   tracker.close();
  }
}

Manifest 파일 TrackingMovieLister.mf 입니다.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Tracking Movie Lister
Bundle-SymbolicName: TrackingMovieLister
Bundle-Version: 1.0.0
Bundle-Activator: osgitut.movies.impl.TrackingMovieListerActivator
Import-Package: org.osgi.framework,
 org.osgi.util.tracker,
 osgitut.movies;version="[1.0.0,2.0.0)"

이 번들을 빌드해서 Equinox 에 설치하는것은 여러분께 연습으로 남겨둡니다. 그후에는 아래 단계들을 따라해서 모든것이 동작하는지를 살펴보세요.

1. BasicMovieFinder 를 실행하고 TrackingMovieLister 를 실행합니다. “MovieLister: added a finder” 메시지가 나오는지 확인.
2. services 명령을 입력해서 MovieLister 가 등록되어 있는지 확인합니다.
3. BasicMovieFinder 를 중단하고 “MovieLister: removed a finder” 메시지가 나오는지 확인.
4. services 명령을 다시 입력해서 MovieLister 서비스 등록이 해제 되었는지 확인.

우리가 여기서 한 작업은, 매우 강력한 기술의 토대를 다진거라고 볼수 있습니다. 우리는 한개의 서비스의 라이프사이클을 다른 서비스(실제로는 여러개의 다른 서비스)의 라이프사이클에 연결하였습니다. 이 기술을 더 발전시키면, MovieLister 에 연결된 다른 서비스를 가질수도 있고, 또 거기에 의존하는 다른 서비스 등등.. 우리는 서로 의존하는 서비스들의 그래프를 만들었습니다. 하지만 다른 정적인 IOC 컨테이너에 의해 만들어진 bean 들의 그래프와는 달리 우리의 그래프는 튼튼하며, 자가 치유능력이 있고, 변화하는 환경에 적응할 수 있습니다.

한편으로 우리가 작성한 코드에는 약간의 문제가 있습니다. MovieFinderTracker 와 TrackingMovieListerActivator 클래스는 반복사용 되는 문장들이 가득해서, 우리가 시스템을 확장하기 시작한다면 우리는 같은 코드를 매번 조금씩만 바꿔서 작성하게 되어 매우 피곤해 질것입니다. 그러므로 다음회에서는 이 모든 코드를 몇줄의 XML 로 변경하는 방법을 알아볼 것 입니다.

다음회부터는 이제 한 디렉토리에서 커맨드 라인 툴로 모든것을 작성하는것을 그만둘 것입니다. 이 튜토리얼을 시작할때 저의 목표는 OSGi 는 간단하면서도 강력한 프레임워크 이며, OSGi 번들을 개발하기 위해서 Eclipse 같은 무겁고 강력한 IDE 가 필요하지는 않다는것을 보여주는 것 이었습니다. 어떤 것이 매우 쉽다고 보여질때 , 우리는 한편으론 IDE 가 어떤 흑마법을 사용한 것이 아닐까 하는 의구심을 가지게 됩니다. 전 이번 경우 엔 그런것과 달리, OSGi 가 그런 흑마법은 필요하지 않다는 것 을 보여주었기를 희망합니다. 한편으로, 만약 이 코드를 넣는 디렉토리가 제것과 비슷하다면, 여러분께서도 이제 적절한 개발환경을 원하고 계실겁니다. 저 역시 그렇습니다. 이것은 물론 OSGi 의 문제가 아닙니다. 어떤 Java 프로젝트라도 표준 툴만을 이용한다면 금방 관리하기 힘들어 집니다.

하여튼, 죄송하지만 다음회까지 여러분께선 EclipseCon 이 끝나는것을 기다리셔야 할듯합니다. 전 24시간안에 Santa Clara 로 가는 비행기를 탑니다. 거기서 뵙기를!
(역주: 작년글이라 위 내용은 필요없겠지만 원문과의 일치를 위해 그냥 번역합니다 ^_^ )

Concurrent Code 를 위해 더 나은 방법을 제공해준 BJ Hargrave 에게 고맙다는 말을 전합니다.