OSGi

A collection of 42 posts

스프링 DM

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

참조: 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개&

Concurrency

Shared Mutable State

공유하는 불변 객체 가능한한 최소한의 객체만 공유하고, 가능한한 공유하는 객체를 immutable하게 유지함으로써, 기본적으로 “동시성 문제” 크기를 줄인다. 불행히도 이 방법으로는 문제 크기를 0으로 만들지는 못한다. 실제 대부분의 애플리케이션에서 공유하는 불변 객체 사용을 완전히 없애진 못하기 때문에, 그럴 때 안전한 방법을 찾아야 한다.

Concurrency

Concurrency and OSGi

참조 : http://neilbartlett.name/blog/osgibook/ J2EE 같은 무거운(heavyweight) 프레임워크에 비해, OSGi는 쓰레드를 포함한 JVM의 모든 리소스를 제어하려 들지 않는다. J2EE에선 직접 쓰레드를 만들거나 명시적인 동기화(synchronization)를 하는 코드를 작성하는 것을 금하고, 대신에 제한적인 “작업 관리” 프레임워크를 제공한다. OSGi는 여러분이

hibernate

OSGi에서 SessionFactory(Hibenate) 사용하기

참조 : http://www.osgi.org/blog/2007/06/osgi-and-hibernate.htmlhttp://notehive.com/wp/2008/07/23/osgi-hibernate-spring-dm-sample/ 번들 세 개만 살펴보겠습니다. 1. hibernate-class2. hibernate-session3. model-a1. hibernate-class 이 녀석은 하이버네이트 라이브러리를 묶어놓은 번들입니다. 얘가 담고 있는 라이브러리는 다음과 같습니다.이렇게 묶어놓은거 말고 스프링 번들 저장소에서

dynamic

OSGi 패키지가 아니라 서비스야 말로 진정한 Dynamic

번들과 번들 사이에서 자신이 가지고 있는 정보를 공유하는 방법은 두 가지 입니다. 패키지 안에 있는 클래스들을 공개해서 상대방이 내가 가진 클래스의 객체를 만들어서 사용하게 할 것이냐, 아니면 내가 패키지 말고 내가 객체를 만들어서 제공할 것이냐. 후자가 바로 서비스. 전자는 패키지입니다. 차이는 매우 큽니다. Dynamic

OSAF

OSGi 기반 프레임워크과 애플리케이션 아키텍처 진화 과정

대체 어떻게 모듈화 해야 할까… 어떻게 나눌 것인가.. 어떻게 구성해야 번들간의 상호참조(CD)를 없앨 수 있을까..어떻게 나눠놔야 개발을 할 때 여러 번들을 뒤적거리지 않을까.. 번들헬이 발생하지 않게 하려면… 위와 같은 고민들은 OSGi와 스프링 DM을 학습하다보면, 자연스레 맞닥드리게 되는 문제들입니다. 이

HANS

OSGi에서 Hibernate의 SessionFactory 문제

대체 어떻게 해야 할까? 뭘? @Entity 달려있는 클래스들이 여러 번들들에 분포되어 있고, 애플리케이션이 돌아가는 도중에 번들이 추가되고, 없어지고, 다시 설치되고, 업데이트 되는 와중에 SessionFactory는 그에 따라 계속 바껴야합니다. Spring이 제공하는 AnnotationSessionFactoryBean 클래스로 만드는 SessionFactory는 정적입니다. 한 번 만들고 다른 빈들이 주입받아서 사용하는데, 도통 어떻게

ㅁㄴ

국내 최초 OSGi 기반 애플리케이션 프레임워크 OSAF 1.5 - 멀지 않았다.

프로젝트와 프로젝트 사이에 텀이 생겨서, 요즘 다듬고 있는 OSAF 1.5 입니다. 범용성은 없고, 얼리어댑터에게만 유용한 프레임워크입니다. 초고속 애플리케이션 개발을 지원하는 OSAF의 맛보기 정도랄까요. 프로젝트를 만드는 김에 OSGi 번들로 만들생각입니다. 굳이 Spring DM 번들일 필요는 없지만, 일단 베이스는 Spring DM 번들로 시작했습니다. 보시면 이미

