Whiteship's Note


Required-Bundle을 비추하는 이유

Spring DM/exercise : 2008.07.10 23:04


먼저 Required-Bundle이 뭔지 알아야겠다. Import-Package를 이해했으면 이건 뭐 아주 간단하다.

1. Resolved 상태가 되기 위한 조건

Import-Package 헤더에 명시한 패키지들이 어떤 번들들에 의해서 Export-Package 헤더이 설정 되어 있으면 해당 번들은  RESOLVED가 될 것이다.(물론 필수 였다는 가정하에.)

Required-Bunlde은 번들 단위로 바꿔서 생각하면 된다. 이 번들의 Required-Bundle에 설정한 번들이 RESOLVED 상태가 되어야 이 번들도 RESOLVED 상태가 될 수 있다.

2. Import 하는 패키지의 정적이냐 동적이냐

Import-Package로 패키지를 참조하면, 해당 패키지들만 참조할 수 있다. Required-Bundle로 참조하면 거기에 설정한 번들이 Export-Package에 명시한 모든 패키지들을 Import 한다. 따라서, Required-Bundle에 설정한 번들이 공개하는 패키지의 설정이 바뀌면 이 번들이 가져오겠다고 선언하는 패키지들도 달라지는 것이다.

자 그럼 이제 이 설정을 비추하는 이유를 살펴보자.

1. 위에서도 언급했듯이 Import 대상이 되는 패키지가 변한다. 그게 문제가 될 수 있다. 만약 이 번들이 꼭 필요로 하는 패키지를 저 번들이 가지고 있었는데, 저 번들이 갑자기 그 패키지를 Export-Package 목록에서 빼버렸다. 그래도 저 번들은 RESOLVED가 되었고, 그랬기 때문에 이 번들도 따라서 RESOLVED가 되었다. 하지만 이 번들이 동작하다가 ClassNotFoundException이나 NoClassDefinitionError를 발생시킬 여지가 다분하다.

2. 만약 Required-Bundle에 설정한 번들의 기능이 너무 많아져서 분리해야 된다고 생각해보자. 그럼 Requied-Bundle에 이 번들을 설정했던 모든 (소비자 격인) 번들들의 설정을 전부 고쳐줘야 한다. 얼마나 힘들고 고된 작업인가... 그냥 Import-Package를 썼었다면, 기능이 많아져서 분리를 해도 그냥 Export-Package도 같이 분리해서 가지고 가기만 하면 된다. 소비자 입장에선 아무것도 바꾸지 않아도 된다.

3. 낭비다. 필요 없이 Import 하는 패키지가 생길 것이다.

Required-Bundle 은 OSGi R4에 추가된 기능인데 Eclipse의 영향이 컸다고 한다.

top

Write a comment.


bnd 사용해서 API 가져오기(Import)

Spring DM/exercise : 2008.07.10 22:48


번들이 사용할 모든 라이브러리는 MANIFEST.MF 파일의 Import-Package에 기술 되어야 한다.

위의 문장은 맞는 문장일까 틀린 문장일까? 틀렸다. 예외가 있다. 바로 java.* 이하의 패키지들은 기술하지 않아도 된다. 별도의 import 없이도 사용할 수 있기 때문에 Import-Package에 굳이 명시할 필요가 없다. 하지만.. javax.*은 Import-Package에 명시해줘야 한다. javax.swing 이나 javax.awt  같은 것 들.. 또는 org.xml.sax와 같은 것들도 물론 명시적으로 선언해 줘야겠다.

그럼 bnd 설정 파일에는 어떻게 설정할까? bnd에도 Import-Package라는 헤더가 있고 필요한 모든 패키지를 import 하도록 * 로 설정해주면 된다.

Import-Package: *

이렇게.. 하지만 이미 이렇게 기본값(CoC)으로 설정되어 있어서 위의 설정을 아예 적지 않아도 알아서 저런 설정이 있는 것으로 인식해서 MANIFEST.MF 파일의 Import-Package를 만들어 준다. 좋다 좋아..

그래도 Import-Package: 헤더를 bnd  설정에서 사용해야 하는 경우가 있는데 바로. 버전을 명시할 때다. 개발 중이 아니라면 버전은 왠만해선 명시해 주는게 베스트 프랙티스라고 생각된다. 버전은 항상 범위로 설정된다. 보통 다음과 같다.

또 하나 필수 여부를 설정할 때도 Import-Package를 사용해야 한다. 기본은 필수 인데, 필수가 아니게 설정하고 싶을 때는 명시적 설정 해줘야 한다.

Import-Package: org.apache.log4j*;version="[1.2.0,1.3.0]",\
                         javax.swing*;resolution:=optional,\
                         *

