Whiteship's Note

'Spring DM/etc'에 해당되는 글 36건

  1. 2009.07.11 스프링 슬라이스(Spring Slice)
  2. 2009.03.20 Our plans for building OSGi application 요약
  3. 2008.12.08 스프링 + OSGi(스프링 DM) 개발 필독 레퍼런스 3종 세트 (6)
  4. 2008.11.27 오호.. 스프링소스 manifest 헤더가 OSGi에 추가되는군요
  5. 2008.11.25 스프링 DM 1.2.0 m2 배포
  6. 2008.11.23 OSGi uses 충돌 감지하기
  7. 2008.11.23 OSGi "uses" 지시어 이해하기
  8. 2008.11.11 SpringSource DM Server 실습할 것 1
  9. 2008.11.09 SpringSource Application Platform(S2AP)은?
  10. 2008.10.04 Spring DM 1.1.2 릴리즈~
  11. 2008.09.15 OSGi 개발에 PDE가 필요한가?
  12. 2008.09.05 스프링 DM 1.2.0 M1 배포
  13. 2008.08.13 번들을 찾으려면.. http://www.springsource.com/repository/ (2)
  14. 2008.07.29 Spring DM 1.1.1 배포
  15. 2008.07.23 스프링 DM 모듈에서 단위 테스트하기(링크)
  16. 2008.07.20 Whiteship's 스프링 DM 레퍼런스 1.0 m3 배포
  17. 2008.07.10 Java의 Classpath 한계와 OSGi
  18. 2008.07.04 나이스~ 스프링 DM 1.1.0 정식판 배포
  19. 2008.07.03 Whiteship's 스프링 DM 레퍼런스 1.0 m2 배포
  20. 2008.07.03 OSGi 관리 툴이 떴네;; mToolkit (2)
  21. 2008.06.25 Spring DM 1.1.0 RC1 배포됐네요.
  22. 2008.06.24 Whiteship's 스프링 DM 레퍼런스 1.0 m1 배포 (4)
  23. 2008.06.22 스프링 DM 레퍼런스 편역(not 번역) 완료 (6)
  24. 2008.06.06 화이트보드 패턴 (2)
  25. 2008.05.14 Impala 프레임워크 "너무 빠르자나!!"
  26. 2008.05.04 스프링 OSGi 번들 저장소
  27. 2008.04.30 웹 애플리케이션과 OSGi
  28. 2008.04.29 Spring DM에 Spring MVC 연동 기능 추가됨. (4)
  29. 2008.04.15 OSGi는 의미가 없다. OSGi is irrelevant (2)
  30. 2008.04.09 Spring DM 소스코드 보기: fisheye

