Whiteship's Note

'Spring DM'에 해당되는 글 33건

  1. 2009.07.11 스프링 슬라이스(Spring Slice)
  2. 2008.11.27 오호.. 스프링소스 manifest 헤더가 OSGi에 추가되는군요
  3. 2008.11.25 스프링 DM 1.2.0 m2 배포
  4. 2008.08.01 Spring DM 샘플 웹 번들(WAR) 설치하기
  5. 2008.07.31 이클립스 타겟 플랫폼에 Spring DM 번들 돌리기
  6. 2008.07.31 맥북에서도 Spring DM 웹 번들 설치 성공
  7. 2008.07.29 Spring DM 1.1.1 배포
  8. 2008.07.10 유용한 OSGi 팁
  9. 2008.07.09 Spring Dynamic Modules Maven Archetype
  10. 2008.07.09 Spring DM, Eclipse 플러그인 개발 환경에 통합하기
  11. 2008.05.24 5.6. Considerations when using external libraries
  12. 2008.05.24 5.5. Importing and Exporting packages
  13. 2008.05.14 5.3. Required Spring Framework and Spring Dynamic Modules Bundles
  14. 2008.05.14 5.2. Extender configuration options
  15. 2008.05.13 Maven으로 Spring DM Project 만들기(Eclipse에서 import 가능)
  16. 2008.05.08 5.1. Bundle format and Manifest headers
  17. 2008.04.30 귿!! OSGi위에 웹 애플리케이션 돌리기 성공 with Spring DM (2)
  18. 2008.04.30 웹 애플리케이션과 OSGi
  19. 2008.04.13 4.7. Stopping the extender bundle
  20. 2008.04.13 4.6. Application Context Destruction
  21. 2008.04.12 4.4. The Resource abstraction
  22. 2008.04.12 4.5. Accessing the BundleContext
  23. 2008.04.11 4.3. Bundle Lifecycle (2)
  24. 2008.04.11 4.2. Application Context Creation
  25. 2008.04.10 4.1. The Spring Dynamic Modules Extender bundle
  26. 2008.04.09 Bundles and Application Contexts
  27. 2008.04.09 Spring DM 소스코드 보기: fisheye
  28. 2008.04.09 What is new?
  29. 2008.04.09 Requirements
  30. 2008.04.09 Why Spring Dynamic Modules?

스프링 슬라이스(Spring Slice)

Spring DM/etc : 2009.07.11 11:36


참조
http://blog.springsource.com/2009/07/10/pluggable-styling-with-springsource-slices/
http://blog.springsource.com/2009/06/22/modular-web-applications-with-springsource-slices/

음.. 웹 애플리케이션을 OSGi 번들로 구성할 때, web 번들 하나랑 기타 서비스 번들 여러 개로 쪼개야 하는구나.. 라고 만 생각하고 있었는데, 그렇지 않았네요.

스프링 슬라이스를 이용해서 하나의 웹 애플리케이션에서 여러 개의 웹 번들을 구성할 수 있도록 해주는 프레임워크라고 보면 될 것 같습니다. 웹 번들이 여러 개라고 해서 ServletContext가 여러 개 생기는 건 아니고, parent/child 구조로 여러 슬라이스가 호스트의 ServletContext를 이용해서 쓰게 해주는가 봅니다. 설정은 호스트 쪽 web.xml 에 스프링 슬라이스 필터를 추가하면 되고, 슬라이스 쪽에서는 Manifest.mf에 Slice-Host와 Slice-ContextPath를 설정하면 되는 정도로 간단한 편인듯 하네요.

요즘은 이것 저것 볼 여력이 없기 때문에.. 이정도만 살펴보고 패스~
신고
top


오호.. 스프링소스 manifest 헤더가 OSGi에 추가되는군요

Spring DM/etc : 2008.11.27 21:57


참조: http://blog.springsource.com/2008/11/27/springsource-manifest-headers-registered-with-osgi/

OSGi 진영에서 public registry에 밴더별 헤더를 등록해서 중복하는 헤더를 방지하고자 하는 것 같습니다.

추가된 스프링소스의 헤더 7개
- Import-Bundle
- Import-Library
- Module-Scope
- Modeul-Type
- Web-Contextpath
- Web-DispatcherServletUrlPatterns
- Web-FilterMappings

추가된 bnd 헤더 2개
- Include-Resource
- Private-Package

오호~~ 귿~~ 다시 한 번 스프링 DM 공부를 하고 가야겠습니다. S1A에 가서 스프링 DM과 DM 서버 관련 세션을 집중적으로 듣고 올 계획입니다. 이틀 남았네 빡쎄게 공부해야겠군..
신고
top


