2012-10-24 2 views
6

OSGi Enterprise Release 5 사양에는 osgi.extender 네임 스페이스가 도입되었습니다. 이 네임 스페이스는 Blueprint 나 Declarative Services와 같은 Extender를 가정하는 번들이 프레임 워크에 설치되어 Require-Capability 헤더를 사용하여이 종속성을 모델링 할 수 있습니다.SCR 익스텐더 기능에 대한 요구 사항을 어떻게 선언합니까?

장 135.2 osgi.extender 네임 스페이스은 각 특정 익스텐더의 기능 값이 해당 사양에 지정되어야 함을 알려줍니다. 예는 청사진을 위해 주어진다 :

Provide-Capability: osgi.extender; 
    osgi.extender="osgi.blueprint"; 
    uses:="org.osgi.service.blueprint.container,org.osgi.service.blueprint.reflect" 
    version:Version="1.0" 

그러나 장 112 선언적 서비스 사양는 SCR 구현이 제공하는 기능을 지정하지 않습니다.

Peter Kriens는 blog post on Requirements and Capabilities에 SCR에 대한 기능이 osgi.component임을 나타내는 예를 제공합니다. 나는 결국이 값이 스펙에서 적절하게 정의 될 것이라고 가정합니다. 그러나 그때까지 나는 그것을 사용할 수 없다.

Require-CapabilityProvide-Capability 헤더가 OSGi Core Release 4.3에 도입 되었기 때문에이 메커니즘은 이미 프레임 워크 구현에서 사용할 수 있습니다. SCR 구현을 OBR 저장소에서 해결할 수 있도록 SCR에 대한 요구 사항을 내 번들에 표시하려고합니다.

한 손으로는 사용자 지정 기능을 제공하는 반면, 구현 번들을 필요로하는 빈 번들을 만드는 솔루션을 상상할 수 있습니다. 예 :

Provide-Capability: com.example.extender; extender=scr 
Require-Bundle: org.apache.felix.scr; bundle-version=1.6.0 

선언 서비스를 포함하는 모든 번들은이 기능에 대한 요구 사항을 나타낼 수 있습니다. 예 :

Require-Capability: com.example.extender; filter:="(extender=scr)" 

선언적 서비스가 포함 된 번들을 배포 할 때 SCR이 해결되는지 확인하는 좋은 방법입니까? 다른 방법이 있습니까?

이 문제에 대한 좋은 해결책은 기능을 제공하지 않는 다른 레거시 번들에도 적용 할 수있는 솔루션입니다.

답변

4

사양에서 osgi.extender 네임 스페이스를 정의했지만 구현시 적절한 확장 기능을 제공하도록 다양한 사양 (Blueprint, DS)을 업데이트해야합니다. 바로 지금, 그들은 아마하지 않습니다.

이제는 DS 번들에서 DS 구현 번들을 해결 (또는 설치)하도록 "요구"할 수 있습니다.

OSGi는 Blueprint 및 DS의 다음 업데이트를 위해 진행 중이며 이러한 업데이트는 osgi.extender 기능을 요구합니다.

+0

그래서 제안 된 해결 방법은 실제로 작동하지 않을 것입니까? –

+3

그럴 것입니다. DS 구현 번들에 기능을 추가 한 조각을 만들 수도 있습니다. –

+0

위대한, 당신의 대답에 감사드립니다! –

관련 문제