스프링 슬라이스(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

Write a comment.


Our plans for building OSGi application 요약

Spring DM/etc : 2009.03.20 20:51


참조 및 요약: Our plans for building OSGi application

OSGi 빌드 요구 사항

- 의존성 메타 데이터 중복 제거: 사용하는 빌드에 따라 pom.xml, ivy.xml에도 의존성을 정의하고 MANIFEST.MF 파일에도 의존성을 정의하는데 그러지 말고 한 곳에서 의존성을 정의하는 방법이 필요하다.

- 기존의 빌드 시스템 활용: 사용자들은 기존의 방식대로 메이븐 또는 Ant 빌드를 사용하고 싶어한다.

- 자동으로 MANIFEST.MF 파일 생성하기

- OSGi MANIFEST.MF 파일에서 의존성 가져오기: MANIFEST.MF 파일을 중심으로 의존성을 해결할 때 필요하다.

시나리오

1. 메이븐 + 이클립스 - pom.xml-주도: OSGi Manifest 파일은 메이븐 또는 이클립스 플러그인을 사용하여 자동생성한다. Manifest 생성에 필요한 대부분의 정보는 자바 코드에서 얻을 수 있지만 버전 정보는 그렇지 않다.  버전 정보는 pom.xml에서 그 정보를 가져올 수 있겠다. Manifest 템플릿을 통해서 그런 일을 할 수 있고 OSGi 속성이나 커스텀 헤더를 추가할 수 있겠다.

2. Ant + Ivy + 이클립스 - ivy.xml-주도: Ant 태스크로 manifest 파일을 생성한다. 위의 방법과 비슷하지만 단점으로 아직 이클립스에서 Ivy 2를 지원하는 플러그인이 없다. 개발자가 ivy.xml 파일을 작성하면 이클립스 플러긴을 사용해서 manifest를 만들고 이클립스 클래스패스를 자동으로 수정해주도록 한다.

3. 메이븐 + 이클립스 - MANIFEST.MF-주도: 개발자가 MANIFEST.MF 파일을 직접 또는 플러그인을 통해서 작성하면 그 파일을 기반으로 의존성을 처리한다. 이때 이클립스의 클래스패스 컨테이너를 이용한다. 테스트를 지원하기 위해 TEST.MF 파일에는 테스트에 필요한 의존성을 정의할 수 있게한다. 여기에 정의한 의존성은 테스트할 떄에만 가져온다. 남은 부분은 이것을 메이븐에 어떻게 적용하느냐 인데 현재 두 가지 옵션을 고려중이다. 하나는 pom.xml을 생성하는 것이고 다른 한 방법은 메이븐의 의존성 처리와 연동 또는 그것을 교체하는 것이다.

4. Ant + Ivy + 이클립스 - MANIFEST.MF-주도: 3번 방법과 비슷하고 2번의 단점인 Ivy 2 이클립스 플러긴 지원이 필요없어진다. Manifest-주도 이클립스 클래스패스 컨테이너를 사용할 것이기 때문이다.

OSGi 빌드 툴

- Bundlor: spring build 프로젝트에서 개발 중이며 몇 주후에 첫 번째 버전을 공개할 예정. 번들을 만들어 주며, manifest.mf 파일을 만들어 준다. http://www.springsource.com/repository/app/ 이곳에 있는 대부분의 번들을 이 툴로 만들었다. manifest 템플릿을 제공하여 커스터마이징 할 수 있게 해준다.

- BundlorEclipse: 이클립스 플러그인으로 Bundlor 기능을 이클립스에서 직접 사용할 수 있다. 소스 코드를 저장 버튼을 눌러 저장할 떄마다 manifest를 계속해서 수정해준다.

- 오프라인 의존성 리졸버

- Manifest 클래스패스 컨테이너

- 메이븐/Ivy 의존성 리졸버/pom.xml/ivy.xml  생성기

왜 bnd를 사용하지 않고 Bundlor를 만들었나?

처음에는 spring dm 프로젝트에서는 bnd를 사용했지만 다음의 부가 기능이 필요해서 만들었다.
- JDT-기반 코드 스캐닝
- 일부(Partial) 코드 처리하기
- 계속적인 manifest 생성

이클립스가 아닌 다른 IDE 활용하기

이클립스 말고 IntelliJ나 NetBeans 사용자를 위해 그쪽 팀에 Bundlor 핵심 라이브러리를 커밋했다. 그 결과 어떤 IDE 에서도 OSGi 개발 툴을 사용할 수 있게 됐다.

추가 요구사항

- 벌크 번들 생성

- 저장소-기반 코드 완성: dm 서버 저장소를 기반으로 소스 코드에서 자동 완성을 하면 자동으로 import 문을 추가해주고 Manifest에도 import 문을 추가해준다.
top

Write a comment.


스프링 + OSGi(스프링 DM) 개발 필독 레퍼런스 3종 세트

Spring DM/etc : 2008.12.08 14:13


스프링 DM 레퍼런스: http://static.springframework.org/osgi/docs/current/reference/html/
스프링 DM 서버 사용자 가이드: http://static.springsource.com/projects/dm-server/1.0.x/user-guide/html/index.html
스프링 DM 서버 개발자 가이드: http://static.springsource.com/projects/dm-server/1.0.x/programmer-guide/html/index.html

맨 위에껀 제가 번역/편역 해서 올린적이 있는데 지금은 또 많이 바껴서 다시 봐야겠고, 아래 두 문서도 분량이 얼마 되지 않으니 금방 읽어 보실 수 있습니다. 나머지 두 문서도 한글화를 할까 생각해봤는데 그럴 여유가 없더군요. 나중에 시간이 되면 블로그에 간단 요약 정도는 가능할지도 모르겠습니다.

읽는 순서는 일단 DM 레퍼런스를 보시는게 좋겠구요. 그 다음은 별로 순서가 필요없을 것 같습니다. 서버 사용법이 궁금하면 사용자 가이드를 보고, 개발할 때 dm 서버가 어떤 도움을 주는지 궁금하시다면 개발자 가이드를 보시면 됩니다. 개발자는 당연히 두 개 다 봐야겠죠? ㅋ

스프링을 사용하여 OSGi 개발이 상당히 편리해지고 있지만, 역시 핵심은 모듈화를 어떻게 할 것인가 인데.. 이건 삽질을 좀 해봐야겠습니다.

어찌됐든, dm 서버로 인해서 한층 OSGi 개발이 편리해진 것 같습니다. 손수 타겟 플랫폼 만들지 않아도 되고, 로깅 걱정 안 해도 되고, 에러 분석도 해주고, 배포 방법 다양하고, PAR 패키징 지원해서 여러 번들을 애플리케이션 별로 구분 할 수도 있고, 이클립스에서 편하게 사용할 수도 있으니 말이죠.

전 이제 자야겠습니다. 한국은 오후 2시 일텐데;;
top

  1. 이철우 2009.12.12 07:03 PERM. MOD/DEL REPLY

    OSGi, Spring-DM 처음 접하는데요, 궁금한것이 있어서 질문 드립니다.

    Spring-DM 과 Spring-OSGi 가 뭐가 다른가요?

    Favicon of http://whiteship.me BlogIcon 기선 2009.12.12 10:01 PERM MOD/DEL

    Spring DM이 Spring DM Server와는 전혀 다른 겁니다. 예전에 Spring OSGi 라는 프로젝트 이름을 Spring DM으로 바꾼거죠.. 마치 Acegi -> Spring Security로 바꾼것처럼이요.

  2. 이철우 2009.12.12 07:54 PERM. MOD/DEL REPLY

    질문 하고 보니까 조금 바보같은 질문 이었네요.

    http://www.springsource.org/osgi
    The Spring Dynamic Modules for OSGi(tm) Service Platforms project makes it easy to build Spring applications that run in an OSGi framework. A Spring application written in this way provides better separation of modules, the ability to dynamically add, remove, and update modules in a running system, the ability to deploy multiple versions of a module simultaneously (and have clients automatically bind to the appropriate one), and a dynamic service model.

    OSGi Service Platform 를 위한 스프링 디엠 프로젝트는 OSGi 프래임웍에서 실행되는 스프링 어프리케이션 을 쉽게 빌드할수 있게해 줍니다. 이러한 방식으로 개발된 스프링 어프리케이션은 더나은 모듈의 분리, 실행되는 시스템에서 모듈들을 추가하고, 삭제하고, 또 업데이트 하는 능력, 같은 어프리케이션의 다른 버젼들을 동시에 실행 (이 경우 클라이언트가 자동으로 자기에게 맞는 버젼으로 접속합니다), 그리고 능동적인 서버 모듈을 가집니다.

    그러니까 Spring-dm Server 는 실행하는 서버고, Spring-OSGi 는 프래임웍 (아님 라이브러리?) 같은 건가요? (Spring-OSGi 라는게 있기는 한건가?)

    어제 spring-dm-server 다운 받아서 실행해보고, 오늘 spring-osgi 다운 받아서 maven 으로 인스톨 실행 시켜 봤는데, 아직 뭐가 뭔지 모르겠군요. 참, spring-osgi-2.0.0.M1 intelliJ 로 열고 maven install (with sample option checked) 했더니 프로젝트 위도우에 수많은 폴더들이 만들어 지던데요, 혹시 해보셨는지요?

    Favicon of http://whiteship.me BlogIcon 기선 2009.12.12 10:09 PERM MOD/DEL

    "그러니까 Spring-dm Server 는 실행하는 서버고, Spring-OSGi 는 프래임웍 (아님 라이브러리?) 같은 건가요? (Spring-OSGi 라는게 있기는 한건가?)"

    네. 그렇습니다. Spring DM Server는 OSGi 번들을 배포할 수 있는 서버입니다. Spring DM Server 말고도 OSGi 플랫폼은 여러 개 있습니다.

    "참, spring-osgi-2.0.0.M1 intelliJ 로 열고 maven install (with sample option checked) 했더니 프로젝트 위도우에 수많은 폴더들이 만들어 지던데요, 혹시 해보셨는지요?"

    아니요. 아직 안해봤습니다. 개인적으로;; OSGi 기술을 쓰려면 아직 스프링이 좀 더 고생해줘서 사용하기 편해지면... 그때 다시 사용을 시도할 생각입니다. 지금도 과거에 비하면 많이 편하진거겠지만;;; 저한텐 좀 힘들더라구요; @_@;

  3. 이철우 2009.12.13 06:46 PERM. MOD/DEL REPLY

    답글 감사드립니다.

    좋은 주말 보내세요.

    Favicon of http://whiteship.me BlogIcon 기선 2009.12.14 10:55 PERM MOD/DEL

    흑흑 주말이 넘 짧아요. 좋은 한 주 되세요~

Write a comment.


오호.. 스프링소스 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

Write a comment.


스프링 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

Write a comment.


OSGi uses 충돌 감지하기

Spring DM/etc : 2008.11.23 18:39


참조 및 번역: Diagnosing OSGi uses conflicts

Glyn은 최근에 "OSGi "uses" 지시어 이해하기"를 제공했다. 나(Rob Harrop)는 uses 제약 위반 원인을 좀 더 자세히 살펴보고 여러분 애플리케이션에서 발생하는 uses 문제 해결에 유용한 몇 가지 팁을 제공하고자 한다.

나는 대부분의 예제에서 dm Server 보다는 이퀴녹스를 사용하려고 한다. 그 이유는 uses 제약사항이 dm Server에 한정적인 것이 아니고 모든 OSGi 사용자와 관련된 것이기 때문이다. 이 블로그 마지막에는, dm Server에 구축된 매우 똑똑한 제약 사항 실패 진단 몇 가지를 보여줄 것이다.

의존적인 제약 불일치(Dependent Constraint Mismatch)


가장 흔한 uses 위반은 한 개 이상의 의존적인 제약 사항끼리의 불일치 때문이다. 예제로 다음 세 개의 manifest를 살펴보자.

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
Import-Package: eclipselink;version="[1.0, 2.0)"

Manifest-Version: 1.0
Bundle-Name: EclipseLink 1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 1
Export-Package: eclipselink;version="1.0.0"

Manifest-Version: 1.0
Bundle-Name: EclipseLink 2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 2
Export-Package: eclipselink;version="2.0.0"

스프링 번들 한 개와 두개의 eclipselink 번들이 있다. 물론 실제 번들은 아니다. spring 번들은 [1.0, 2.0) 버전 번위의 eclipselink 패키지를 사용한다. 분명히 오직 eclipselink_1 번들만이 이 제약 사항을 만족한다. 이제 다른 두 개의 애플리케이션 manifest를 살펴보자.

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="[1.0, 1.0]"

Manifest-Version: 1.0
Bundle-Name: App2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app2
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="[2.0, 2.0]"

app1은 exlicpselink [1.0, 1.0] 범위를 참조하고, app2는 eclispelink [2.0, 2.0] 범위를 참조한다. 만약 이 두 개의 번들을 이퀴녹스에 설치하고 app 번들들을 start 시도하면, 콘솔에서 다음과 같은 결과를 확인할 수 있다.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
2       RESOLVED    spring_2.5.5
3       RESOLVED    eclipselink_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app1_1.0.0
6       INSTALLED   app2_1.0.0

sprig과 eclipselink 번들들은 모두 잘 리졸브 된 걸 볼 수 있다. app1 번들은 시작(start)했지만, app2 번들은 시작하지 못했다. 이유를 알아보기 위해 diag 커맨드를 사용할 수 있다.

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [6]
  Package uses conflict: Import-Package: spring.orm.hibernate; version="0.0.0"

여기서 우리는 spring.orm.hibernate 패키지를 임포트하는 부분에서 uses 충돌로 인해 해당 번들을 리졸브 할 수 없다는 것을 알 수 있다. 이것은 app2에서 spring.orm.hibernate를 임포트하는 것을 안 된다는 것이다. 그 이유는 다른 import로 인해 spring.orm.hibernate를 제공하는 번들의 uses 제약 사항이 깨질 수 있기 때문이다.

이를 진단하는 과정 처음으로 할 일은 spring.orm.hibernate 번들의 가용한 공급자를 찾아내는 것이다. 우리는 이미 해당 공급자가 spring 번들이라는 걸 알고 있지만, 만약 공급자를 모른다면 packages 커맨드를 사용할 수 있다.

osgi> packages spring.orm.hibernate
spring.orm.hibernate; version="2.5.5"<file:/Users/robharrop/dev/resdiag/uses/spring/bin [2]>
  file:/Users/robharrop/dev/resdiag/uses/app1/bin [5] imports

여기서 spring.orm.hibernate 패키지를 번들 2에서 공급(export)했다는 것을 알 수 있다. 이 정보를 가지고 번들 2의 spring.orm.hibernate에서 uses 지시어에 어떤 패키지가 등록되어 있는지 확인할 수 있다.

osgi> headers 2
Bundle headers:
 Bundle-ManifestVersion = 2
 Bundle-Name = Spring Bundle
 Bundle-SymbolicName = spring
 Bundle-Version = 2.5.5
 Export-Package = spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
 Import-Package = eclipselink;version="[1.0, 2.0)"
 Manifest-Version = 1.0

여기서 우리는 uses에 있는 유일한 패키지 eclipselink 패키지가 범인이라는 걸 알 수 있다. 사실, 스프링 번들은 eclipselink [1.0, 2.0) 범위를 참조하는 반면 app2는 eclipselink [2.0, 2.0] 범위를 참조하는 걸 확인할 수 있다. 이 두 범위는 상충한다. app2는 스프링 번들이 사용하는 eclipselink와 동일한 버전을 연결할 수 없다.

uses 목록이 긴 경우는, 어떤 패키지의 제공자가 둘 이상인지를 확인하여 위반을 한 패키지 범위를 좁혀볼 수 있다. uses 제약을 위반 패키지를 제공하는 공급자는 반드시 둘 이상이다.

버전 불일치는 의존 제약 불일치의 유일한 원인이 아니다. 속성도 버전처럼 제약 문제를 발생 시킬 수 있다.

설치 순서 문제


앞선 예제를 다시 살펴보자. spring 번들의 manifest를 변경하여 eclipselink 2.0 패키지를 참조하도록 변경하고 app1은 1.0 이상의 모든 버전을 허용하도록 수정하여 문제를 수정해보자.

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
Import-Package: eclipselink;version="[1.0, 2.0]"

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="1.0"

번들들을 설치하고 app 번들을 시작하면 큰 변화가 생긴걸 볼 수 있다.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       RESOLVED    eclipselink_2.0.0
4       ACTIVE      app1_1.0.0
5       ACTIVE      app2_1.0.0

이제 두 개의 app 번들 모두 시작 할 수 있다. 불행히도 좀 더 교묘한 이슈가 우리를 기다리고 있다. 설치 순서에 따라, 이 번들 집합체는 같이 실행되지 않을 수도 있다. 이를 실험해보기 위해서, spring, eclipselink_1과 app1을 한 묶음으로 설치하고 app1을 실행한다.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0

자 이제 eclipselink_2와 app2를 설치한다.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       INSTALLED   app2_1.0.0

app2 번들은 시작되지 않는다. diag 통해 왜 그런지 살펴보자.

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [5]
  Package uses conflict: Import-Package: spring.orm.hibernate; version="0.0.0"

uses 충돌이 다시 발생했다. 이번에는 앞선 진단 과정이 아무런 도움이 되지 않느다. 의존성 제약 불일치가 없기 때문이다. 첫 번째에 모두 잘 리졸브 됐기 때문에 이건 이미 알고 있다.

이슈는 리졸루션 순서에 있다. 번들들은 두 덩어리로 나눠서 설치하고 리졸브 했다. 첫 번째 덩어리는 spring, eclipselink_1, app1 이고 두 번째 덩어리는 eclipselink_@와 app2다. (app1 번들을 시작(start)한 결과로..)첫 번째 덩어리가 리졸브 될 때, spring 번들은 esclipselink 패키지를 가져올 때 eclipselink_1 번들에 묶이게 된다. 이것을 콘솔에서 확인해보자.

osgi> bundle app1
file:/Users/robharrop/dev/resdiag/uses/app1/bin [3]
  Id=3, Status=ACTIVE      Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/3/data
  No registered services.
  No services in use.
  No exported packages
  Imported packages
    spring.orm.hibernate; version="2.5.5"<file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]>
    eclipselink; version="1.0.0"<file:/Users/robharrop/dev/resdiag/uses/eclipselink1/bin [2]>
  No fragment bundles
  Named class space
    app1; bundle-version="1.0.0"[provided]
  No required bundles