스프링 DM 1.2.0 m2 배포

Spring DM/etc : 2008.11.25 00:52


참조 : http://www.springsource.org/node/837

눈에 띄는 변경 사항은
- 일단 얼마전에 배포된 스프링 2.5.6을 사용하도록 변경 했다는 겁니다.
- compendium 네임스페이스를 추가했다는데..;; 뭔지 모르겠습니다. 알아봐야겠네요.
- shutdown 알고리즘을 개선했다는 군요.

나머진 잘 눈에 안 들어오고 모르겠네요~

ps: 이사 할 땐 손톱을 약간 길게 깍으세요. 평소처럼 깍았는데 이사하면서 손 끝이 부어서 그런가 굉장히 따갑습니다. ㅠ,ㅠ
신고
top


Spring DM 샘플 웹 번들(WAR) 설치하기




헐.. 이 날 맥주 마시고, 알딸딸 한 상태에서 녹화했더니, 목소리랑 말투가 장난 아니네요. ㅋㅋㅋ 음주 스크린캐스팅이 궁금하신 분들은 재미삼아 봐보세요.ㅋㅋ
신고
top

TAG Spring DM

이클립스 타겟 플랫폼에 Spring DM 번들 돌리기



어때요. 참 쉽죠?
신고
top


맥북에서도 Spring DM 웹 번들 설치 성공

Spring DM/exercise : 2008.07.31 00:03


인증샷 1. 번들 목록

사용자 삽입 이미지

인증샷 2. simple-web-app 첫 화면

사용자 삽입 이미지
인증샷 3. 서블릿

사용자 삽입 이미지
인증샷 4. JSP는.. 또 실패;;

사용자 삽입 이미지
흠... 리소스가 제대로 등록이 안 되있는건지.. 원인을 좀 찾아봐야겠습니다.


맥북에서 Spring DM 웹 번들 돌린게 왜 기쁘냐면요;; 안 해보신 분들은 몰라요... 윈도에서 돌리는 Equinox(줄여서 윈E)랑 맥에서 돌리는 Equinox(맥E)가 좀 차이가 나는 것 같습니다. 버그 같은데, 그게 맥E 의 버그인지, Spring DM web extender의 버그 인지, catalina의 버그인지 도통..잘 모르겠습니다.

spring web extender가 catalina 번들이 제공하는 서비스를 필요로 하는데, 만약에 catalina 보다 먼저, start 시키면 당연히.. resolved 상태로 못가고 해당 서비스가 들어올 때까지 좀 기다립니다. 그러다가 특정 시간이 되면 타임되서 넘어갑니다. 이게 정상이죠. 윈E에선 이렇게 정상적으로 동작합니다. 그래서 설치할 번들 목록에서 spring web extender 가 catalina 보다 위에 있어도(즉 먼저 start를 시도하겠죠.) 상관없습니다. 기다리다 보면, 다른 번들들 모두 Active 상태가 되고, spring web extender만 Resolved 상태로 남아있습니다.(catalina도 Active 상태가 됐으니 web extender가 필요로 하는 서비스가 제공 되서 상태가 변한겁니다.) 그러면... 이제 web extender만 다시 start 명령어로 Active 상태로 만들어 주면 됩니다.

하지만.... 맥E에선, 한 번 해보세요~ 해보셨어요? 안 해보셨으면 말을 하지마세요.

사용자 삽입 이미지
사용자 삽입 이미지


참.. 테스트 환경은. Eclipse 3.4. Spring DM 1.1.1 입니다.

ps: Bad case에 걸렸을 때 Good case를 찾아 빠져 나가는 방법이 있긴 있는데.. 그건 비밀입니다. 캬캬캬
신고
top


Spring DM 1.1.1 배포

Spring DM/etc : 2008.07.29 23:44


http://www.springframework.org/node/718

버그들을 좀 수정했나봅니다. 눈에 확 들어오는 뭔가는 없어서 코멘트 할 께 없네요;;
신고
top


유용한 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


Spring Dynamic Modules Maven Archetype

Spring DM/Appendix D : 2008.07.09 11:16


스프링 DM은 메이븐 아키타입archetype을 제공하여 스프링 DM 번들 개발 시에 사용할 수 있는 자바 프로젝트 기본 틀을 제공한다. 아키타입을 실행하려면 다음의 명령어를 사용하면 된다.

mvn archetype:generate

