Wie ein dynamische Eigenschaft Wert in einer OSGi DS-Service-Registrierung

Question

Hier ist ein Stück Code von der Apache CXF Dokumentation erstellen:

CustomMessageBodyReaderWriter provider1 = new CustomMessageBodyReaderWriter(); 
provider.setCustomProperty(true); 

Dictionary properties = new Hashtable(); 
properties.put("org.apache.cxf.rs.provider", provider); 

bundleContext.registerService(
    new String[]{"org.books.BookService"}, new BookServiceImpl(), properties); 

Beachten Sie, dass dieses Stück Aktivator Verfahrens einen OSGi Service registriert, wo eine der Eigenschaftswerte ist ein Objekt, das zur Laufzeit erstellt und konfiguriert wird.

Was nun, wenn ich wollte, dass dies eine CXF dOSGi Komponente ist? Die einzige Möglichkeit, die Dienstregistrierungseigenschaften für DS @Components anzugeben, erfordert, dass der Eigenschaftswert eine Zeichenfolge im Slot "Eigenschaften" in @Component ist. Gibt es eine Möglichkeit, ausführbaren Code zu verwenden?

Answer 1

CXF verwendet die Diensteigenschaften nicht korrekt. Die Spezifikation sagt:

Eigenschaften enthalten Informationen als Schlüssel/Wert-Paare. Der Schlüssel muss ein String-Objekt sein und der Wert sollte ein Typ sein, der von Filter -Objekten erkannt wird (eine Liste finden Sie unter Filter auf Seite 138). Mehrere Werte für den gleichen Schlüssel werden mit Arrays ([]) und Collection-Objekten unterstützt. Die Werte von Eigenschaften sollten auf primitive oder standardmäßige Java-Typen beschränkt sein, um unerwünschte Zwischenbündelabhängigkeiten zu verhindern. ...

Die Serviceeigenschaften sollen Informationen zum Service liefern. Die Eigenschaften sollten nicht zur Teilnahme an der eigentlichen Funktion des Dienstes verwendet werden. Das Ändern der Eigenschaften für die Serviceregistrierung ist eine potenziell kostspielige Operation. Für beispielsweise kann ein Framework die Eigenschaften während der Registrierung in einen Index vorverarbeiten, um spätere Suchvorgänge zu beschleunigen.

Wie auch immer, AFAIK, ist es mit dem aktuellen DS nicht möglich, solche Eigenschaften zu erstellen. Sie können jedoch:

• Die ‚DS Weg‘, eine sofortige Komponente verwenden, die mit einem ComponentFactory
• Verwenden Sie eine sofortige Komponente, und registrieren Sie Ihren Dienst mit dem rohen osgi API
• Wenn Sie die reale Komponente erstellt verwenden felix SCR können Sie eine ExtComponentContext verwenden Ihre Komponenteneigenschaften

Aktualisierung außer Kraft zu setzen:

ein Beispiel für eine Component:

@Component(factory = "bookService") 
public class BookServiceImpl implements BookService { 
    ... 
} 

und eine Komponente dieses Werk mit:

@Component 
public class BookServiceManager { 

    @Reference(target = "(component.factory=bookService)") 
    private ComponentFactory bookServiceFactory; 

    @Activate 
    public void start() { 
    CustomMessageBodyReaderWriter provider1 = new CustomMessageBodyReaderWriter(); 
    provider.setCustomProperty(true); 

    Dictionary properties = new Hashtable(); 
    properties.put("org.apache.cxf.rs.provider", provider); 

    bookServiceFactory.newInstance(properties); 
    } 
} 

Um ehrlich zu sein, mit diesem Anwendungsfall, ich ziehe mit dem rohen OSGi API. Dieser Ansatz kann jedoch nützlich sein, wenn DS Ihre @ Reference in Ihrer ComponentFactory verwalten soll. Wenn die Abhängigkeiten nicht erfüllt sind, werden ComponentFactory und alle ComponentInstance deaktiviert.

Answer 2

Ich arbeite derzeit an einer 2.0-Version von CXF-DOSGi, die es erlaubt, Provder-Instanzen als Intents zu setzen.Sie können dann eine Instanz von CustomMessageBodyReaderWriter unter einem Intent-Namen veröffentlichen und von Ihrem Remote-Dienst aus darauf verweisen, indem Sie die erforderlichen Intents auflisten.