import packages 섹션에서 eclipselink 버전 1.0.0이 eclipselink_1 번들에서 가져온 걸 확인할 수 있다. 두 번째 덩어리를 설치하면 app2 번들은 eclipselink 버전 2를 필요로 하는데, spring이 이미 eclipselink 1.0.0 버전에 묶여 있어서 리졸브되지 못한다. 한 덩어리로 모든 번들을 설치하고 리졸브 할 때는, OSGi 리졸버가 spring.orm.hibernate의 uses 제약도 만족하면서도 다른 모든 제약사항을 만족하도록 시도할 것이다.

이 문제를 고치기 위해 우리 번들을 수정할 필요는 없다. 대신, 모든 번들을 한 덩어리로 설치하거나 spring 번들을 리프래쉬 하면 된다. 그렇게 해서 OSGi가 다시 리졸루션 과정을 거치도록 한다. 이제 eclipselink_2 번들이 설치되고 이번에는 다른 결과를 예상할 수 있다.

osgi> refresh spring

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app2_1.0.0

osgi> bundle spring
file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]
  Id=1, Status=RESOLVED    Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/1/data
  No registered services.
  No services in use.
  Exported packages
    spring.orm.hibernate; version="2.5.5"[exported]
  Imported packages
    eclipselink; version="2.0.0"<file:/Users/robharrop/dev/resdiag/uses/eclipselink2/bin [4]>
  No fragment bundles
  Named class space
    spring; bundle-version="2.5.5"[provided]
  No required bundles

spring 번들을 리프래시해서 app2 번들도 리졸브 된 걸 볼 수 있다. spring 번들에서 연결할 eclipselink 패키지가 eclipselink_2 번들의 2.0 버전으로 바꼈다.

dm 서버에서 uses 제약 사항

uses 제약 위반이 dm 서버에서 발생하면, 여러분이 해야할 분석 절차를 알아서 제공해준다. 특히 불일치하는 패키지를 담고 있을 가능성이 있는 의존성 제약을 식별할 때 도움이 된다.

Could not satisfy constraints for bundle 'app2' at version '1.0.0'.
 Cannot resolve: app2
  Resolver report:
    Bundle: app2_1.0.0 - Uses Conflict: Import-Package: spring.orm.hibernate; version="0.0.0"
      Possible Supplier: spring_2.5.5 - Export-Package: spring.orm.hibernate; version="2.5.5"
        Possible Conflicts: eclipselink

uses 제약사항은 엔터프라이즈 라이브러리에서 매우 흔히 사용하며 손수 실패 원인을 분석하는 것은 악몽같은 일이다. 특히, uses를 사용하는 패키지가 10 개 이상 있을 때는, 가용한 충돌을 판별하는 작업은 상당한 시간-낭비를 초래한다. 따라서 자동화 검진은 필수이며, 나는 dm 서버에서 진당 코드가 향상되어 흔히 발생하는 문제가 아무것도 아닌 것처럼 다룰 수 있게 되길 바란다.

다음 배포판에서는, 진단 도구를 dm 서버 이클립스 툴에 바로 포함시켜서 dm 서버에서 이런 문제들을 대부분 자동으로 분석하도록 할 수 있게 할 계획이다.
top

Write a comment.


OSGi "uses" 지시어 이해하기

Spring DM/etc : 2008.11.23 17:08


참조 및 번역: Understanding the OSGi "uses" Directive

스프링 DM 서버 또는 다른 어떤 OSGi 플랫폼 기반의 애플리케이션을 빌드 할 때, 여러분은 아마도 머지않아 "uses"라는 지시어를 보게 될 것이다. 이 지시어의 목적을 분명하게 이해하지 않는다면, 여러분은 언제 그것을 사용해야 하는지도 모를 뿐더러, "uses" 충돌("uses" conflict)로 인해 번들 resovle가 되지 않을 때 의문만 생길 것이다. 본 기사에서 "uses" 지시어를 이해하고, 언제 사용해야 하는지, 그리고 어떻게 "uses" 충돌을 디버깅하는지 살펴보겠다.

번들 리졸루션(Resolution)


OSGi는 일단 번들이 "리졸브"(resolve) 상태가 되도록 설계되어 있다. 클래스 캐스트 예외나 타입이 맞지 않아서 발생하는 그와 비슷한 문제들이 발생하지 않도록 해야 한다. 이는 OSGi가 각각의 번들마다 하나의 클래스 로더를 사용하기 때문에 사용자들이 타입 불일치 문제를 만나게 될 여지가 많다. 그래서 매우 중요하다.

런타임에 사용하려면 일단 클래스 로더에 의해 자바 타입이 로딩이 되어야 해당 타입의 클래스나 객체 같은 것을 사용할 수 있다. 런타임 타입은 타입의 전체 클래스 이름과 해당 타입을 정의한 클래스 로더의 조합으로 정의한다. 만약 동일한 전체 클래스 이름이 두 개의 다른 클래스 로더를 사용하여 정의되어 있다면, 두 개의 호환하지 않는 런타임 타입을 생성한다. 이런 비호환성으로 인해 두 타입의 어떤 "접촉"(contact)을 하게 될 경우 런타임 에러를 발생한다. 예를 들어, 이 두 타입 중 하나를 다른 타입으로 캐스팅을 시도할 때 클래스 캐스트 예외가 발생한다.