메이븐 플러그인이 가용한 archetype을 보여줄 것이다. 그 중에서 spring-osgi-bundle-archetype을 선택하면 된다.(현재 32번으로 설정되어 있다.) 그리고 프로젝트에 필요한 몇 가지 정보를 입력한다.(그룹id, 아티팩트id, 버전, 패키지) 가용한 모든 아키타입과 버전은 여기를 참조하라.

물론 archetype:create를 사용해서 직접 아키타입을 설정하여 프로젝트를 생성할 수도 있다.

mvn archetype:create \
-DarchetypeGroupId=org.springframework.osgi \
-DarchetypeArtifactId=spring-osgi-bundle-archetype \
-DarchetypeVersion=   \
-DgroupId=<your-project-groupId>  \
-DartifactId=<your-project-artifactId> \
-Dversion=<your-project-version>

(과연 누가 저렇게 쓸까;;; 오타 없아 커맨드 창에 저걸 전부 입력 할 수 있는 사람~?)

둘 모두 같은 프로젝트 구조를 생성해준다. 그 안에 두 개의 스프링 설정 파일 src/main/resources/META-INF/spring/bundle-context.xml 와 src/main/resources/META-INF/spring/bundle-context-osgi.xml 가 있다. 프로젝트는 OSGi 번들로 패키지 형태가 설정되어 있다.

프로젝트에 MANIFEST.MF 파일이 없는데, 이 건 메이븐의 bnd 플러그인으로 자동 생성한다. 따라서 번들을 생성하고 싶으면 다음과 같이 하면 된다.

mvn package

번들 말고, MANIFEST.MF 파일만 생성하고 싶을 때는 다음과 같이 한다.

mvn org.apache.felix:maven-bundle-plugin:manifest

D.1. 생성한 프로젝트 살펴보기
  • OSGi 번들로 패키징 함.
  • MATA-INF/MANIFEST.MF 는 자동 생성함.
  • src/main/java/<package> 번들이 공개할 패키지
  • src/main/java/<package>/internal 번들이 공개하지 않을 패키지
  • src/main/resources/META-INF/spring/bundle-context.xml 번들 내부에서 사용할 스프링 설정 파일
  • src/main/resources/META-INF/spring/bundle-context-osgi.xml OSGI 관련 스프링 설정 파일
  • .project, .classpath, 그리고 build.properties 파일은 이 프로젝트를 이클립스 PDE 플러긴 프로젝트로 인식하게 해 줌.



신고

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

Spring Dynamic Modules Maven Archetype  (0) 2008.07.09
top


Spring DM, Eclipse 플러그인 개발 환경에 통합하기

Spring DM/Appendix C : 2008.07.09 10:32


참조: http://static.springframework.org/osgi/docs/current/reference/html/appendix-pde-integration.html

레퍼런스대로 하면, 잘 안 될 겁니다. Spring DM 최신 버전도 못 쓰고 말이죠. Spring DM 때문에 Spring IDE를 설치해야 하는 것도 아닌데, Spring DM 레퍼런스 이 부분은 별로 네요. 그래서 제 맘대로 다시 작성합니다.

Eclipse의 Target Platform에 Spring DM 관련 번들들을 설정 해 놓고 손 쉽게 Equinox위에서 해당 번들들을 돌릴 환경을 마련하는 과정입니다. 간단합니다.

먼저 Spring DM 프로젝트를 다운로드 합니다.

http://www.springframework.org/osgi

압축을 풀고, lib과 dist에 있는 모든 번들들(*source*가 들어간건 제외합니다. 소스는 필요 없습니다.)을 복사해서 특정 폴더 하나로 이동시켜둡니다.

사용자 삽입 이미지

그리고 Eclipse의 Target Platform 설정으로 들어가서 해당 폴더를 Location으로 잡아주고, Reload 버튼을 클릭합니다. 환경 설정은 끝났습니다.

사용자 삽입 이미지

이제 Equinox를 실행해보죠.

사용자 삽입 이미지

흠.. 뭐 별게 없스니다. 왼쪽에 있는 서브 메뉴에서 OSGi Framework을 더블클릭해서 새로운 Run Configuration 인스턴스를 만들고 이름을 Spring DM이라고 지어줬습니다. 번들들은 알아서 Target Platform에 설정해 둔것들을 로딩해 왔을 겁니다. Apply를 클릭하고 Run을 클릭합니다.

번들들의 상태와 Equinox 명령어를 확인해보죠.

사용자 삽입 이미지

