2016-06-07 6 views
9

OSGi 선언 서비스 (DS) 사양은 Bnd와 같은 도구로 처리 할 수있는 주석을 런타임에 사용되는 구성 요소 설명 xml로 정의합니다. R6 사양에 112.8.1 말한다 :OSGi 선언적 서비스 (DS) 주석이 수퍼 클래스에서 상속되지 않는 이유는 무엇입니까?

The Component Annotations are not inherited, they can only be used on a given class, annotations on its super class hierarchy or interfaces are not taken into account.

왜 그들이 상속을 허용하지 지정된입니까?

답변

11

Apache Felix 프로젝트에서 제공 한 DS 주석은 한 번 DS 확장 성을 지원합니다. 이 구현을 기반으로 공식 OSGi DS 주석을 구체화하는 작업의 일부로 표준화하려고했습니다.

그러나 문제는 번들 경계를 넘어서 두 구현 클래스간에 문제가 발생한다는 것이며 여기에는 Import-Package 또는 Require-Capability 헤더를 사용하여이 종속성을 올바르게 표현할 수 없다는 점입니다. 마음에 생겨나

일부 문제 :

  • 일반적으로 당신은 bindunbind 방법을 비공개로하고 싶다. DS가 기본 클래스의 개인 bind 또는 unbind 메소드를 호출해도 괜찮습니까? (기술적으로는 잘 수행 할 수 있지만 개념적으로는 괜찮습니까?)
  • 개인 메서드가 있지만 구현자가 개인 메서드 이름을 변경하기로 결정하면 어떻게됩니까? 결국 API는 비공개이며 API 표면의 일부가 아닙니다. bind/unbind 메서드가 확장 클래스에서 제공되는 설명자에 나열되어 있고 이전 메서드 이름의 이름을 계속 지정하므로 Extender가 실패합니다.
  • 개인 메서드 이름을 지원하지 않으면이 bind/unbind 메서드를 보호하거나 공개해야합니다. 따라서 구현 세부 정보 메서드를 강제로 API의 일부가되게합니다. 그리 좋은 IMHO.
  • 참고 : 두 개의 서로 다른 묶음이 동일한 패키지를 다른 내용으로 공유하지 않아야하므로 패키지 개인 메서드가 작동하지 않습니다.

우리는 단 한 묶음으로 그러한 상속을 갖는 것이 좋겠다고 주장했지만이 제한이나 그 주위의 설명 등은 노력할만한 가치가 없다는 결론에 도달했습니다. 그래서 사양 로드맵에서 기능을 다시 떨어 뜨 렸습니다.

+1

"따라서 구현 세부 정보 메서드를 API의 일부가되게합니다. 아주 좋지 않은 IMHO." DS와 같은 90 %의 구성 요소 모델에서는 바인딩 및 설정 메소드 만 공개 될 수 있습니다. 구성 요소 클래스는 일반적으로 내 보낸 패키지에 없기 때문에 이러한 함수는 API에 포함되지 않습니다. 필자는 public method를 사용하는 사람들을 강요하는 것보다 method.setAccessible (true)를 호출하는 것이 훨씬 더 중요하다고 생각한다. –

+0

하지만 구성 요소 클래스는 서비스 객체로 사용할 수 있으므로 이러한 공용 바인딩/바인딩 해제 메서드가 공유 서비스 객체에 있습니다. –