OSGi는 유일한 클래스 로더 기반 자바 모듈 시스템이 아니지만 지금까지 가장 성숙한 시스템이다. 즉 OSGi 설계자들은 오랫동안 힘들게 이런 종류의 문제들을 다려왔고 그 해결책을 OSGi 스펙에 포함시켜왔다. OSGi 설계는 이런 문제들을 애플리케이션 코드가 동작하기 전에 발경하는 것이다. 즉 리졸루션(resolusion)이라는 단계에서 말이다. 리졸루션(Resolution)은 자바와 같은 엄격한 타입 제한 프로그래밍 언어에서 애플리케이션 코드를 실행하기도 전에 특정 문제들을 발견할 수 있는 컴파일과 유사하다. 여러분의 번들을 resovle 하려면 가끔 머리가 아플 수도 있다 하지만 이는 클래스 캐스트 예외와 같은 런타임 에러 진단을 해준다.

그래서 번들 리졸브(resolve)는 무엇을 의미하는가? 이것은 번들의 의존성을 확인했다는 뜻이다. 일반적으로 해당 번들이 사용하는(import) 패키지를 공개한(export) 번들들을 찾았고 그 버전 제약을 만족시킨다는 뜻이다. 가장 명확한 제약 사항은 모든 공개된(export) 패키지 버전이 사용하려는(import) 패키지 버전 범위 내에 포함되어야 한다. 또 다른 제약 사항으로는 패키지 임포트(import)에 기술 할 수 있는 임의 속성이 그에 대응하는 패키지 익스포트(export) 속성과 일치해야 한다는 것이다.

여러 번들에 의해 공개된 패키지


우리가 곧 살펴볼 uses 지시어는 하나 이상의 번들에 의해 공개되는 패키지에서 발생하는 타입 불일치를 해결할 목적으로 사용한다. 어떤 한 번들의 타입을 다른 번들의 타입으로 사용할 필요가 있을 때, 런타임 타입이 호환되지 않기 때문에, 타입 불일치 문제가 발생한다. 예를 들어, 어떤 번들에서 다른 번들의 클래스 이름이 같지만 다른 타입으로 타입 캐스팅을 시도할 때 클래스 캐스팅 예외가 발생한다. 어떻게 이런 일이 발생할까? 번들은 동일한 패키지를 하나 이상의 번들에서 가져올(import) 수 없기 때문이다. 상충하는 타입을 접촉(contact) 시킬 어떤 방법이 있어야 한다. It happens by a type being passed "through" a type in another package..

어떤 타입을 다른 타입으로 전달(pasess through)하는 방법은 두 가지가 있다. 첫 번째 방법은 어떤 타입이 다른 타입을 명시적으로 참조하는 것이다,. 예를 들어, 다음은 org.bar 패키지에 있는 Bar 타입의 어떤 메소드는 org.foo 패키지의 Foo 타입을 참조할 수 있다.

public Foo getFoo();

어떤 타입을 다른 타입으로 암묵적으로 전달하는 두 번째 방법은 서브타입을 이용하는 것이다, 예를 들어, 다음은 서브타입을 참조하는 메소드 시그너쳐다.

public Object getFoo();

암묵적인 경우, 서브타입의 객체는 어느 순간에는 상충하는 타입으로 캐스팅될 것이다.

자바 코드 수준에서 그런 타입 불일치가 어덯게 발생하는가. 번들 manifest가 어떻게 생겼는지 살펴보자.

필요한 타입 Foo는 org.bar 패키지를 공개하는(export) 번들과 동일한 번들이 공개하거나

bundle-symbolicname: B
bundle-manifestversion: 2
export-package: org.foo,org.bar

또는 다른 번들(F)이 공개할 수도 있을 것이다.

bundle-symbolicname: B
bundle-manifestversion: 2
export-package: org.bar
import-package: org.foo

bundle-symbolicname: F
bundle-manifestversion: 2
export-package: org.foo

"uses" 지시어는 OSGi가 위와 같은 타입 불일치를 번들 리졸루션 과정에서 진단할 수 있도록 도입되었다.

"uses" 지시어


위와 같은 잠재적인 타입 불일치를 리졸루션 과정에서 찾아내기 위해, 자바 코스 수준에서의 명시적인 또는 암묵적인 타입을 그에 상응하는 번들 manifest에 선언해야 한다. 공개하는 패키지는 "uses" 지시어를 붙여서 해당 패키지가 참조할 패키지를 선언해준다.

위 예제에서, 공개하는 패키지 org.bar는 org.foo 패키지를 "사용"(use) 한다고 선언한다.


export-package: org.bar;uses:="org.foo"


"uses" 지시어에서 사용하는 패키지나 패키지들은 "uses" 지시어를 사용하고 있는 번들 manifest에서 공개(export) 또는 가져올(import) 패키지에 명시되어 있는 것들이어야 한다. 따라서 다음은 유효한 manifest지만


export-package: p;uses:="q,r", q
import-package: r


다음은 유효하지 않은 manifest다.(q 패키지를 export 또는 import 하고 있지 않기 때문에)


export-package: p;uses:="q,r"
import-package: r


추이적인 "ueses"


타입 참조는 추이적이다. 예를 들어, 타입 C를 참조하는 타입 B를 타입 A가 참조할 경우에, A의 사용자는 B를 통해서 C를 참조할 수 있다.

타입 참조가 이렇게 추이적이기 때문에, OSGi는 자동적으로 이를 고려했다. "uses" 지시어의 "추이적인 클로져"(transitive closure)라고 알려져 있는 것이 바로 그것이다. 이것은 "uses" 지시어를 사용하기만 하면 OSGi가 알아서 추이적인 타입 참조를 다뤄준다는 것이다.

예를 들어, 다음 번들 manifest를 보자


export-package: p;uses:="q,r", q;uses:="r"
import-package: r


문법에 맞다. 다음 번들 manifest는 "p에서 q", "q에서 r" 그리고 "(추이적으로) p에서 r" 타입 참조를 충분히 잘 표현한 것이다.


export-package: p;uses:="q",q;uses:="r"
import-package: r


(역자 주, 위랑 아래랑 같으니까 아래처럼 사용해도 된다는 뜻입니다.)

"uses" 충돌 감지하기(Diagnosing)


번들 레졸루션 과정은 모든 제약 사항을 확인하는 것이 주목적이다. 따라서 모든 "uses" 제약 사항이 만족하지 않을 경우 "uses" 충돌을 보고할 것이다. 스프링 dm 서버가 주는 진단 이슈는 이런 문제를 해결하는데 도움을 준다.

원리를 이해하기 위해 만든 예제를 살펴보자. 클라이언트 번들 C가 사용할 몇몇 유틸리티 번들 F와 B을 만들고 있다고 가정해보자. 새로운 버전의 F를 추가하고다음 mainfest들을 가지고 서버에 배포한다고 가정해보자.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: F
Bundle-Version: 1
Bundle-Name: F Bundle
Export-Package: org.foo;version=1

(역자 주, 버전이 1이니까 이전에 사용하던 F 유틸 번들 이겠네요.)

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: F
Bundle-Version: 2
Bundle-Name: F Bundle
Export-Package: org.foo;version=2

(역자 주, 버전이 2니까 이번에 새로 추가한 F 유틸 번들인가 봅니다.)

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: B
Bundle-Version: 1
Bundle-Name: B Bundle
Export-Package: org.bar;uses:="org.foo"
Import-Package: org.foo;version="[1,2)"

(역자 주, 이것도 유틸 번들인데, F 유틸 번들 1와 2가 공개하는(export) org.foo 패키지 버전 1 이상 2 미만을 사용하고 있군요. 결국 F 유틸 번들 버전 1을 사용하겠네요.)

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: C
Bundle-Version: 1.0.0
Bundle-Name: C Bundle
Import-Package: org.bar,org.foo;version="[2,3)"

(역자 주, 이건 클라이언트 번들인 C 인데 org.foo 패키지를 사용하는 데 그 버전이... 이런.. 2 이상 3 미만을 사용합니다. 그러면 이 번들은 지금 새로 설치한 F 유틸 번들 버전 2를 사용하게 됩니다. 뭔가 꼬였군요. 왜냐면 여기서 또 사용하기로(import)되어 있는 org.bar 패키지에서는 F 유틸 번들 버전 1의 org.foo 패키지를 사용하니까요. 두 패키지가 호환되지 않자나요. 같은 패키지지만 다른 번들이 공개한 거니까 런타임 타입이 다르죠. 왜냐면 클래스로더가 다르니까.)

C 번들을 설치하려고 하면, dm 서버는 다음과 같은 로그 메시지를 출력한다,

<SPDE0018E> Unable to install application from location 'file:/xxx/C.jar/'. Could not satisfy constraints for bundle 'C' at version '1.0.0'.
Cannot resolve: C
Resolver report:
Bundle: C_1.0.0 - Uses Conflict: Import-Package: org.bar; version="0.0.0"
Possible Supplier: B_1.0.0 - Export-Package: org.bar; version="0.0.0"
Possible Conflicts: org.foo

