Whiteship's Note


4.7. Stopping the extender bundle

Spring DM/Chapter 4 : 2008.04.13 12:41


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번부터 다시 한다.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.6. Application Context Destruction

Spring DM/Chapter 4 : 2008.04.13 12:34


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

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

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.4. The Resource abstraction

Spring DM/Chapter 4 : 2008.04.12 18:00


스프링은 리소스 추상화 계층을 제공합니다.
- 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 구현체에 여러분들이 직접 타이핑하는 수고는 해야하다.)

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.5. Accessing the BundleContext

Spring DM/Chapter 4 : 2008.04.12 07:58


스프링 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);
}

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.3. Bundle Lifecycle

Spring DM/Chapter 4 : 2008.04.11 21:20


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를 만든다.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.2. Application Context Creation

Spring DM/Chapter 4 : 2008.04.11 21:03


Extender 번들은 application context를 비동기적으로 생성한다.
- OSGi 서비스 플랫폼 시작 속도를 빠르게 해준다.
- 서비스들 간의 종속성으로 인한 데드락의 위험이 없다.
- 따라서 스프링 DM을 사용한 번들의 application context가 만들어지기 전에 STARTED 상태가 될 수 있다.
- 5.1을 참조하면, 동기적으로 번들을 생성하도록 설정하는 방법을 참조할 수 있다.
- 만약 application context를 무슨 이유에서건 생성하지 못했다면, 로그를 남기고 번들은 여전히 STARTED 상태다. 단, 해당 번들이 export한 서비스는 하나도 없는 상태로..

1. Mandatory Service Dependencies


OSGi 서비스의 가용성에 필수적인 mandatory 의존성을 선언하면, 해당 application context의 생성은 OSGi 서비스 레지스트리를 통해서 필수적인 의존성을 만족 시킬 때까지 대기 block 한다.
- 6장 서비스 레지스트리에서 필수적인 서비스 레퍼런스를 찾지 못할 때 어떤일이 벌어지는 지 설명한다.
- 이런 원리로 스프링 DM은 번들들이 어떤 순서대로 시작되는 상관없이 필수적인 종속성을 가지도록 보장한다.
- 타임아웃을 설정할 수 있다. 기본은 5분이다. timeout 지시자에 그 값을 설정할 수 있다. 5.1 참조.
- 해당 번들 실행시 필요한 서비스를 못찾으면 바로 application context 생성을 실패하도록 설정할 수 있다.(fail-fast) 이 경우 해당 번들은 ACTIVE 상태가 아니라 RESOLVED 상태로 남게 된다.

2. Application Context Service Publication


번들의 application context 생성이 완료되면, application context 객체는 자동으로 OSGi 서비스 레지스트리에 하나의 서비스로 등록이 된다.
- org.springframework.context.ApplicationContext 인터페이스 아래로 공개된다.
- 공개된 서비스들은 org.springframework.context.service.name 이라는 서비스 속성을 가지고 있다. 이 값은 해당 application context를 가지고 있는 번들의 Symbolic Name으로 설정된다.
- application context를 서비스로 등록하는 걸 막을 수도 있는데, 이건 5.1에서 살펴본다.

노트: Application context가 서비스로 등록되는 이유는 testing, administration, management를 하기 위해서다. context 객체에 런타임시 접근하여 getbean() 같은 것을 호출하는 행위를 하지 말기 바란다. 다른 번들의 application context에 등록되어 있는 Bean을 가져오고 싶을 때 권장하는 방법은 일단 OSGi 서비스로 해당 bean을 export하고, 그걸 참조하고 싶어하는 context에서 서비스로 import하는 것이다. 이렇게 서비스 레지스트리를 통해서 가져와야 그에 상응하는 버전에 해당하는 서비스만 참조하는 것을 보장하며, OSGi 플랫폼이 동적으로 관리하는 서비스를 가져올 수 있다.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


4.1. The Spring Dynamic Modules Extender bundle

Spring DM/Chapter 4 : 2008.04.10 22:41


스프링 DM은 org.springframework.osgi.bundle.extender라는 번들을 제공한다.

이 번들은 번들에서 사용할 스프링 application context를 생성해준다. 스프링 웹 애플리케이션의 ContextLoaderListener와 같은 역할을 한다.

extender 번들이 설치 installed 되고 시작 started 되면 이미 Activce인 상태의 번들 중에 스프링 DM을 사용하는 번들을 찾아서 application context를 만들어 준다.

또한, 번들 시작 이벤트를 주시 listening 하다가 스프링 DM을 사용한 번들이 시작되면 application context를 만들어 준다.

5.1에서 extender가 어떻게 스프링 DM을 사용한 번들로 인식하는지 알아본다.

Extender Pattern

"allow other bundles to extend the functionality in a specific domain"
특정 도메인에 있는 기능을 다른 번들들이 확장할 수 있도록 하는 패턴.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top


Bundles and Application Contexts

Spring DM/Chapter 4 : 2008.04.09 23:08


OSGi 번들

OSGi에서 배포 단위는 번들.
번들은 런타임시에 세 가지 steady 상태 중 하나가 됨. installed, resolved, active.
번들은 서비스를 OSGi 서비스(객체) 레지스트리에 등록하여 다른 번들이 해당 서비스를 사용하도록 할 수 있슴.
번들은 패키지를 노출 시켜서 다른 번들들이 노출 된 타입들을 import 해서 사용하도록 할 수 있음.

스프링 Application Context

스프링의 기본적인 모듈화 단위는 application context.
이 안에 스프링이 관리할  빈들을 담고 있다.
상속 구조를 가질 수 있다. 하위 context에서 상위 context에 있는 빈들을 참조할 수 있지만, 그 반대는 안 된다.
(Spring MVC를 잘 보면 이 구조가 있죠.)
스프링의 exporter나 factory bean들은 외부 클라이언트쪽 application context에서 해당 bean에 대한 레퍼런스를 사용할 수 있도록 제공해준다.
(Spring의 Expoter들은 JMS나 RPC 쪽을 보면 잘 나와 있습니다. 아주 일관된 패턴으로 Exporter들을 제공해 줍니다.)

OSGi 번들과  스프링 Application Context

잘 어울린다.
스프링 DM을 사용해서, 번들은 번들 내부에 있는 객체들(bean)을 생성하고, 설정하고, 묶고, 꾸며줄 applicaion context를 가질 수 있다.
그런 Bean들 중에 일부를 선택적으로 OSGi 서비스로 노출시켜서 외부의 다른 번들에서 사용할 수 있도록 할 수 있고, 그런 빈들은 깔끔하게Transparently 다른 OSGi 서비스에 주입 될 수 있다.

'Spring DM > Chapter 4' 카테고리의 다른 글

4.7. Stopping the extender bundle  (0) 2008.04.13
4.6. Application Context Destruction  (0) 2008.04.13
4.4. The Resource abstraction  (0) 2008.04.12
4.5. Accessing the BundleContext  (0) 2008.04.12
4.3. Bundle Lifecycle  (2) 2008.04.11
4.2. Application Context Creation  (0) 2008.04.11
4.1. The Spring Dynamic Modules Extender bundle  (0) 2008.04.10
Bundles and Application Contexts  (0) 2008.04.09
top