위의 설정은 log4j 패키지 버전 1.2.0 이상 1.3.0 이하에 있는 클래스나 리소스를 참조하도록 설정했고, swing 패키지는 굳이 없어도 이 번들이 RESOLVE 상태가 되는데 지장이 없도록 설정했다. 마지막으로 그 외 필요한 모든 패키지들은 필수고 버전은 [0.0.0, *] 이렇게 설정되어서 어떤 버전이든 상관 없이 있기만 하면 된다.

마지막으로 Import-Package에 패키지 명을 명시적으로 선언하는 경우가 있는데, 특정 패키지를 아예 빼버리거나 무조건 추가한다. 왜일까? 특정 패키지를 빼는 경우는 번들의 코드 중에 일부는 절대로 실행이 되지 않을 꺼라는 전제가 있다면 그 부분에서 사용한 패키지를 굳이 Import 할 필요는 없을 것이다. 그리고 왜 bnd가 알아서 필요한 패키지를 찾아서 (MANIFEST.MF 에 있는) Import-Package 헤더에 추가해 줄텐데 명시적으로 등록을 하는 경우가 생길까? 그건 동적으로 로딩할 클래스 때문이다. 그런 클래스들을 담고 있는 패키지는 햇갈리게 * 를 사용하지 말고 명시적으로 전체 패키지 명을 적어주자.


top

Write a comment.


Java의 Classpath 한계와 OSGi

Spring DM/etc : 2008.07.10 22:28


자바에서 기본으로 제공하는 "모듈 시스템"이라고 할 수 있는 건 JAR 파일들을 모아둔 클래스패스 덩어리다. 이게 구린 이유는 의존성 관리를 하지 않기 때문이다. 그냥 암묵적으로 어떤 환경에서 실행되리라고 가정해버린다. 클래스패스에 필요한 것들이 있는지를 알 수도 없고 어떤게 필요한지도 알 수 없다. 따라서, 필요한 JAR 파일을 클래스패스에 추가하지 않고 애플리케이션을 실행하면 Runtime 시에 ClassNotFoundException이나 NoClassDefinitionFound 와 같은 에러를 종종 만나게 되고, 어떤 JAR가 빠졌는지 찾으면서 허송세월을 보낸다.

OSGi는 그럼 뭐가 다를까? OSGi는 명시적이며(Explicit), 선언적이고(Declarative) 버전을 적용해서(Versioned) 의존성들을 관리한다.

Explicite
- 번들이 필요로 하는 패키지 또는 서비스와 번들이 공개할 패키지나 서비스를 명시적으로 설정한다.

Declaritve
- 의존성을 기술하는 방법이 매우 간단한 텍스트 형식이다. 따라서 도구를 사용해서 쉽게 의존성을 기술하는 파일을 만들어 낼 수도 있다.

Versioned
- 라이브러리는 계속 변하기 마련이다. 따라서 같은 라이브러리라 하더라도 분명 차이가 있을 것이다. 따라서 OSGi는 모든 번들 의존성 사이에 버전 범위를 기술하도록 했다. 그래서 같은 라이브러리라 하더라도 여러 개의 버전이 동시에 사용될 수 있다.

참조 : http://neilbartlett.name/blog/osgibook/
top

Write a comment.


bnd 사용해서 API 공개(Export) 하기

Spring DM/exercise : 2008.07.10 22:17


Export-Package 헤더를 사용하면 된다. 예를 들어 다음과 같이..

Export-Package: whiteship.service.*;version=1.0.0

뒤에 버전은 해당 패키지를 1.0.0 버전으로 공개하겠다는 설정이다. 버전에 대해서는 조금 있다가 정리하자. bnd가 저 설정을 읽으면 다음 작업을 하게 된다.

1. 해당 JAR(번들) 안에 명시한 패키지가 들어있는지 검사한다.
2. MANIFEST.MF 파일에 대상이 되는 패키지를 Export-Package 헤더에 추가한다.

*와 !를 적절히 사용해서 다음과 같이 작성할 수 도 있다.

Export-Package: !com.*, *

com. 이하 모든 패키지는 제외하고 그 나머지 패키지들만 공개하겠다는 설정이다. 이 얼마나 간단한가.. 귿!
top

Write a comment.


유용한 OSGi 팁

Spring DM/Appendix E : 2008.07.10 10:58


E.1. OSGi Fragments