이 중에서

Bundle: C_1.0.0 - Uses Conflict: Import-Package: org.bar; version="0.0.0"

이 줄은 org.bar 패키지 임포트와 관련하여 "uses" 제약 위반이 있다는 것을 알려준다. 즉, C가 사용하려고 하는 공개된(export) org.bar의 "uses"가 만족스러운 상황이 아니라는 것이다.

Possible Supplier: B_1.0.0 - Export-Package: org.bar; version="0.0.0"

이 줄은 org.bar 공급자가 의심스럽다는 것이고

Possible Conflicts: org.foo

이 줄은 어떤 패키지에서 "uses" 제약 사항이 위반되는지 알려준다.

구체적인 것에서 다시 돌아와서, 우리는 "uses" 충돌이 발생한 이유를 알고 있다. 번들 C가 가져오는 org.foo 패키지가 번들 B가 가져오는 것과 버전이 다르기 때문이다. B가 최신 버전의 F를 사용하도록 설정하는 것을 깜빡했다.

B의 manifest를 다음과 같이 수정한다.

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: B
Bundle-Version: 1
Bundle-Name: B Bundle
Export-Package: org.bar;uses:="org.foo"
Import-Package: org.foo;version="[2,3)"

이제 번들 C를 성공적으로 배포할 수 있다.

복잡한 "uses" 충돌 진단하기


의도적으로 만든 "uses" 충볼은 번들 manifest를 보고서로 알 수 있을 만큼 간단한 문제였다. 하지만 매우 많은 충돌 가능성이 있는 "uses" 지시어 목록과 같은 좀 더 복잡한 "uses" 충돌의 경우, Equinox 콘솔(2401포트로 telnet)을 사용하여 성공적으로 설치된 번들을 확인해 볼 수 있다.(dm 서버는 성공적으로 배포하지 못한 번들은 uninsatll 시킨다.)

이퀴녹스 콘솔 명령어를 사용하여 설치된 번들 목록을 확인할 수 있다.,

osgi> ss

위에서 만들어본 문제 상황에서 다음과 같은 목록을 확인할 수 있다.


82 ACTIVE F_1.0.0
84 ACTIVE F_2.0.0
85 ACTIVE B_1.0.0

B 번들 manifest를 보려면 다음과 같이 한다.

osgi> headers 85

그리고 패키지 org.foo 패키지를 공개한 번들과 사용하는 번들을 보려면 다음과 같이 한다.

osgi> packages org.foo

요약


본 기사는 "uses" 지시어 필요성을 살펴봤고, 이를 사용하여 타입 불일치 에러 문제를 조기에 진단할 수 있는 방법을 보았다. 그리고 dm 서버 진단과 이퀴녹스 콘솔을 사용하여 "uses" 제약 위반을 확인하는 방법도 살펴보았다.

(마지막 단락은 번역 스킵)

You may think the "uses" directive is more trouble than it is worth, but when you consider the alternative of tracking down the reason for a possibly obscure class cast exception while your application is running, you should start to see the rationale for "uses". Indeed any Java module system which doesn't provide the equivalent of "uses" constraints is likely to give you class cast exceptions at runtime once you have gotten to the point of having multiple versions of your application modules. The OSGi "uses" directive solves a general problem of Java modularity.
top

Write a comment.


SpringSource DM Server 실습할 것 1

Spring DM/etc : 2008.11.11 23:01


서버 로그 확인
- cd serviceability/trace/
- less trace.log

서버 실행 할 때 옵션주기
- bin/startup.sh -jmxremote
- jconsole

덤프뜨기(jconsole에서)
- 덤프 버튼 클릭
- 생성된 덤프 파일 확인(amte 파일경로)

웹 프로젝트 만들기
- new -> project -> springsource dm server -> module project
  - 모듈 타입을 web으로 설정 할 것
  - 페이지 컨텍스트 설정 할 것
- MODULE-INF 폴더 만들기(웹 기본 폴더가 되는 듯), 그 뒤에 웹 리소스 쫘르륵..
- 컨트롤러 추가하기
- Manifest.mf에 Import-Library: org.springframework.spring;version="[2.5.5.A,3.0.0)" 추가
- META-INF 밑에 spring 폴더 만들고 스프링 설정 파일 추가.
  - module-context.xml
  - 컴포넌트 스캔
  - 뷰 리졸버
  - AnnotationMethodHandlerAdapter
- 프로젝트를 S2DM 서버로 드래그 앤 드랍
- localhost:8080/페이지 컨텍스트 경로 확인.

동영상을 보고 따라해보려고 해봤지만, 굵은 글씨 부분에서 막혔습니다. 저렇게 추가를 해도 라이브러리를 못찾습니다. 번들 클래스 패스에 추가가 되어야 할텐데 그게 안 되네요. 흠.. 플러그인 문제인듯.. 그게 잘 되야 좀 편하게 개발할텐데..
 
top

Write a comment.


SpringSource Application Platform(S2AP)은?

Spring DM/etc : 2008.11.09 21:34


S2AP랑 S2DS랑 햇갈려서 찾아 봤더니 S2AP는 S2DS와 S2E를 포함한 것을 말하는군요.

참조: http://www.springsource.com/products/suite/applicationplatform

The SpringSource Application Platform is an end-to-end platform that is designed from the ground up for complete portability and scalability for today’s data center and for next-generation virtualized, grid, and cloud computing deployments. The Platform is a collection of products designed to provide the optimal environment to build, run and manage enterprise Java applications that utilize Spring based technologies, including:

[막 번역]
S2AP는 단대단 플랫폼으로 요즘 데이터 센서에 완전히 호환가능하며 확장성 좋도록 설계했고 또한 다음 세대의 가상화, 그리드 그리고 클라우드 컴퓨팅 배포를 고려하여 설계했다. 이 플랫폼은 스프링 기반 기술을 사용하는 엔터프아리스 자바 애플리케이션을 빌드, 실행 그리고 관리하는데 최적의 환경을 제공하는 제품들로 구성되어 있다. 다음을 포함하고 있다.

    *  SpringSource Enterprise delivers the software, services, and technical support necessary to ensure that your organization develops and runs Spring-powered enterprise applications more productively, securely and with the greatest uptime.
    * SpringSource dm Server is a completely modular, OSGi-based Java server designed to run enterprise Java applications and Spring-powered applications with a new degree of flexibility and reliability.

S2E: 스프링을 사용하는 엔터프라이스 애플리케이션을 보다 효율적이고, 잘 사용할 수 있도록 소프트웨어, 서비스 그리고 기술 지원을 한다.
- Spring Enterprise Edition
- SpringSource Perfomance Suite
  - SpringSource Tool Suite
  - SpringSource Application Management Suite
  - SpringSource Advanced Pack of Oracle
- SpringSource Support

S2DS: 완전 모듈화한, OSGi-기반 자바 서버로, 엔터프라이즈 자바 애플리케이션과 스프링을 사용하는 애플리케이션을 새로운 수준의 유연성과 신뢰도를 가지고 실행할 수 있다.
사용자 삽입 이미지




top

TAG S2AP, S2DS, S2E

Write a comment.


Spring DM 1.1.2 릴리즈~

Spring DM/etc : 2008.10.04 18:58


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

이번엔 그닥 눈의 띄는 changelog가 없네요.
top

Write a comment.


OSGi 개발에 PDE가 필요한가?

Spring DM/etc : 2008.09.15 20:21


절대로 그렇지 않습니다. 오히려 OSGi를 처음 접할 때 이클립스 PDE(Plug-in Development Environment)로 시작하면, 더 낯설고 복잡해 보입니다. 왠지 꼭 그런 도구가 있어야 개발할 수 있을 것 같은 기분이 들죠. 그래서, 오히려 처음 OSGi 개발을 시작하거나 공부할 때는 PDE를 사용하지 않는게 더 좋은 방법이라고 생각합니다. 최소한의 도구만을 사용하는것이 오히려 OSGi 학습에 도움이 될 수 있습니다.

또한, 도구들은 어느정도 학습자로써 반드시 알아야 할 것을 감추는 경향이 있습니다. 도구를 사용하는 것은 좋치만, 마치 자바를 배울 때 javac Hello.java 랑 java Hello도 안 해보고 이클립스에서 Run As -> Java Application만 실행하는 것에는 큰 차이가 있듯이..말이죠.