test랑 jetty fragment는 resolved 상태로 되어 있네요. test 번들은 저렇게 설치할 용도로 만들어진게 아니니까 폴더에서 빼줘야 될 것 같네요. jetty fragment는 나중에 Jetty를 서브릿 컨테이너로 사용할 때 제티 설정을 변경할 수 있는 번들이니까 뭐.. 일단 내비둬도 상관없겠네요.

중요한 건, Extender가 제대로 동작 중이냐 입니다. 번들 ID 3번으로 잘 동작하고 있군요. Spring DM에서 가장 중요한 번들이 Extender입니다. 좀 더 자세히 봐볼까요?

사용자 삽입 이미지

흠.. 확실히 콘솔 명령어는 Felix보다 Equinox가 좀 더 많고 편합니다.
신고

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

Spring DM, Eclipse 플러그인 개발 환경에 통합하기  (0) 2008.07.09
top


5.6. Considerations when using external libraries

Spring DM/Chapter 5 : 2008.05.24 23:08


대부분의 엔터프라이즈 애플리케이션 라이브러리들은 context class loader를 통해서 타입과 리소스를 로딩할 수 있다고 가정한다. 보통 개발자가 이 것을 직접 다루지는 않지만, 애플리케이션 서버, 컨테이너 또는 멀티 쓰레드로 동작하는 애플리케이션들은 context class loader를 사용하고 있다.

OSGi R4에서는 context class loader를 통해 가용한 타입이나 리소스 집합에 대해 정의되어 있지 않다. 이것은 OSGi 플랫폼이 쓰레드 context class loader 값을 보장하지 못한다는 것이고 다시 말하자면, ccl을 관리하지 않는다는 것이다.

따라서 클래스 로딩을 하거나 동적으로 새로운 클래스를 생성하는 코드가 OSGi 환경에서는 제대로 동작하지 않을 수 있다.

스프링 DM은 해당 번들의 application context를 생성하는 도중에 번들의 클래스패스에서 가용한 모든 타입과 리소스들을 ccl을 통해 접근할 수 있도록 보장한다. 또한 스프링 DM은 외부 서비스를 호출할 때와 공개한 서비스에 대한 요청에 서비스를 할 때 CCL을 통해서 접근 가능한 클래스와 리소스를 설정할 수 있다. 방법은 5.5에서 설명했다.

OSGi R5에서는 제 3의 라이브러리에 의해 추가된 암묵적인 클래스 패스와 생성된 클래스를 지원하기 위한 스펙을 정하고 있다. 그전까지는 DynamicImport-Package manifest 헤더를 사용하거나,  Equinox의 버디buddy 매커니즘을 사용할 수 있을 것이다.
신고
top


5.5. Importing and Exporting packages

Spring DM/Chapter 5 : 2008.05.24 00:19


Import-Package와 Export-Package manifest 헤더에 대한 자세한 내용은 OSGi 스펙을 참조하도록.

번들은 자신이 의존성을 가지는 모든 외부 패키지들을 Import-Package를 사용해서 설정한다.

만약 다른 번들들이 사용할 필요가 있는 타입을 제공해야 한다면, Export-Package를 사용하여 외부 번들에서 사용할 수 있는 모든 패키지를 설정한다.
신고
top


5.3. Required Spring Framework and Spring Dynamic Modules Bundles

Spring DM/Chapter 5 : 2008.05.14 23:42


스프링 Extender가 제대로 동작하려면 OSGi 플랫폼에 배포해야 할 몇몇 번들 아티팩트들이 있다.
- org.springframework.osgi.extender : extender 번들 자신
- org.springframework.osgi.core : 스프링 DM을 지원하는 핵심 구현체 변들
- org.springframework.osgi.io : 스프링 DM I/O 지원 라이브러리 번들

여기에 추가로 스프링 라이브러리가 필요한데, 스프링 2.5부터는 OSGi 플랫폼에 바로 배포가 가능한 형태로 배포하고 있다. 그 중에 다음을 필요로 한다.
- spring-core.jar
- spring-context.jar
- spring-beans.jar
- spring-aop.jar

추가로 다음의 라이브러리 번들을 필요로 한다. OSGi 플랫폼에 배포 가능한 형태의 JAR 파일들을 Spring DM With Dependencies 형태로 배포한 파일에 들어있다.
- aopalliance
- backport-util(JDK 1.4에 돌릴 때만 필요)
- cglib-nodep
- commons-logging API(SLF4J 강추)
- logging 구현체
신고
top


5.2. Extender configuration options

Spring DM/Chapter 5 : 2008.05.14 23:29