OSGi R4에 포함된, fragment는 매우 유용하면서도 강력한 기능이다. fragment는 "호스트 번들에 붙일 수 있는 번들"로써, 대상 번들에 컨텐츠를 추가할 수 있다. fragment는 자신의 클래스로더나 bundle activator를 사용할 수 없으며 호스트에 존재하는 정보를 재정의할 수 없다. 간략하게 fragment 번들을 사용해서 번들을 확장 할 수 있다. 따라서 resource, 클래스, 또는 manifest 요소들까지도 확장 가능한 형태가 된다. 스펙을 다시 인용하면 다음과 같다. "fragment의 주요 사용처는 로케일에 따른 번역 파일 제공이다. 이 것을 사용하여 주요 애플리케이션 번들에서 독립적으로 번역된 파일을 사용할 수 게 해준다."

Spring DM에서 이 기능은 extender와 같은 컴포넌트들을 설정할 때 매우 유용하다. 간단하게 추가할 리소스를 번들로 묶고 Manifest에 한 줄을 추가하면 된다.

Fragment-Host: <host bundle symbolic name>

위 설정을 가지고 있는 번들은 fragment이고 저기에 기술한 symbolic name을 가진 호스트 번들에 구성물들이 첨가가 된다. fragment와 host 번들 symbolic name은 달라야 한다. 예를 들어, Spring DM extender에 fragment를 추가하려면, 다음과 같은 manifest를 작성하면 된다.

Manifest-Version: 1.0                                                                    (1)
Bundle-ManifestVersion: 2                                                                (2)
Fragment-Host: org.springframework.bundle.osgi.extender                                  (3)
Bundle-SymbolicName: org.mydomain.project.fragment                                       (4)
Bundle-Name: my-fragment                                                                 (5)
Bundle-Description: Fragment attached to Spring-DM extender                              (6)

1    Manifest 버전
2    OSGi 번들 버전. 기본값인 1이면 OSGi R3 번들이고 2면 OSGi R4 번들이라 뜻.
3    이 번들을 부착할 번들의 symbolic name. 여기서는 spring-osgi-extender.jar를 가리키는 org.springframework.bundle.osgi.extender로 설정 함. Fragment-Host를 사용하여 OSGi 플랫폼에 자신이 fragment라는 특별한 번들임을 알려줌.
4    fragment symbolic name.
5    bundle name - 부가적이지만 유용한 헤더(가독성 측면에서)
6    bundle 설명 - OSGi 플랫폼이 사용하기 위한 것이 아니라, bundle name 처럼, 사람이 읽기 편한 헤더. 번들의 목적을 확인하기 위한 용도로 사용.

같은 symbolic name을 가진 호스트 번들이 여러 개일 때는 버젼을 명시해서 하나를 선택할 수 있다.

Fragment-Host: org.springframework.bundle.osgi.extender;bundle-version=1.1.0

버전의 기본값은 [0.0.0,∞) 다.


'Spring DM > Appendix E' 카테고리의 다른 글

유용한 OSGi 팁  (0) 2008.07.10
top

Write a comment.


20080710 GMP

모하니?/GMPing : 2008.07.10 08:56


News

city employees 씨리 임플로이스
could be 쿧비
In an afford to ~하기 위해서, ~하기 위한 일환으로
cut down on 줄이다
commute 통학하다

In an afford to cut down on commuting costs, 4,000 city employees in Birmingham Alabama began working a four week. It's an idea that could be coming to office neer you.

Screen English

Hi. Excuse me. Could you help?
Hm.. hm. yes.
I'm looking for a book obviously. 
Anything in particular?(특별히 찾으시는 거라도 있나요?)
Someting that can help me deal with what might be awkward situation.
Oh. OK.

Pop's English(She is so high)

Cuz she is so high, high above me. She is so lovely.
She is so high. CleoPatra, Joan of Arc, or Aphrodite.

Talk Play Learn

Aren't you going to ~?(~하지 않을꺼야?)

Aren't you going to join us?
Aren't you going to come in?
Aren't you going to say hello?
Aren't you going to say sorry?
Aren't you going to talk to me?
Aren't you going to look at me?
Aren't you going to say goodbye?
Aren't you going to wash your hands?

Sound Sound Play

p가 중간에 들어갈 땐 묵음

camps 캠스
empty 엠티
symptom 심텀

More Expression

찜찜한 기분 = mixed feelings

'모하니? > GMPing' 카테고리의 다른 글

20080721 GMP  (0) 2008.07.21
20080718 GMP  (0) 2008.07.18
20080717 GMP  (0) 2008.07.17
20080716 GMP  (0) 2008.07.16
20080715 GMP  (0) 2008.07.15
20080710 GMP  (0) 2008.07.10
20080708 GMP  (0) 2008.07.08
20080707 GMP  (0) 2008.07.07
20080705 GMP  (0) 2008.07.05
20080704 GMP  (0) 2008.07.04
20080703 GMP  (0) 2008.07.03
top

TAG GMP

Write a comment.