그래서 OSGi 학습을 할 때 권장하는 도구는 최소한의 자바 프로젝트 편집기 + bnd 입니다. bnd는 MANIFEST.MF 생성과, 해당 프로젝트를 번들로 묶어주는 역할을 합니다. MANIFEST.MF 파일을 bnd로 만드는 이유는 MANIFEST.MF 파일이 단순한 텍스트 파일이 아니기 때문입니다. 한 행당 길이 제한이 있으며, 사용할 수 있는 헤더와 값을 지켜서 만들어야 합니다. bnd는 그런 불편함을 최소화 해줍니다. 그리고 번들로 만들어 주는 기능을 제공하는 이유는 이 MANIFEST.MF 파일이 jar 파일의 젤 상위 META-INF라는 폴더의 젤 처음에 위치해야 합니다. 그래야 일반 jar가 아닌 OSGi 번들로 인식합니다. 그렇게 패키징 해주는 기능을 제공하는 겁니다.

물론 Maven을 사용한다면, 이야기가 조금 달라집니다. 이때는 M2Eclipse 기반의 메이븐 프로젝트 + 메이븐 번들 플러그인입니다. 메이븐 번들 플러긴은 bnd 툴을 그대로 메이븐 플러긴으로 만든 것인데, 이 플러긴이 메이븐 페이스(phase)에 끼워져있어서, 해당 mvn package를 실행할 때, 해당 프로젝트를 번들화 하는 작업이 추가됩니다. 번들화라고 해봤자, MANIFEST.MF를 생성해서 제 위치에 넣어주는 것 뿐입니다. 따라서 Maven 프로젝트 관리 + 플러긴 하나로 OSGi 개발을 할 수 있습니다.

bnd에서 MANIFEST.MF 파일을 만들기 위한 설명서로 .bnd 파일을 만드는데, 이 파일은 properties 파일 처럼 키= 값 형태 입니다. 이 때 사용하는 키는 Manifest 헤더와 비슷한 것들이 많기 때문에 Manifest 헤더를 이해하는데 도움이 되고, 이클립스 플러긴으로 사용할 수도 있어서 .bnd 파일을 우클릭하면 make bundle이라는 메뉴가 생기는데 이것을 클릭하면 바로 MANIFEST.MF 파일 생성하고 해당 프로젝트를 번들로 만들어줍니다. 이클립스에서 export 하면 길고 긴 마법사 쭉 따라가야 하는데 그런 불편함이 없죠. 그야말로 OSGi 학습과 개발에 매우 유용한 툴이 아닌가 싶습니다.

OSGi를 학습하시는 분들에게 PDE 보다는 bnd 사용을 권해 보면서 마무리 하겠습니다.

2008/06/22 - [Spring DM/exercise] - bnd를 소개합니다.
2008/07/08 - [Screen Casting] - Eclipse에서 bnd 사용해서 번들 만들기
2008/07/10 - [Spring DM/exercise] - bnd 사용해서 API 가져오기(Import)
2008/07/13 - [Spring DM/exercise] - bnd에 번들 실행환경 설정하기
2008/08/18 - [Spring DM/exercise] - pom.xml에서 bnd 설정 파일 분리하기


top

TAG Bnd, OSGi, pde

Write a comment.


스프링 DM 1.2.0 M1 배포

Spring DM/etc : 2008.09.05 20:43


참조 : http://www.springframework.org/node/754

눈에 띄는 변경 사항은 딱 하나

"스프링 MVC 예제, 그것도 애노테이션 기반의 예제를 추가했다."
top

Write a comment.


번들을 찾으려면.. http://www.springsource.com/repository/

Spring DM/etc : 2008.08.13 12:04


http://www.springsource.com/repository/ 필요한 번들을 찾으려면 왼쪽 사이트에 가셔서 검색하시면 됩니다. 다소 복잡한 dep 구조를 가지고 있는 하이버네이트도 잘 정리되어 있었습니다.

사용자 삽입 이미지

위에 링크에서 번들 파일을 바로 다운로드 할 수 있으며, Maven을 사용할 때는 아래 dependency 덩어리를 pom.xml에 추가하면 됩니다. 그리고 이 번들이 의존하는 다른 번들들의 링크까지 확인할 수 있습니다.

하단의 Required Dependencies 바를 펼치면 해당 링크로 바로 이동할 수 있죠.
사용자 삽입 이미지

이렇게 위 사이트의 도움으로 OSAF 1.5의 모든 의존성을 해결해서 ACTIVE 상태로 만들 수 있었습니다.

사용자 삽입 이미지

차근 차근 진행이 되어 갑니다. 멀지 않았습니다. 하지만, 한 발짝 물러나야 할 일이 생겼군요.

1. OSAF 1.5 모듈에서 스프링 DM이 해줄 일이 생겨서, 빈 몇 개를 서비스로 등록을 해야겠습니다. 컴포넌트 스캔 확인 좀 해야겠네요. 컴포넌트 스캔까지 되면...

2. 다음은 예제 만들어서 저 번들이 제공하는 서비스와 패키지를 제대로 쓸 수 있는지 확인하고..

3. 간단 튜토리얼 만들고...

4. OSAF 웹 사이트좀 꾸민 다음..

5. 최종 배포!!!

멀지 않았습니다. 배포한 뒤에는 좀 더 심화 작업을 진행할 생각입니다.

6. 기존 시스템 OSGi화 하기

7. 코드 제너레이터 만들기

8. 이클립스 플러긴 만들기
top

  1. Favicon of http://anarch.springlog.com/ BlogIcon anarcher 2008.08.14 11:05 PERM. MOD/DEL REPLY

    우와. 머찌네요. +__+
    혹시 코드 제네레이터가 rails 처럼 제네레이터하는 건가요?+_+
    혹시 어떤 식으로 구성하실지 알수 있나요? +_+
    잼있겠네요. ;-)

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2008.08.14 11:45 PERM MOD/DEL

    Rails 처럼 제너레이터라 함은.. 도메인 모델 클래스가지고, DAO, Service, Controller, CRUD 뷰까지 쭉 만들어주는거 말씀하시는거죠?

    템플릿 엔진이랑 XML 파일로 설정 파일 만들어서 좌르륵 생성하는 걸 간단하게 만들어 보긴 했었는데요.

    흠~ 좀 더 확장성이랑 유연함을 고려해서.. 다시 만들 계획입니다.

Write a comment.


Spring DM 1.1.1 배포

Spring DM/etc : 2008.07.29 23:44


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

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

Write a comment.


스프링 DM 모듈에서 단위 테스트하기(링크)

Spring DM/etc : 2008.07.23 08:53


http://springtips.blogspot.com/2008/07/unit-test-with-spring-dynamic-modules.html

제목은 단위 테스트인데, 사실 OSGi 환경에서 번들로 설치한 담에 실행하는 것이고, 스프링 ApplicationContext도 사용하고 있으니까 정확하게는 통합 테스트 입니다. 제목이 굳이 단위 테스트인 이유는 몰겠네요. 흠.. 단위 테스트를 왜 OSGi 환경에서 실행했을라나..

어쨌든, 스프링 DM에서 테스트를 작성하는 방법을 설명해주고 있는 괜춘한 글입니다. 벌써 저렇게 자기 애플리케이션을 스프링 DM 번들로 전환하는 작업을 마친 사람들도 많은데, 저도 좀 분발해야겠습니다.
top

Write a comment.


Whiteship's 스프링 DM 레퍼런스 1.0 m3 배포

Spring DM/etc : 2008.07.20 12:20



지난 배포 뒤에 시간좀 오래 걸렸습니다. 크게 달라진 건 없고, 10장과 Appendix A, B, C, D, E를 추가했습니다.


생략한 표들을 추가하는 작업까지 완료하면, 1.0 정식판이 완성 될 것 같습니다.
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.


나이스~ 스프링 DM 1.1.0 정식판 배포

Spring DM/etc : 2008.07.04 22:27


http://forum.springframework.org/showthread.php?t=56895

짝짝짝!!
top

Write a comment.


Whiteship's 스프링 DM 레퍼런스 1.0 m2 배포

Spring DM/etc : 2008.07.03 23:59




Change Log
- confluence로 깔끔하게 옮겼습니다.
- confluence에서 pdf 로 뽑아냈습니다.(깔끔하고, 링크도 살았습니다.)
- 일부 제목을 번역했습니다.
- 내용을 약간 다듬었습니다.

Next Version
- 생략한 표들을 추가할 계획입니다.
- 원래 계획 대로라면, M3이 될 것 같네요.
- 뒷 부분에 생략한 부분도 추가할 계획입니다.


top

Write a comment.


OSGi 관리 툴이 떴네;; mToolkit

Spring DM/etc : 2008.07.03 22:48


우와;; 오늘 번들 관리하는 모듈을 만들고 있었는데.. 김빠지게 시리..GUI로 번들 관리할 수 있는 툴을 무료 배포해버리는군요. 하하핫. 괜찮아 괜찮아 기선아. 너도 열심히 해서 만들자꾸나...

사용자 삽입 이미지


http://dz.prosyst.com/oss/
top

  1. Favicon of http://yunsunghan.tistory.com BlogIcon Max 2008.07.04 10:01 PERM. MOD/DEL REPLY

    이제 관련 tool이 하나,둘씩 나오기 시작하는군요...
    (OSGi 학습해야 하는데...)

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.07.04 11:58 신고 PERM MOD/DEL

    네. 알게 모르게 많이 나와있더라구요. ㅋㅋ
    OSGi 전쟁 중인듯..