번들과 관련된 설정이외에, 스프링 DM은 extender의 기본 행위를 설정할 수도 있다. 이것은 Spring-DM을 관리하는 환경Managed Environment에 포함시키거나 여러 번들에 걸친 기능이 필요할 때 유용하다. 확장 가능한 설정을 위해, extender는 OSGi의 fragment를 사용하여 기본 값을 재정의 할 수 있다. extender는 META-INF/spring 밑에 있는 모든 XML 파일을 읽어들이며 application context(OsgiBundleXmlApplicationContext)를 생성한다. extender의 기본 설정을 재정의하려면, 아래 테이블을 보고 원하는 빈을 읽어와서 정의를 하고 spring-osgi-extender.jar의 Fragment로 붙이면 된다.

Fragment-Host: org.springframework.bundle.osgi.extender

표생략

5.2.1. Listening to Extender events

번들의 application context 시작이나 실패시 로그를 남기고 싶을 수 있다. 이런 경우, 스프링 DM이 제공하는
org.springframework.osgi.context.event 패키지를 정의하여 OSGi application context가 보낼 수 있는 이벤틀를
정의할 수 있다.

현재 지원하는 이벤트는 딱 두개
- OsgiBundleContextRefreshedEvent
- OsgiBundleContextFailedEvent

이 이벤트들을 받길 원하는 쪽에서는 OsgiBundleApplicationContextListener를 구현해야 한다. 그리고 해당 서비스를
OSGi 서비스로 공개하야 한다. 그럼 스프링 DM이 알아서 리스너들을 찾아서 이벤트를 그쪽으로 보내줄 것이다.

이런식의 이벤트 처리는 OSGi의 장점을 모두 누릴 수 있다. 즉 extender가 이벤트 배포자나 이벤트 리스너로 부터
완전히 분리되어 있으며, 등록/해지 과정도 간단하다.

스프링 DM 이벤트와 스프링 이벤트와는 조금 차이가 있는데, 스프링 이벤트는 이벤트가 발생한 applicaion context
내부의 빈으로 이벤트를 보내지만, OSGi 이벤트는 자신을 지켜보고 있는 다른 application context의 빈으로 보내진다.

신고
top


Maven으로 Spring DM Project 만들기(Eclipse에서 import 가능)

Build/Maven : 2008.05.13 18:03


참조
http://www.springframework.org/node/361
http://www.springframework.org/node/360
http://opensource.atlassian.com/confluence/spring/display/DOC/HowTo+build+Spring-Osgi+using+Maven+2
http://static.springframework.org/osgi/docs/1.1.0-m2/reference/html/appendix-archetype.html

기본 명령어는 다음과 같습니다.

mvn archetype:create \
-DarchetypeGroupId=org.springframework.osgi \
-DarchetypeArtifactId=spring-osgi-bundle-archetype \
-DarchetypeVersion=${version}   \
-DgroupId=<your-project-groupId>  \
-DartifactId=<your-project-artifactId> \
-Dversion=<your-project-version>

${version} 에는 배포된 스프링 DM 프로젝트 버전을 설정해주면 됩니다. 최신 버전인 1.1.0-m2 라고 설정하시면 되겠죠.

your-group-gourpId, your-project-artifactId, your-project-version 이 값들은 뭔지 아시리라.. 생각하고 생략하겠습니다.

그럼 대충 이런걸 타이핑해야 하는데... 정말 끔찍한 일이죠.

mvn archetype:create -DarchetypeGroupId=org.springframework.osgi -DarchetypeArtifactId=spring-osgi-bundle-archetype -DarchetypeVersion=1.1.0-m2 -DgroupId=whiteship -DartifactId=springdmweb -Dversion=1.0

이걸 어떻게 오타없이 타이핑하죠? 그래서 전 그냥 텍스트 파일에 붙여넣은 다음 확장자를 bat 파일로 바꿔서 dos 커맨드 창에서 createSpringDMProject.bat를 실행시킵니다.

필요하신 분들은 다운 받으신 다음에 groupdId와 artifactId 등을 수정하신 다음 사용하시면 됩니다. 그렇게 생성된 프로젝트는 이클립스에서 바로 import 해서 사용할 수 있습니다.

사용자 삽입 이미지
기본으로 테스트 클래스들까지 만들어 줍니다. 멋져부러...
신고
top


5.1. Bundle format and Manifest headers

Spring DM/Chapter 5 : 2008.05.08 20:05


