Whiteship's Note


Spring DM 1.1.0 RC1 배포됐네요.

Spring DM/etc : 2008.06.25 23:29


http://www.springframework.org/osgi
with-dependencies가 겨우 13MB 밖에 안 합니다.


top


BundleContext로 할 수 있는 일

Spring DM/OSGi : 2008.06.25 23:12


BundleActivator 다음으로 가장 중요한 OSGi API를 꼽으라면, BundleContext일 겁니다. 어쩌면 BundleActivator보다 중요할지도 모르죠. OSGi 플랫폼에 설치한 번들과 관련된 문맥 정보를 담고 있는 객체니까요. 어떤 용도로 쓸 수 있는지 알아두면 좋겠죠?

시스템 전역에서 사용할 설정 프로퍼티즈 룩업

ID로 설치된 다른 번들 찾기

설치된 모든 번들 목록 가져오기

번들을 프로그래밍을 통해서 라이프사이클 다루기

새로운 번들을 프로그래밍을 통해서 설치하기

프레임워크가 관리하는 영속 저장소에서 파일 가져오거나 저장하기

프레임워크 내부에 있는 어떤 번들의 상태 변화를 알려주기 위한 번들 리스너 등록 또는 해지하기

프레임워크 내부에 있는 어떤 서비스의 상태 변화를 알려주기 위한 서비스 리스너 등록 또는 해지하기

일반적인 프레임워크 이벤트를 알려주기 위한 프레임워크 리스너 등록 또는 해지하기

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

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

OSGi 툴 세트 Pax  (0) 2008.10.21
Shared Mutable State  (2) 2008.09.25
The Price of Freedom  (0) 2008.09.25
Concurrency and OSGi  (0) 2008.09.25
BundleContext로 할 수 있는 일  (0) 2008.06.25
2 Security Layer  (0) 2008.02.18
1. Introduction  (0) 2008.02.17
top


번들 라이프사이클

Spring DM/exercise : 2008.06.25 22:56


전에 한 번 그림도 그려보고 아드리안의 발표자료에서도 봤지만, 이번엔 Neil이 그린 라이프사이클입니다.

사용자 삽입 이미지

install 커맨드를 사용해서 번들을 설치하면 맨 먼저 INSTALLED 상태가 되고,
start 커맨드를 사용하면 번들이 필요로 하는 패키지나 서비스를 참조할 수 있는지 확인한 다음 RESOLVED 상태가 되고, 자동으로 자신이 공개할 서비스를 서비스 레지스트리에 등록하고 ACTIVE  상태가 됩니다.

이 상태에서 update 명령을 실행하면 일단 RESOLVED 상태로 넘어가야 하기 떄문에 STOPPING 과정을 거치는데 이 과정에서 자신이 등록했던 서비스를 서비스 레지스트리에서 제거하고 RESOLVED 상태에서 INSTALLED 상태로 변하고 여기서 실제 번들 파일을 update 합니다. 이 때 이미 번들이 위치한 정보를 알고 있기 때문에 위치를 다시 알려줄 필요는 없겠죠. 그런 다음 원래 상태가 ACTIVE 상태였기 떄문에 다시  start를 합니다. 그럼 처음과 같이 RESOLVED -> STARTING 을 걸쳐 ACTIVE 상태가 됩니다.

이 상태에서 이번에는 stop 커맨드를 사용하면 번들은 RESOLVED 상태가 됩니다. 왜? 이미 해당 번들이 필요한 서비스나 패키지들이 가용하다는 것을 검증한 상태기 때문이죠.

해당 번들을 아예 안 쓸꺼면 그 땐 uninstall 해버리면 됩니다. 현재 상태가 어떤 상태이든 관계없이 저 고리를 따라서 이동한 뒤 설치된 번들 목록에서 사라질 겁니다. 다음에 그 번들을 다시 설치하고 싶으면 위치를 또 알려줘야 합니다. 그게 update와 uninstall/install의 가장 큰 외관상 차이며, 개념적인 차이기도 합니다.

Anyway 무사히 모든 번들들이 RESOLVED 되기를 빕니다.

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

top