Write a comment.


Spring DM 1.1.0 RC1 배포됐네요.

Spring DM/etc : 2008.06.25 23:29


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


top

Write a comment.


Whiteship's 스프링 DM 레퍼런스 1.0 m1 배포

Spring DM/etc : 2008.06.24 11:18



Can u feel the fire~ I get higher~. Nobody nobody nobody no~ can't nobody hold me down~.
Whiteship's 스프링 DM 배포 로드맵

현재 버젼 m1
1. 편집 상태가 상당히 허접합니다.
2. 초장부터 끝장까지 일관적이지가 않습니다. 초반에는 거의 편역과 요약 형태인데, 뒤로 갈 수록 번역 스타일로 변해갑니다.
3. 시간이 넉넉치 않아서, 일단 처리하고 볼려는 심산입니다.

m2 는 다음주 쯔음에...
1. 편집 상태를 좀 더 다듬어서. 링크도 살리고, 기타 등등.
2. 제목을 번역

m3 은 다다음주 쯔음에...
1. 전반적인 문채를 다듬어서 필요한 부분을 추가하고 필요 없는 부분은 삭제. 즉 내용을 수정합니다.
2. 그림과 표를 추가합니다.

v1 정식버젼 배포는 다다다음주 쯔음에..
1. docbook을 이용해서 HTML과 PDF 파일로 배포하기 시도.
2. 잘 되면, maven을 이용해서 빌드

v2 스프링 DM 레퍼런스 구현 기약 없음.
1. 레퍼런스 내용을 다루는 모든 예제 코드 만들기
2. 스프링 DM, OSGi를 익히는데 필요한 로우 레벨의 지식 탐구 정리(Classloading과 Cuncrrency)

v3 더더욱 기약 없음.
1. 스크린 캐스팅 추가

다운로드는 이 곳에서..
top

  1. Favicon of https://seal.tistory.com BlogIcon 물개선생 2008.06.24 13:03 신고 PERM. MOD/DEL REPLY

    m1 버전이였던 거얌.. ^^* 2주 후에 한번 더 받아야 겠네.

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2008.06.24 13:32 PERM MOD/DEL

    네. 지금껀 배포를 위한 용도구요. 링크도 다 짤렸고(편집 과정 중에 글자만 복사하느라..) 편집이나 내용 정리도 좀..해야되서요.ㅋㅋ

  2. Favicon of http://www.jazz.pe.kr BlogIcon 아름프로 2008.06.24 15:56 PERM. MOD/DEL REPLY

    수고하셨습니다. ~

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.06.24 18:02 신고 PERM MOD/DEL

    넹~

Write a comment.


스프링 DM 레퍼런스 편역(not 번역) 완료

Spring DM/etc : 2008.06.22 00:32


파트 3 Other Resouces와 파트 4 Appendixes를 제외한 파트 1, 2, 3(1장부터 9장까지 편역을 드디어 완료했습니다. 얼마 되지도 않는데 정말 오래도 걸리네요. 어찌됐든 일독, 정독, 요약, 편역 했다는데 의미를 두고 링크를 정리해봅니다. 원하시는 분이 계시다면, PDF나 웹 페이지로 정리해서 배포할 생각도 있는데, 원하시나요?

1 장. Why Spring Dynamic Modules?
2 장. Requirements
3 장. What is new?
4 장. Bundles and Application Contexts
    4.1. The Spring Dynamic Modules Extender bundle
    4.2. Application Context Creation
    4.3. Bundle Lifecycle (2)
    4.4. The Resource abstraction
    4.5. Accessing the BundleContext
    4.6. Application Context Destruction
    4.7. Stopping the extender bundle
5 장. Packaging and Deploying Spring-based OSGi applications
    5.1. Bundle format and Manifest headers
    5.2. Extender configuration options
    5.3. Required Spring Framework and Spring Dynamic Modules Bundles
    5.4. Spring XML authoring support
    5.5. Importing and Exporting packages
    5.6. Considerations when using external libraries
    5.7. Diagnosing problems
6 장. The Service Registry
    6.1. Exporting a Spring bean as an OSGi service
    6.2. Defining references to OSGi services
    6.3. Exporter/Importer listener 베스트 프랙티스
    6.4. Service importer global defaults
    6.5. 서비스 Exporter와 서비스 Importer의 관계
7 장. 번들 다루기
8 장. Web Support
    8.1. 지원하는 웹 컨테이너
    8.2. Web support 사용법
    8.3. WAR classpath in OSGi
    8.4. web extender 설정하기
    8.5. Customizing the standard deployers
    8.6. OSGi-ready libraries and web development
    8.7. Spring-MVC Integration
9 장. Testing OSGi based Applications
    9.1. OSGi Mocks
    9.2. Integration Testing
top

  1. Favicon of http://sonegy.egloos.com BlogIcon 소내기 2008.06.22 00:40 PERM. MOD/DEL REPLY

    토비님 블로그에서 하이버네이트 강의 듣다가 방문했는데, 월척 게시물이 올라왔네요! 아이쿠 넙죽~

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.06.22 00:44 신고 PERM MOD/DEL

    넵~ 헤헷. 차린건 별거 없지만 많이 드세요.

  2. Favicon of http://seal.tistory.com BlogIcon 물개 2008.06.23 09:36 PERM. MOD/DEL REPLY

    하루에 몇 개씩 그렇게 열심히 하더니, 멋지삼.

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2008.06.23 11:48 PERM MOD/DEL

    헤헷 감사합니다. :)

  3. Favicon of http://www.yangkun.pe.kr BlogIcon 건이아빠 2008.07.05 23:55 PERM. MOD/DEL REPLY

    네~ 원해요~~ PDF :)

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2008.07.06 00:19 PERM MOD/DEL

    http://whiteship.tistory.com/1721 여기서 받으실 수 있습니다. :)

Write a comment.


화이트보드 패턴

Spring DM/etc : 2008.06.06 00:02


도입

OSGi 서비스의 다이내믹한 특징 때문에 프로그래머가 그 변경 사항을 추적해야 하는 노고가 필요한데, 이전에는 리스너들을 사용했었는데 이게 너무 복잡해지고 에러가 발생할 여지가 많아서 이 문서에서 그 이슈를 살펴보고 보다 쉽고 근본적으로 더 신뢰할 수 있는 모델을 설명하고자 한다.

배경

1. 리스너 패턴

자바의 기본적인 이벤트 리스너 구조 설명 생략.

리스너 패턴의 단점. 클래스 파일이 너무 많다. 프로그램 시작 시간에 영향을 주고 프로그램 사이트에도 영향을 주고 따라서 실행시 오버헤드가 존재한다. 대부분의 경우 이벤트 소스는 단일 리스트만 등록한다. 그런데도 이벤트 소스는 리스너들 리스트를 다룰 수 있도록 반드시 추가적인 벡터를 가지고 있어야 한다. 물론 이 문제가 메모리가 남아돌고 CPU가 빠른 데탑에서는 별 문제가 아니지만 임베디드 환경에서는 매우 중요한 오버헤드다.

또 다른 이슈는 이벤트 소스와 리스너 사이의 의존성이 분명하지 않다는 것이다. 이벤트 소스가 사라지면 그것이 물고 있던 리스너들도 제거되어야 한다. 만약 리스너가 없어지면 해당 리스너를 리스너 목록에서 제거해야 한다. 이런걸 사이프 사이클 이슈라고 한다. 일반적인 자바 애플리케이션에서는 이게 별 문제는 아니다. 일반적으로 초기화 과정 중에 리너너들을 등록하는데 이건 뭐 구현하기도 쉽고 확인하기도 쉽다. 하지만, 제거 하는 과정은 검증하기가 어렵고 보통 전혀 이런 과정을 다루지도 않는다. 워크스테이션 환경에서는 이게 별 문제가 아니다. 하지만 임베디드 환경에서는 이런 가정을 할 수 없으며 완전히 동적이지도 않다.

2. OSGi 환경

OSGi 환경에는 다음고 같은 것들이 필요하다
• Small devices
• Collaboration model
• Continuously up and running VM
• Life cycle management

작은 장치. 각각의 클래스 파일은 300 에서 500 바이트의 오버헤드를 가지고 있다. 따라서 파일이 많아질 수록 안 좋다. 따라서 OSGi 스펙 만드는 초기 시절에는 어설픈 예외 클래스나 어댑터 클래스들을 만들지 않기로 결정했었다.

작은 장치는 성능과 동적 메모리에도 제약이 있다. 메모리를 사용하는 객체들을 만드는 것도 최소화하는 방안을 스펙을 만들며 시도했다.

