2016-06-07 45 views
9

OSGi Deklarasyon Servisleri (DS) belirtimleri, çalışma zamanında kullanılan xml bileşen açıklamasına Bnd gibi araçlar tarafından işlenebilen ek açıklamaları tanımlar. R6 spec 112.8.1 diyor ki:Neden OSGi Deklarasyon Hizmetleri (DS) ek açıklamaları süper sınıflardan miras alınmıyor?

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.

Neden miras izin belirtilen vardır?

cevap

11

Apache Felix projesi tarafından sağlanan DS ek açıklamaları bir kez DS genişletilebilirliğini destekliyordu. Bu uygulamaya dayanarak, resmi OSGi DS ek açıklamalarını belirleyen çalışmanın bir parçası olarak bunu standartlaştırmaya çalıştık.

Sorun şu ki, buradaki iki uygulama sınıfı arasında toplu sınır sorunlarına giriyoruz ve bu bağımlılığı Import-Package veya Require-Capability başlıklarını kullanarak düzgün şekilde ifade edemeyiz. Akla fışkıran

Bazı sorunlar:

  • Genellikle bind ve unbind yöntemleri özel yapmak istiyorum. DS'nin temel sınıftaki özel bind veya unbind yöntemini çağırması iyi olur mu? (Teknik olarak bu iyi yapılabilir, ama kavramsal olarak iyi olabilir mi?)
  • Özel yöntemlerimiz varsa ancak uygulayıcı özel yöntemlerin adını değiştirmeye karar verirse ne olur? Sonuçta onlar özel ve API yüzeyinin bir parçası değildir. Genişletici, uzantı sınıfı tarafından sağlanan tanımlayıcılarda bind//unbind yöntemlerinin listelenmesiyle başarısız olur ve eski yöntem adlarını hala adlandırır.
  • Bunun için özel yöntem adlarını desteklemezsek, bu kuralların korunmasını veya herkese açık olmasını istiyoruz. Böylelikle API'nin parçası olmak için uygulama detaylandırma yöntemlerini zorluyoruz. Çok hoş olmayan IMHO.
  • Not: Paket özel yöntemler iki farklı paketin aynı içeriği farklı içeriklerle paylaşmaması gerektiği için çalışmaz.

Biz tek bir paket içinde böyle miras olması ok-ish olacağını daha sonra geri savundu ancak bu sınırlama, etrafında açıklamalar vb çabaya değer olmazdı sonuca vardık. Bu yüzden özelliği tekrar özellik yol haritasından düşürdük.

+1

"Ayrıca, API'nin bir parçası olmak için uygulama ayrıntılandırma yöntemlerini zorluyoruz. Çok güzel IMHO değil." Bileşen modelimizde (bu, DS gibi% 90'tır) yalnızca bağlama ve ayarlayıcı yöntemleri yalnızca halka açık olabilir. Bileşen sınıfları genellikle dışa aktarılan paketlerde olmadığından, bu işlevler herhangi bir API'nin parçası olmayacaktır. Benim düşünceme göre, method.setAccessible (true) çağrısı, halka açık bağlama yöntemlerini kullanan kişileri zorlamaktan çok daha kötüdür. –

+0

Ancak, bileşen sınıfı bir hizmet nesnesi olarak kullanılabilir, bu nedenle bu ortak bağlama/kaldırma yöntemleri paylaşılan hizmet nesnesinde bulunur. –