각각의 애플리케이션 모듈은 OSGi 번들로 패키징해야 한다. 번들은 META-INF/MANIFEST.MF 파일을 가지고 있는 jar 파일이다. OSGi 서비스 플랫폼 핵심 스팩 3.2에서 그 자세한 내용을 살펴볼 수 있다. 몇몇 OSGi 구현체들은 풀어헤쳐진 jar 파일을 지원하지만 형식은 동일하다.

스프링 Extender는 번들은 "스프링이 가미된"Spring-Powered 번들을 인식하고 해당 번들에 연관된 애플리케이션 컨텍스트를 번들이 시작할 때 다음의 조건 중에 하나라도 만족하면 만들어 준다.
  • META-INF/spring 폴더에 하나 이상의 .xml 파일을 가지고 있을 경우.
  • META-INF/MENIFEST.MF 파일에 Spring-Context라는 헤더가 있을 경우.
보태자면, 만약 부가적으로 SpringExtender-Version 헤더를 manifest 파일에 추가하면, extender는 명시된 버전 조건을 충족시키는 번들만 인식할 것이다. 버전은 Bundle-Version에 명시되어 있다. SpringExtender-Version의 값은 OSGi 스펙을 따라야 한다.

Spring-Context 헤더가 빠져있는 경우 extender는 META-INF/spring 폴더 안에 있는 모든 파일을 유효한 스프링 설정 파일로 인식한다.

Application Context는 이런 파일들의 집합으로 구성된다. 권장하는 방법은 Applicaion Context 설정을 최소한 두 개의 파일로 나누는 것이다. 하나는 모듈이름-contet.xml 이고 다른 하나는 모듈이름-osgi-context.xml 로 말이다.
  • 모듈이름-context.xml - OSGi와 상관없는 일반적인 빈 설정들을 담는다. 최상위 엘리먼트를 bean으로 사용.
  • 모듈이름-osgi-context.xml - OSGi 서비스로 import/export 하는 빈들을 설정한다. 최상위 엘리먼트를 Spring OSGi 네임스페이스로 사용한다.
menifest 파일의 Spring-Context 헤더는 설정 파일 집합을 기술하기 위해 사용한다. 자원 경로는 상대 경로로 인식하고 여기에 하나라도 설정을 하면 META-INF/spring 폴더에 있는 파일들은 무시한다. 다음과 설정할 수 있다.

Spring-Context: config/account-data-context.xml, config/account-security-context.xml

가용한 설정 옵션
  • create-asynchronosly(false|true): 애플리케이션 컨텍스트를 비동기적으로 생성(이게 기본값)할지 동기적으로 생성할지 설정.
Spring-Context: config/account-data-context.xml;create-asynchrously:=false

  • wait-for-dependencies (true|false):  필수 서비스 의존성을 만족 할 때 까지 대기할지(이게 기본값) 말지 설정.
Spring-Context: config/osgi-*.xml;wait-for-dependencies:=false

  • timeout (300): 대기 시간 설정 기본값은 5분. 300초. 초 단위로 설정. wait-for-dependencies가 false면 이 값은 무시함.
Spring-Context: *;timeout:=60

  • publish-context (true|false): application context 객체 자체를 서비스 레지스트리에 등록할지(이게 기본값) 말지 설정.
Spring-Context: *;publish-context:=false



신고
top


귿!! OSGi위에 웹 애플리케이션 돌리기 성공 with Spring DM

Spring DM/exercise : 2008.04.30 18:00


사용자 삽입 이미지

위 그림 한장이면 돌리는 방법은 끝나죠.

맨 아래 보이는 녀석이 Spring DM 받으면 src/sample에 들어있는 웹 애플리케이션입니다. 자세한 내용은 좀 더 공부해야겠지만 일단 예제를 돌려서 기쁘네요.




현재 Servlet 까지는 됐는데, JSP는 아직 안 됩니다. 이것 저것 만지다보면 될 것 같네요.

신고
top


웹 애플리케이션과 OSGi

Spring DM/etc : 2008.04.30 08:47


참조 : http://blog.springsource.com/main/2008/04/29/web-applications-and-osgi/

왜 WAR를 OSGi에 배포하려는가?

쉬운 질문이군. OSGi는 기본적으로 버전잉과 패키지 엮기 그리고 핫 릴로딩을 지원한다. 여러분의 애플리케이션이 이런 장점들을 얻을 수 있다는 것을 상상해보라. .. 나머진 생략 ..

왜 웹 애플리케이션이 OSGi에서 문제가 되는가?