OSGi 협력 모델은 서비스 레지스트리를 사용하여 만들어졌다. 이 레지스트리는 번들(이게 곧 애플리케이션)이 서비스를 등록하도록 한다. 서비스는 보통 자바 객체이며 자바 인터페이스를 사용하여 다른 구현체로 갈아 칠 수도 있로고 한다. 레지스트리의 동적인 성격은 서비스가 언제 나오고 들어가는지 서비스 추적할 수 있는 무언가를 필요로 하게 됐다.

지속적인 수정과 실행 기능은 "라이프 사이클 관리"와 "다른 프로그래밍 규칙을 필요로하는 서비스 레지스트리"에 관련되어 있다.

 3. 화이트보드 패턴

화이트보드 패턴은 리스너 패턴으로 인해 필요한 사적인 레지스트리를 만드는 대신 서비스 레지스트리의 사용을 강화한 것이다. 이벤트 리스너를 이벤트 소스에 등록해서 이벤트를 추적하는 대신 화이트보드 패턴은 리스너 자체를 서비스로 등록하고 이벤트 소스가 이벤트를 가지고 서비스 레지스트리에 있는 모든 리스너들을 호출하는 방법이다.

사용자 삽입 이미지
보통은 서버 번들과 애플리케이션 번들 간에 복잡도 트레이드 오프가 있기 마련인데, 이 경우에는 둘 다 복잡도가 낮아진다. 둘 모두 OSGi 서비스 레지스트리에게 책임을 위임했기 때문이다.

추가적인 장점
- 디버깅: 이벤트 리스너를 레지스트리에서 볼 수 있다. 어떤 프레임워크도 레지스트리를 탐색하는 도구를 지원할꺼다.
- 시큐리티: OSGi 프레임워크 ServicePermissions는 이벤트 소스로의 접근을 제어할 수 있다. 이벤트 리스너가 이벤트 리스너 인터페이스를 등록할 수 있는 권한을 가지고 있어야하기 때문이다.
- 프로퍼티즈: 레지스트리는 모든 리스너중 부분집합을 선택할 때 서버가 사용할 프로퍼티즈를 사용할 수 있다. 이런 매카니즘을 설정 관리에 사용할 수 있다.

참조 : http://www.osgi.org/documents/osgi_technology/whiteboard.pdf

top

  1. Favicon of http://blog.hyukhur.com BlogIcon 허혁 2008.06.09 14:45 PERM. MOD/DEL REPLY

    화이트 보드 패턴을 볼 때마다

    시티헌터가 생각이 납니다.

    항상 의뢰는 게시판를 통해서 받았지요..

    ㅋㅋ

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2008.06.09 19:46 PERM MOD/DEL

    전 시티헌터를 안 봐서 잘 모르겠네요 :)

Write a comment.


Impala 프레임워크 "너무 빠르자나!!"

Spring DM/etc : 2008.05.14 00:12


"영양" 프레임워크가 서버 사이드에서 공식 배포를 알렸습니다.

http://code.google.com/p/impala/wiki/QuestionAndAnswers 맨 아래에 영양이라고 이름 지은 이유가 나옵니다. 영양의 자태가 곱고graceful, 엘리강트하며elegant, 기민하기agile 때문이라고 합니다. 이름 잘 짓네요.ㅋㅋ

벌써부터 스프링 DM 기반 OSGi 프레임워크가 나왔습니다. 모듈화(어떻게 잘 쪼갤 것인가)에 대한 고민과 그들의 대안을 볼 수 있는 좋은 기회라고 생각합니다.

흠.. 대충 main(공통), module, test, web, repository로 쪼갰던게, 각각에 대한 자세한 설명은 아직 못 읽었습니다. 12시가 넘으면 안약을 넣어도 졸리기 때문에 자야겠습니다.

기능 요약
http://code.google.com/p/impala/wiki/Features

시작 하기
http://code.google.com/p/impala/wiki/GettingStarted

top

Write a comment.


스프링 OSGi 번들 저장소

Spring DM/etc : 2008.05.04 22:54


스프링 DM과 Maven을 사용하시는 분들에겐 희소식입니다.
OSGi 플랫폼에 배포가 가능한 상태의 번들들을 모아둔 스프링 저장소 입니다.

http://www.springsource.com/repository/app/

위의 링크에서 필요한 번들을 검색하여 다운로드 할 수 있으며 Maven이나 Ivy를 사용하시는 분들은 <dependency> 엘리먼트를 사용하여 의존성을 추가할 수 있습니다.

다음은 hibernate annotation 번들을 검색한 결과 화면입니다.

사용자 삽입 이미지
자세한 설명은 여기를 참조하세요.


top

Write a comment.


웹 애플리케이션과 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

Write a comment.


Spring DM에 Spring MVC 연동 기능 추가됨.

Spring DM/etc : 2008.04.29 21:31


참조 : http://static.springframework.org/osgi/docs/1.1.0-m2/reference/html/web.html#web:spring-mvc

1.1.0 M2가 나왔습니다. 눈에 띄는 변화는 단연 Web쪽 기능 추가. 자세한 내용은 레퍼런스를 보라고하지만, 레퍼런스보다 예제코드가 더 배고픈데 말이죠.

오늘 밤은 스프링 DM과 함께~


스프링은 역시 멋져부러~
top

  1. Favicon of http://yunsunghan.tistory.com BlogIcon Max 2008.04.30 08:50 PERM. MOD/DEL REPLY

    예제코드도 곧 나오겠는걸요?
    (기선씨에 의해서...^^; )

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.04.30 10:02 신고 PERM MOD/DEL

    헤헷 열공하고 있습니다. ^^

  2. Favicon of http://jjaeko.tistory.com BlogIcon 쨐오 2008.04.30 13:19 PERM. MOD/DEL REPLY

    Spring MVC 죠아요?

    Favicon of http://whiteship.tistory.com BlogIcon 기선 2008.04.30 13:29 PERM MOD/DEL

    아니요. 우우~~~ 우우우~~~ (농담입니다.)

Write a comment.


OSGi는 의미가 없다. OSGi is irrelevant

Spring DM/etc : 2008.04.15 23:32


http://rossmason.blogspot.com/2008/04/osgi-is-irrelevant.html

한참 재미있게 Spring DM for OSGi를 공부하고 있고, OSGi의 매력에 빠져들고 있는 요즘.. 갑자기 기운이 쭉빠지게 하는 제목의 글을 만났습니다.

그런데 왠 걸.. 내용은 제가 예상했던 그런 내용이 아니였습니다. Spring DM 공부하길 잘했다는 것을 결론으로 마무리가 되었습니다.

저 글을 쓰신분은 로존슨과 세미나에서 OSGi에 대해 갑론을박을 나눈 경험이 있으신가 봅니다. 어쨋거나 제가 이해한 주요 내용은 이러합니다.

OSGi가 뜨고 있다. ---> OSGi가 제공해주는 서비스들은 좋다. ---> 그 서비스들이 고객에게 의미가 있는 것이지 그 내부 동작 원리가 의미가 있는 것은 아니다. ---> 따라서 OSGi에 대해서는 점차 이야기 할 일이 줄어들 것이고 어떻게 하면 OSGi의 장점을 잘 살릴 수 있는 기반 애플리케이션을 설계할 것인가가 주요 이슈가 될 것이다.

Spring DM과 같은 OSGi 추상화 계층이 정말 제 역할을 다 해줘서 OSGi API와 자세한 동작 원리를 몰라도 될 정도로만 해 준다면, OSGi 가 제공하는 서버스와 그 기능에만 초점을 맞춰 학습하는게 효울적인 것 같습니다. OSGi 플랫폼 개발자 이거나 Spring DM과 맞먹는 프레임워크를 만들겠다면 모를까...

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

화이트보드 패턴  (2) 2008.06.06
Impala 프레임워크 "너무 빠르자나!!"  (0) 2008.05.14
스프링 OSGi 번들 저장소  (0) 2008.05.04
웹 애플리케이션과 OSGi  (0) 2008.04.30
Spring DM에 Spring MVC 연동 기능 추가됨.  (4) 2008.04.29
OSGi는 의미가 없다. OSGi is irrelevant  (2) 2008.04.15
Spring DM 소스코드 보기: fisheye  (0) 2008.04.09
OSGi 번들 만들기 2  (0) 2008.04.08
OSGi 번들 만들기 1  (0) 2008.04.08
스프링 DM 벌써 1.0.2  (2) 2008.03.26
Spring OSGi 관련 링크  (0) 2008.01.31
top

  1. Favicon of http://evilimp.tistory.com BlogIcon evilimp 2008.04.16 11:11 PERM. MOD/DEL REPLY

    로그존슨은 누구냐는...;;; ㅋㅋㅋ

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2008.04.16 11:53 신고 PERM MOD/DEL

    ㅋㅋㅋ모르셨어요? 로드존슨 동생이에요.
    어제 밤에 하두 졸려가지고..

Write a comment.


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

Write a comment.