Apache Felix 프로젝트에서 제공 한 DS 주석은 한 번 DS 확장 성을 지원합니다. 이 구현을 기반으로 공식 OSGi DS 주석을 구체화하는 작업의 일부로 표준화하려고했습니다.
그러나 문제는 번들 경계를 넘어서 두 구현 클래스간에 문제가 발생한다는 것이며 여기에는 Import-Package
또는 Require-Capability
헤더를 사용하여이 종속성을 올바르게 표현할 수 없다는 점입니다. 마음에 생겨나
일부 문제 :
- 일반적으로 당신은
bind
및 unbind
방법을 비공개로하고 싶다. DS가 기본 클래스의 개인 bind
또는 unbind
메소드를 호출해도 괜찮습니까? (기술적으로는 잘 수행 할 수 있지만 개념적으로는 괜찮습니까?)
- 개인 메서드가 있지만 구현자가 개인 메서드 이름을 변경하기로 결정하면 어떻게됩니까? 결국 API는 비공개이며 API 표면의 일부가 아닙니다.
bind
/unbind
메서드가 확장 클래스에서 제공되는 설명자에 나열되어 있고 이전 메서드 이름의 이름을 계속 지정하므로 Extender가 실패합니다.
- 개인 메서드 이름을 지원하지 않으면이
bind
/unbind
메서드를 보호하거나 공개해야합니다. 따라서 구현 세부 정보 메서드를 강제로 API의 일부가되게합니다. 그리 좋은 IMHO.
- 참고 : 두 개의 서로 다른 묶음이 동일한 패키지를 다른 내용으로 공유하지 않아야하므로 패키지 개인 메서드가 작동하지 않습니다.
우리는 단 한 묶음으로 그러한 상속을 갖는 것이 좋겠다고 주장했지만이 제한이나 그 주위의 설명 등은 노력할만한 가치가 없다는 결론에 도달했습니다. 그래서 사양 로드맵에서 기능을 다시 떨어 뜨 렸습니다.
"따라서 구현 세부 정보 메서드를 API의 일부가되게합니다. 아주 좋지 않은 IMHO." DS와 같은 90 %의 구성 요소 모델에서는 바인딩 및 설정 메소드 만 공개 될 수 있습니다. 구성 요소 클래스는 일반적으로 내 보낸 패키지에 없기 때문에 이러한 함수는 API에 포함되지 않습니다. 필자는 public method를 사용하는 사람들을 강요하는 것보다 method.setAccessible (true)를 호출하는 것이 훨씬 더 중요하다고 생각한다. –
하지만 구성 요소 클래스는 서비스 객체로 사용할 수 있으므로 이러한 공용 바인딩/바인딩 해제 메서드가 공유 서비스 객체에 있습니다. –