- Servlet 스펙은 웹 컨테이너를 기준으로 하고있다. 라이프 사이클 관리, 동시성, HTTP 요청 처리 등고 같은 표준 서비스를 제공하는 웹 구성요소다.
- OSGi 플랫폼은 서비스 레지스트리, 패키지 엮기, 버전잉과 같은 managed environment다.
- OSGI는 서블릿을 지원하기 위해 HTTP Service를 설계했다.
- 위의 API를 통해서 간단하게 서블릿을 등록할 수 있다.
- 서블릿이 OSGi 내부에서 요청을 처리하려면, 반드시 프로그래밍을 좀 해서programmatically 서블릿 객체를 만들고 적당한 API를 통해서 등록을 해야한다. 게다가 HTTP 서비스는 오직 서블릿 2.1 스펙만 지원한다.
- 이 문제를 다음과 같이 해결할 수 있다.
    - web.xml을 해석하는 등의 선언적인 방법을 통해서 코딩 줄이기
    - 표준 API를 확장하거나 2.1 API 위에 뭔가 더 만들어서 Servlet 2.1 이상의 기능을 제공하기
- Spring DM은 위와는 다르고 독특한 접근 방법을 체택했다.

웹 컨테이너를 직접 통합하기

- Spring-DM은 OSGi와 컨테이너 사이의 다리 역할을 한다.
- WAR를 그냥 컨테이너에 배포하듯이 배포하면 된다.
- OSGi와 컨테이너 둘 다 크게 변경될 것이 없다.
- Spring DM은 다음과 같은 것들을 지원한다.
    - 서블릿 2.4/2.5, JSP 2.0/2.1 스펙 지원
    - availability of the container capabilities (blocking vs non-blocking IO, allocated threads in the thread pool and so on)
    - web.xml 을 사용한다. 이걸 Spring DM이 파싱하는게 아니라 컨테이너에게 그 일을 위임한다. 원래 하던 녀석이 잘 할테니까..
    - 컨테이너 스펙 설정 파일(톰캣의 META-INF/context.xml 과 같은..)
- 현재 톰캣 5.5.x/6.0.x 와 제티 6.1.x 이상의 버전의 컨테이너를 사용할 수 있다.
- 웹 컨테이너가 웹 애플리케이션을 관리하고 컨테이너가 지원하는 모든 것들은 OSGi 번들들에게 가용하다.

1.1 최종판이 아직 발표되진 않았지만, M2를 접해보길 권장한다. 상당히 그대로 배포될 가능성이 많은 API들이며 새 기능들은 문서화해두었다. 도움이 필요하면 포럼으로 오고 메일링 리스트를 이용하라. 마지막으로 자바원에 온다면 SpringSource 부스에서 만나볼 수 있다.

ps: 알았다. 오바.
신고
top


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


Spring DM 소스코드 보기: fisheye

Spring DM/etc : 2008.04.09 13:01


스프링의 모든 프로젝트 코드를 한 눈에 볼 수 있습니다.
http://fisheye3.cenqua.com/browse/springframework

이 중에서 Spring DM의 소스 코드는 하위 디렉터리로 들어가면 되는데, 폴더 이름은 예전 이름 그대로인 spring-osgi네요.

사용자 삽입 이미지

http://fisheye3.cenqua.com/browse/springframework/spring-osgi


가장 최근에 수정한 코드 중에 DefaultOsgiApplicationContextCreator라는 녀석이 있군요.
소스코드를 보려면 일단 ~~.java 같이 링크로 되어 있는 녀석을 클릭합니다. 그러면 버전이 보이고,  annotated/raw라는 링크가 보이는데, 소스코드만 보고 싶으신 분들은 raw를 클릭하고, 이것 저것(누가 어디를 언제 수정했는지) 보고 싶으시 분들은 annotated를 클릭하면 됩니다.

사용자 삽입 이미지

음.. 대강 보니, 번들에서 스프링 설정 가져오과서 이게 스프링 DM이 지원하는 번들인지 본다음에, Spring DM이 지원하는 번들이면, ApplicationContext를 만들어서 서비스에 ApplicationContext를 등록하는 코드인가 봅니다.

와. 정말 깔끔하군요.


신고
top


What is new?

Spring DM/Chapter 3 : 2008.04.09 12:35


스프링 DM이 젊은 프로젝트(young project)이다 보니, 매 버전 마다 새로운 기능이 추가 된다. 이 번 챕터에 그 내용들을 다룬다.

1.1.X

1. Web Support

찬욱군 블로그에서 본 내용이군요.

The biggest feature in Spring Dynamic Modules 1.1.x is the transparent support for web applications on OSGi platforms.

