Tagged

스프링 DM

A collection of 29 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개– Include-Resource– Private-Package 오호~~ 귿~

@ServiceReference

Spring DM Extentions

이번 Appendix 장에서는 1.0 배포판부터 추가된 핵심 기능을 확장한 기능들을 다루지만, 이 다음 배포판에서도 그대로 확장으로 있을지는 보장하지 못한다. 이 기능들을 핵심 기능 쪽으로 옮기는 것을 생각하고 있기 때문이다. B.1. 애노테이션 기반 주입 org.springframework.osgi.extensions.annotation 번들은 OSGi 서비스 레퍼런스를 주입하는 애노테이션을 제공한다. 이 기능을 사용하려면

Compendium Service

A.1. Configuration Admin

A.1.1. Property placeholder support 스프링 DM은 빈 속성 값을 OSGi Configuration Administration 서비스에서 가져오는 기능을 지원한다. 이 기능은 property-placeholder 엘리먼트를 이용하여 사용할 수 있다.  property placeholder 엘리먼트는 “${…}” 이런 형태의 구분자를 사용한 부분의 빈 속성 값을 Configuration Administratino 서비스에서 가져와서 설정해준다. 이 때 persistent-id 속성으로

Chapter 9

9.2. Integration Testing

OSGi처럼 제한적인 환경에서는 여러분들이 작성한 클래스의 가시성과 버전관리, 번들이 다른 번들과 제대로 동작하는지를 확인하는 것이 중요하다. 통합 테스트를 편하게 하기위해, 스프링 DM 프로젝트는 테스트 클래스 계층구조를 제공한다(org.springframework.osgi.test.AbstractOsgiTests를 기반으로) . 이걸 사용해서 자동으로 OSGi 환경에서 실행되는 일반적인 JUnit 테스트 케이스를 작성할 수 있다. 보통 스프링 DM 프로젝트가

스프링 DM

9.1. OSGi Mocks

대부분의 OSGi API들이 인터페이스고 EasyMock같은 라이브러리를 사용하여 목객체를 만들어 사용하는 것이 간단할 수도 있지만, 실제로는 상당히 많은 코드를 필요로 한다.(특히 JDK 1.4에서..) 테스트를 짧고 간결하게 유지하기위해, 스프링 DM은 org.springframework.osgi.mock 패키지 아래에 OSGi 목들을 제공한다. 이것들이 유용한지 아닌지는 여러분들에게 달려있다. 우린 스프링 DM 테스트 스위트를 만들

스프링 DM

Chapter 9. Testing OSGi based Applications

베스트 프랙티스를 잘 따르고 스프링 DM 지원 기능을 사용한다면, 여러분들이 작성한 bean 클래스들은 단위 테스트가 용이할 것이다. OSGi를 직접 참조하지도 않을 것이고, 최소한의 인터페이스 기반의 OSGi API(BundleContext와 같은..)만을 사용하여 mock 객체를 만드는 것도 쉬워질 것이다. 단위 테스트와 통합 테스트 둘 다 스프링 DM이 지원한다.

Chapter 8

8.7. Spring-MVC Integration

1.1부터 스프링 DM은 스프링 MVC 프레임워크와 밀접하게 통홥되었다. 이번 섹션에서 어떻게 스프링 MVC 애플리케이션을 OSGi 환경에서 실행할 수 있는지 살펴보겠다. OSGi 플랫폼에서 제대로 사용되려면, 스프링 MVC를 새로운 환경으로 이전해야 한다. 스프링 DM은 OSGi를 인식하는 application context를 제공한다.(OsgiBundleXmlWebApplicationContext) 이것은 스프링 MVC의 XmlApplicationContext와 동일한 역할을 한다. application context는 웹 애플리케이션

Activator

8.6. OSGi-ready libraries and web development

불행히도, 현재 대부분의 웹 개발용 라이브러리들은 OSGi 번들이 아니다. 즉 그 라이브러리들을 OSGi 공간에서 사용하려면 다른 번들에 내장된 채로 사용하는 수밖에 없다. 이 문제를 해결하기 위해서, 스프링 DM 프로젝트는 흔히 사용하는 라이브러리들을 OSGi에서 사용할 수 있는 형태로 바꾼 것들을 Maven 리파지토리에 올려서 제공하고 있다. 8.6.1. Deploying web containers

스프링 DM

8.5. Customizing the standard deployers

디플로이어는 시작시에 필요한 서비스들을 룩업한다. 필수 요소인 경우 디플로이어는 해당 서비스를 참조할 수 있을 때까지 기다리고, 만약 시간이 지나도 참조할 수 없을 때는 예외를 발생시킨다. 만약에 기본 타임아웃 설정이나 서비스 룩업 필터가 정의되어 있지 않으면, 스프링 DM의 reference 엘리먼트를 사용하여 설정할 수 있다. <?xml version=”1.0″

스프링 DM

8.4. web extender 설정하기

