4.7. Stopping the extender bundle

Extender 번들이 멈추게stop 되면, Extender가 만든 모든 application context가 제거 될 것이다. Application context가 제거되는 순서는 다음과 같다.

1. 어떤 서비스도 export하지 않았거나, export 했지만 다른 번들들이 참조하지 않고 있는 application context를 가장 먼저 없앤다. 없앨 때는 번들 id의 역순으로 가장 최근에 설치된 번들의 application context부터 없앤다.

2. 1번 과정에서 import한 서비스들에 대한 레퍼런스가 끊기면서 새롭게 다시 1번 과정이 대상이 되는 application context가 생길것이다. 그렇다면 1번을 다시 수행한다.

3. 더이상 동작 중인 application context가 없다면, 멈춘다. 만약 여전히 남아있는 application context가 있다면, 이건 상호 참조cyclic depedency of references가 있다는 것이다. 이 경우에는 서비스 랭킹을 확인해서 랭킹이 낮은 녀석을 내린다. 그리고 1번부터 다시 한다.

4.6. Application Context Destruction

application context의 삶은 자신이 포함되어 있는 번들에 달려있다. 따라서 만약에 번들을 제거uninstall 하면, application context도 제거되고, export 했던 서비스들도 레지스트리에서 내리고, import 했던 서비스들도 제거한다.

번들만 별도로 닫히거나 전체 OSGi 플랫폼을 끄는 것과 같은 매우 큰 이벤트의 일부로 닫힐 수가 있다. 이런 경우이거나 extender 번들이 닫히는 경우에는, 서비스들 사이의 종속성에 근거하여 관리하에 닫게 된다. 자세한 내용은 다음 섹션에서…

4.4. The Resource abstraction

스프링은 리소스 추상화 계층을 제공합니다.
- Application Context는 그 녀석을 기본으로 탑재하고 있습니다.
- 모든 리소스는 application context가 가지고 있는 org.springframework.core.io.ResourceLoader가 읽어옵니다. 물론 이 녀석을 별도의 bean에 주입하고 직접 코딩을 통해서 리소스를 읽어와도 됩니다.
- 리소스의 경로 앞에 classpath: 또는 file: 접두어prefix를 사용하여 가져올 리소스의 경로를 지정할 수 있는데, 사용하는 application context의 구현체에 따라 기본으로 사용하느 접두어가 다릅니다.

OSGi 4.0.X 스펙에는 리소스를 읽어올 세 종류의 공간space을 정의하고 있습니다.
- 스프링 DM은 이 모든 것들을 적잘한 OSGi 맞춤 application context와 적잘한 접두어를 사용하여 지원합니다.























접두어


OSGi 리소스 로딩 방법


설명


classpath:


Class Space


번들 클래스로더(the bundle, all imported packages and required bundles)를 찾는다. 해당 번들들이 RESOLVED 상태가 되도록 강제한다. 이 방법은 OSGi API Bundle 클래스의 getResource(String)과 유사한 방법이다.


classpath*:


Class Space


번들 클래스로더(the bundle and all imported packages and required bundles)를 찾는다. 해당 번들들이 RESOLVED 상태가 되도록 강제한다. 이 방법은 OSGi API Bundle 클래스의 getResource(String)과 유사한 방법이다.


osgibundlejar:


JAR File(or JarSpace)


번들 jar만 찾는다. 번들을 RESOLVED 상태로 만들 필요 없이 low-level 접근을 제공한다.


osgibundle:


Bundle Space


번들 jar와 그것에 붙어있는 조각(fragment)들까지 찾는다. 클래스로더를 생성하거나 번들이 RESOLVED 상태가 되도록 강제하지 않는다.

노트
만약 접두어를 붙이지 않으면, 기본으로 bundle space(osgibundle:)를 사용합니다.

노트
OSGi의 동적인 특징 때문에, 번들 클래스패스가 생명주기 동안 변경 될 수 있습니다. 이것으로 인해 실행 중이 환경 또는 타겟 플랫폼에 기반해서 패턴 매칭을 할 때 전혀 다른 클래스패스 리소스가 반환될 가능성이 있습니다.

file: 이나 http: 같은 일반적인 스프링 리소스 접두어들도 물론 지원하며, 리소스 로딩이 되는 대상은 위치에 있더라고 상관없습니다. resource-loading 번들 또는 거기에 붙어있는 fragment에 국한되진 않습니다.

OSGi 플랫폼들이 번들에 들어있는 내용물을 찾기 위한 자신들 만의 독특한 접두어들을 가지고 있을 수도 있다. 예를들어, Equinox는 bundleresource: 와 bundlentry: 접두어를 가지고 있다. 물론 이렇게 플랫폼이 정의한 프리픽스도 스프링 OSGi(여긴 DM이라고 안 했네.ㅋㅋ)과 함께 사용할 수 있다. (특정, OSGi 구현체에 여러분들이 직접 타이핑하는 수고는 해야하다.)

4.5. Accessing the BundleContext

스프링 DM을 사용하면 OSGi API에 의존하지 않아도 된다.
- 정말로 OSGi의 BundleContext 객체에 접근하고 싶다면, 스프링이 도와줄 것이다.
- Extender가 만들어준 application context에는 BundleContext 타입의 bean 하나를 bundleContext라는 이름으로 항상 가지고 있다.
- 이 bean을 application context내의 다른 bean에 얼마든지 중입inject 할 수 있다.
- 거기다가, BundleContextAware라는 인터페이스까지 마련해 뒀다.
- 이 인터페이스를 구현한 bean들은 스프링이 bundleContext를 끼워넣어줄 것이다. 이 기능을 사용하려면, org.springframework.osgi.context 패키지를 import 해야한다.

public interface BundleContextAware {
public void setBundleContext(BundleContext context);
}

4.3. Bundle Lifecycle

OSGi는 다이내믹 플랫폼으로, 프레임워크가 동작하고 있는 도중에 번들을 설치, 시작, 업데이트, 멈춤, 제거 할 수 있다.

번들이 멈추면be stopped
- 번들이 등록한 서비스들은 모두 등록이 해지되고unregistered 번들은 RESOLVED 상태가 된다.
- 번들이 가지고 있던 자원을 반납하고 쓰레드도 종료한다.
- 번들이 노출 시켰던 패키지들은 번들이 멈추더라도 계속해서 다른 번들들에 의해 사용될 수 있다.

번들은 RESOLVED 상태에서 업데이트 할 수 있다.
- 업데이트하는 과정은 같은 번들을 특정 버전에서 다른 버전으로 이관migrate하는 것이다.

번들은 RESOLVED 상태에서 시작be started 될 수 있다.
- 시작되면 번들은 ACTIVE 상태가 된다.

OSGi의 PackageAdmin refreshPackages 명령어
- 전체 OSGi 프레임워크 또는 설치되어 있는 번들들의 모든 패키지를 리프래시한다.
- 리프래시하는 동안에 그 대상이 되는 번들의 Application Context는 멈췄다가 재시작한다.
- refreshPackages 명령 처리 후, 수정된 번들의 이전 버전 패키지 또는 제거된 번들의 패키지는 더이상 사용할 수 없다. 자세한 사항은 OSGi 스펙 참조.

(다시) 번들이 멈추면..
- application context는 자동으로 제거된다.
- 서비스들도 OSGi 서비스 레지스트리에서 제거된다.
- application context의 종료 라이프사이클(DisposableBean, destroy-method, @Post머시기..)이 진행된다.
- 멈춘담에 바로 다시 시작시키면, 새로운 application context를 만든다.