멋진 단어 중에 하나인 Transparent 나왔습니다. non-invasive와 같은 맥락으로 이해하면 되겠죠. 투명하게 지원한다.. 뭐 이렇게 해석하시거나 이해(?)하시면 곤란합니다. 톰캣이나 제티같은 웹 컨테이너를 직접 통합하여 WAR를 바로 배포할 수 있도록 했다고 합니다.

Chapter 8에서 자세히 다룬답니다.

2. Classpath Resource Abstraction

OSGi resource를 찾을 때 classpath: 나 classpath*:를 사용할 수 있다. 마치 스프링의 component scanning과 비슷한 것이다.

OSGi resource에 대해서는 다음을 참조.
- Section 4.4 "The Resource abstraction"
- 4.3.12 of the OSGi specification

(흠.. 뭐 천천히 살펴보죠. 레퍼런스가 어디로 도망가는 것도 아니고..)

3. Pluggable Extender Configuration

1.1.X는 스프링 DM에서 사용하는 extender(이 녀석은 지난 번 토비형님이 JCO에서 발표하실 때 봤었죠. 스프링 DM에서 가장 중요한 번들로, application context를 만들어 줍니다.) 기본 설정을 쉽게 변경할 수 있는 기능이 추가 됨.

fragment(자 어려운 용어 계속 나옵니다.ㅋㅋㅋ 단순하게 번들 상속이라고 할까요. 흠.. 빌붙기라고 할까요. 자신의 클래스로더를 만들지 않고 다른 번들에게 빌붙을 수 있습니다.)를 사용해서 애플리케이션 컨텍스트를 시작하는 방법, 웹 배포에 사용할 웹 컨테이너, 스프링 애플리케이션이 돌아갈 쓰레드 풀등의 설정을 사용자가 커스터 마이징 할 수 있다. 또한 OSGi 스프링 애플리케이션 컨테스트 라이프사이클에 대응하는 이벤트를 받는 것이 가능하다. 4.1에서 자세히 다룸.
신고

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

What is new?  (0) 2008.04.09
OSGi 번들 상태 변화  (2) 2008.01.26
top


Requirements

Spring DM/Chapter 2 : 2008.04.09 12:02


스프링 다이내믹 모듈(DM) 1.0은 JDK 1.4 이상과 OSGi R4 이상을 지원한다.

스프링 DM을 사용해서 배포하는 번들은 반드시 MENIFEST.MF에 "Bundle-ManifestVersion: 2"라고 명시해야 한다.

저게 무슨 뜻이냐면, OSGi R4를 따르는 번들이라는 뜻이다. 스프링 DM이 OSGi R4 이상을 지원하니까 저렇게 해야한다. 2 말고 1이라고 할 수도 있는데 그건 OSGi R3 스펙을 따르는 번들이라는 뜻이다.

스프링 DM은 Continuous Integration의 일부로 Equinox 3.2.2, Felix 1.0.3, Knopflerfish 2.0.4에서 테스트를 한다고 합니다. 멋있어!
신고

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

Requirements  (0) 2008.04.09
top


Why Spring Dynamic Modules?

Spring DM/Chapter 1 : 2008.04.09 11:55


스프링 프레임워크는 full-stack Java/JEE를 이끌고 있는 애플리케이션 프레임워크다.

스프링 다이내믹 모듈은 스프링 애플리케이션을 OSGi 실행 환경에 쉽게 배포 할 수 있도록 돕는다.

엔터프라이즈 애플리케이션은 스프링 다이내믹 모듈과 OSGi 플랫폼을 사용하여 다음과 같은 장점을 얻을 수 있다.
- 보다 나은 모듈화. (모듈이라는 경계를 강화하여 애플리케이션 로직을 모듈 단위로 경계를 긋는다.)
- 모듈을 버전에 따라 동시에 여러개를 배포할 수 있다.
- 동적으로(런타임에) 시스템에 있는 다른 모듈이 제공하는 서비스를 사용하고 발견할 수 있다.
- 동적으로 모듈을 실행 중에 설치, 업데이트, 제거 할 수 있다.
- 스프링 프레임워크를 사용하여 여러 모듈에 걸쳐 컴포넌트들을 생성하고, 설정하고, 묶고assemble, 꾸밀decorate 수 있다.
- 개발자들이 쉽게 OSGi 플랫폼의 기능을 사용할 수 있도록 간단하고 익숙한 프로그래밍 모델을 제공한다.
신고

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

Why Spring Dynamic Modules?  (0) 2008.04.09
top







티스토리 툴바