서비스

Late Binding in Java

참조 : http://neilbartlett.name/blog/osgibook/ OOP의 목적 중 하나는 의존성을 최대한 낮춰서 코드의 재사용성과 유연함을 늘리는 것이다. 자바에서는 인터페이스를 사용해서 이런 목적에 접근 했다. 인터페이스는 불편하고 그것을 구현한 구현체만 바꾸면 인터페이스를 사용하고 있는 클라이언트 코드는 변경할 필요가 없었기 때문이다. 하지만, 한계가 있는데, 객체를

Execution Environment

bnd에 번들 실행환경 설정하기

Bundle-RequiredExecutionEnvironment: J2SE-1.5, J2SE-1.4 이런식으로 설정하면 이 설정 그대로 MANIFEST.MF에 복사해서 붙여넣어줍니다. 모든 번들에 이런 실행환경을 설정해주는것이 좋겠죠. 가용한 설정 값드은 다음과 같습니다. CDC-1.0/Foundation-1.0CDC-1.1/Foundation-1.1JRE-1.1J2SE-1.2J2SE-1.3J2SE-1.4J2SE-1.5J2SE-1.6OSGi/Minimum-1.0OSGi/Minimum-1.1 1.5

클래스로딩

OSGi에서 클래스 로딩 순서

먼저, java.* 에 들어있는 클래스거나, org.osgi.framework.bootdelegation 속성에 설정된 클래스면 Parent Class Loader에게 클래스로딩 책임을 위임합니다. 다음은 Import-Packaged에 명시된 패키지에 들어있는 클래스라면, 클래스로딩 책임을 해당 클래스를 Export 한 번들의 클래스로더에게 위임합니다. 다음은 Required-Bundle 설정으로 참조한 패키지에 들어있는 클래스라면, 클래스로딩 책임을 해당 번들의

OSGi

Required-Bundle을 비추하는 이유

먼저 Required-Bundle이 뭔지 알아야겠다. Import-Package를 이해했으면 이건 뭐 아주 간단하다. 1. Resolved 상태가 되기 위한 조건 Import-Package 헤더에 명시한 패키지들이 어떤 번들들에 의해서 Export-Package 헤더이 설정 되어 있으면 해당 번들은  RESOLVED가 될 것이다.(물론 필수 였다는 가정하에.) Required-Bunlde은 번들 단위로 바꿔서 생각하면 된다.

Bnd

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

번들이 사용할 모든 라이브러리는 MANIFEST.MF 파일의 Import-Package에 기술 되어야 한다. 위의 문장은 맞는 문장일까 틀린 문장일까? 틀렸다. 예외가 있다. 바로 java.* 이하의 패키지들은 기술하지 않아도 된다. 별도의 import 없이도 사용할 수 있기 때문에 Import-Package에 굳이 명시할 필요가 없다. 하지만.. javax.*은 Import-Package에 명시해줘야

Java Classpath

Java의 Classpath 한계와 OSGi

자바에서 기본으로 제공하는 “모듈 시스템”이라고 할 수 있는 건 JAR 파일들을 모아둔 클래스패스 덩어리다. 이게 구린 이유는 의존성 관리를 하지 않기 때문이다. 그냥 암묵적으로 어떤 환경에서 실행되리라고 가정해버린다. 클래스패스에 필요한 것들이 있는지를 알 수도 없고 어떤게 필요한지도 알 수 없다. 따라서,

Archetype

Spring Dynamic Modules Maven Archetype

스프링 DM은 메이븐 아키타입archetype을 제공하여 스프링 DM 번들 개발 시에 사용할 수 있는 자바 프로젝트 기본 틀을 제공한다. 아키타입을 실행하려면 다음의 명령어를 사용하면 된다. mvn archetype:generate 메이븐 플러그인이 가용한 archetype을 보여줄 것이다. 그 중에서 spring-osgi-bundle-archetype을 선택하면 된다.(현재 32번으로 설정되어 있다.) 그리고 프로젝트에

You've successfully subscribed to Whiteship!
Could not sign up! Invalid sign up link.