core extender와 마찬가지로, 웹 Extender도 OSGi fragment로 설정될 수 있다. 같은 패턴을 사용해서, 웹 extender는 자신의 번들 영역에있는 META-INF/spring 폴더 밑에 있는 XML 파일들을 찾고 그것들을 하나의 application context로 조립하여 자신의 설정파일로 내부적으로 사용한다. 이런 기본 설정을 재정의 하려면, 아래 표에서 적당한 빈 이름을 찾아서, 그것들을 원하는 대로 정의한

Chapter 8

8.3. WAR classpath in OSGi

서블릿 스펙에는 WAR 내부에 특별한 의미를 지니는 위치와 몇가지 규칙들을 정의하고 있다. 이번 섹션에서는 이것들이 OSGi 환경에서 어떻게 처리되는지 살펴볼 것이다. 8.3.1. Static Recsources WAR 번들을 설치할 때, static resource들의 경우, 스프링 DM은 번들 영역에서 가용한 것이 무엇인지만 신경쓴다. 이게 무슨 뜻이냐면 번들 jar 내부에 있는 것들과 거기에

Chapter 8

Chapter 8. Web Support

1.1.0 배포판 부터 도입된 주요 기능은 웹 애플리케이션 지원이고 이로인해 웹 애플리케이션을 OSGi에 배포하기 쉬워졌다. 웹 애플리케이션을 OSGi 위에서 돌리는 가장 큰 문제는 클로스로딩이다. 웹 애플리케이션에는 번들 영역(Bundle Space)라던지 가져온 패키지(Imported pachages)라는 개념이 없다. 각각의 웹 컨테이너들은 자신만의 클래스 로딩 계층구조를 가지고 있는 클래스패스를

Auto re-registering

6.5. 서비스 Exporter와 서비스 Importer의 관계

공개한 서비스가 기능을 수행하기 위해 다른 서비스에 의존할 수 있다. 이때 만약 이들 서비스가 필수 레퍼런스라고 가정하고 해당 서비스들이 없어지고 대체제를 찾지 못해서 unsatisfied 상태가 되면 공개한 서비스는 자동으로 서비스 레지스트리에서 해지가된다. 즉 더이상 클라이언트에서 해당 서비스를 사용할 수 없게 된다. 그러나, 해당 필수 레퍼런스가 다시 가용해지면, 공개한 서비스도 다시

cardinality

6.4. Service importer global defaults

osgi 네임스페이스는 모든 가져올 레퍼런스에 설정한 전역 설정을 선언할 수 있는 두 개의 속성을 제공한다. 따라서, osgi 네임스페이스를 사용할 때 내부에 있는 set, list, reference 엘리먼트는 다음 속성을 사용할 수 있다. default-timeout: 타임아웃을 명시하지 않은 모든 importer에 기본 타임아웃을 설정할 수 있다. <beans xmlns=”http://www.springframework.org/

cyclic reference

6.3. Exporter/Importer listener 베스트 프랙티스

위에서 언급했듯이, 스프링 DM 리스너들은 서비스가 묶이고, 풀리고, 등록되고, 해지될 때를 알기 위한 용도다. 이런 리스너들을 다룰 때 다음의 가이드라인이 도움이 될 수 있을 것이다. 오래 걸리는 작업을 리스너 안에서 실행하지 말아라. 만약 그래야만 한다면, 별도의 쓰레드에서 작업하도록 하라. 리스너들이 동기적으로 처리되기 때문에 가능한 빨리 처리되도록 해야 한다. 해당 리스너

스프링 DM

6.2. Defining references to OSGi services

스프링 DM은 OSGi 서비스 레지스트리를 통해 사용할 수 있는 서비스를 나타내는 빈을 선언하는 기능을 제공한다. 이런 방법으로 통해 OSGi 서비스는 애플리케이션 컴포넌트로 주입될 수 있다. 서비스를 룩업할때는 해당 서비스가 지원하는 서비스 인터페이스 타입과 레지스트리에 등록된 서비스 속성에 부합하는 부가적인 필터 표현식을 사용한다. 몇몇 경우에, 간단하게 애플리케이션에서 하나의 서비스만을 필요로 할

Chapter 6

6.1. Exporting a Spring bean as an OSGi service

service 엘리먼트를 사용해서 OSGi 서비스로 공개할 빈을 설정할 수 있다. 최소한 공개시킬 빈과 서비스 인터페이스를 설정해야 한다. <service ref=”beanToPublish” interface=”com.xyz.MessageService”/> 위의 설정은 beanToPublish라는 빈을 com.xyz.MessageService 인터페이스를 통해서 사용할 수 있도록 서비스로 공개하겠다는 것이다. 그렇게 공개한 서비스는 org.springframework.

Chapter 6

Chapter 6. The Service Registry

OSGi 서비스 레지스트리는 번들이 객체를 공유 레지스트리로 공개할 수 있고 이를 인터페이스를 통해 접근하도록 하는 기반 시설이다. 그렇게 공개된 서비스들은 레지스트리 내부에서 그들과 관련된 서비스 속성들을 가지고 있다. 스프링 DM은 osgi 네임스페이스를 제공하여 스프링이 빈을 OSGi 서비스로 공개할 수 있도록 한다. osgi 네임스페이스는 다른 최상위 네임스페이스 내부에 선언해도 되고, 최상위