Nachdem jetzt längere Zeit nix mehr lief, hab ich heute Abend wieder etwas Zeit, mich um das Projekt zu kümmern:

Im letzten Lebenszeichen hatte ich noch die Absicht geäußert, den Code der DS-Implementierung genauer zu untersuchen. Das ist mir aber für den Anfang noch zu mühsam. Stattdessen habe ich zufällig gemerkt, dass das Bundle org.eclipse.equinox.ds den einen Service unter dem Interface org.osgi.service.cm.ConfigurationListener registriert. Ich werde mir daher zuerst das CM etwas genauer ansehen um evtl. noch Informationen zu den Service Komponenten darüber abzufragen.

CM steht für Configuration Managment Admin, dies ist ein besonderer Framework Service, der es erlaubt, Services mit ihren Parametern zu konfigurieren. Das Interface ConfigurationListener kann als Service im System angemeldet werden. Der Services wird dann automatisch bei allen Events des Admins benachrichtigt. Leider lassen sich darüber keine Informationen abfragen Mal sehen, ob DS noch weitere Schnittstellen nach außen hat.

Nach dem Aufsetzen der Entwicklungsumgebung habe ich als Zweites den Source-Code von Equinox via CVS ausgecheckt, um bei meinen ersten Schritten etwas zu spicken.

Der erste Versuch war, ein eigenes Bundle zu schreiben, welches alle Funktionalitäten ohne Kenntnis der Interna des DS-Bundles implementiert. Das „services“ Kommando der Equinox hab ich deshalb auch als erstes angeschaut, da hier schon Name und ID der Service-Component angezeigt werden. Allerdings geschieht dies nicht, weil es Zugriff auf die Component hat, sondern weil Name und ID als Service-Properties dem Service hinzugefügt werden. Das Kommando zeigt einfach nur diese Properties an.

Aufbauend darauf habe ich schon einmal ein Bundle geschrieben, dass anhand dieser Properties die vorhandenen Service-Components mit Name und ID auflistet.

Auf der Suche im Internet bin ich dann noch auf die DS-Implementierung von Apache Felix gestoßen. Diese scheint schon etwas weiter entwickelt zu sein, hier gibt es das Kommando „scr“, welches Service-Components auflisten, anzeigen, starten und beenden kann. Dieser Link führt zu einer Beschreibung.

Für eine weitere Betrachtung der DS unter Equinox werde ich nicht umhin kommen, auch tiefer in den Sourcecode zu schauen. Auch wird es wohl darauf hinaus laufen, dass ich das Bundle org.eclipse.equinox.ds noch anpassen muss.

Wie schon angedroht, werde ich jetzt mit einem kleinen Projekt zu Hause beginnen. Erstes Ziel soll die Erstellung eines Service-Component Trackers sein, einer Anwendung, welche die Service-Components einer OSGi-Umgebung suchen, anzeigen sowie verändern kann. Folgende Funktionen sollen bereitgestellt werden:

• Service-Components anzeigen: dies soll ähnlich zu dem services-Kommando geschehen. Auch soll es möglich sein, Service-Components mittels Wildcards zu suchen.
• Service-Components starten und beenden: Mittels der Komponenten-ID oder dem -Namen soll der Status von Service-Components auf enabled oder disabled verändert werden können.
• Neue Instanzen von Service-Component-Factories erzeugen und beenden: Bei den Service-Component-Factories soll es möglich sein, mittels eines Kommandozeilenbefehls neue Instanzen zu erzeugen und vorhandene Instanzen wieder zu löschen.

Bei der Implementierung sollte im ersten Schritt eine Service-Component erstellt werden, welche den Zugriff auf die Service-Components herstellt. Zusätzlich ist eine Service-Component für die oben genannten Funktionen notwendig, falls jede Funktion vom Umfang zu groß wird, ist auch eine Aufteilung auf 3 einzelne Service-Components möglich.

Es werden folgende Technologien benötigt:

• OSGi: Die eigentliche Runtime, bereitgestellt durch Eclipse Equinox
• org.osgi.service.components: Die Implementierung der Service-Components, bereitgestellt durch das Bundle org.eclipse.equinox.ds
• org.eclipse.equinox.log zur Nutzung von Logging während der Entwicklung

Da die Service-Components ein reines OSGi Feature sind, kann auf die Nutzung von RCP verzichtet werden, zumindest solange das Projekt sich auf die Kommandozeile beschränkt.

Als Zeitrahmen würde ich maximal 5 Wochen veranschlagen, je nach freier Zeit und nach Schwierigkeiten bei der Implementierung.

So, und jetzt gehts als Erstes ans Einrichten von Eclipse und einem neuen SVN-Repository.

Hier noch eine kleine Info-Sammlung über Declarative Services (DS) in Fragment Bundles (FB). Alle folgenden Infos beziehen sich auf Eclipse Equinox.

Grundsätzlich gilt: es funktioniert. Allerdings unterliegen DS in FB einigen Besonderheiten:

• XML-Files: Die Service-Komponenten-Beschreibungen können beliebig im Host- oder Fragment-Bundle abgelegt werden. Sie können beliebige Klassen aus beiden Bundles reservieren, da ja beide zur Laufzeit zu einem Bundle verschmolzen werden und sich den Classpath teilen.
• Manifest-Files: Jetzt die schlechte Nachricht, das Element Service-Component
darf nur in der Manifest-File des Host-Bundles eingetragen sein, im Manifest des Fragments wird es ignoriert. Es können jedoch mehrere Service-Component-Elemente im Host-Manifest „auf Vorrat“ eingetragen werden, wenn man sich dann an den Fehlermeldungen im Log nicht stört.
• Konflikte: Was passiert, wenn man mehrere gleichnamige XML-Files in Host- und Fragmenten liegen, diese aber unterschiedliche Service-Komponenten deklarieren?? Es steht wahrscheinlich in keiner Spezifkation, was dann geschieht, bei Eclipse Equinox passiert folgendes: Es werden zwei eigenständige Service-Komponenten erstellt und gestartet. Es findet keine Überschreibung oder Überlagerung statt. Man kann sich das so vorstellen, als lägen beide in unterschiedlichen Files im gleichen Bundle. Falls es vorkommt, dass die Service-Komponenten einen identischen Namen haben (too much copy-paste ),  so kollidieren sie so wie im Normalfall.

Nachdem ich auf der Arbeit ständig damit hantiere, gibts jetzt ne kleine Anleitung bzw. Checkliste für Declarative Services (DS) unter OSGI. Was sind DS? Ganz einfach: Normalerweise müsste man per Hand codieren, welche Services ein OSGI-Bundle anbietet und welche es verwendet. Dadurch entstehen einige Probleme, vor allem muss man sich selbst darum kümmern, was passieren soll, wenn ein Service mal nicht zur Verfügung steht oder sich im Betrieb verabschiedet. Außerdem ist es für einen Außenstehenden oft schwer einzusehen, welche Services das Bundle verwendet bzw. anbietet. Die Ressourcenbelegung ist auch ein Punkt, da die Services sich sofort bei Bundle-Start registrieren und nicht erst, wenn sie benötigt werden. Hier kommen die Declarativen Services ins Spiel. Mit ihnen kann man Services per XML-Datei konfigurieren.

Die folgende Checkliste wurde unter der Verwendung von Eclipse Equinox erstellt.

Checkliste: Was wird für Declarative Services benötigt?

• Die Implementierung der Deklarative Services erfolgt durch das Bundle org.eclipse.equinox.ds. Dieses Bundle muss immer mit geladen werden, bevor die DS verwendet werden können.
• Zusätzlich wird die Klasse ComponentContext aus dem Bundle org.osgi.service.component benötigt.
• Die eigentliche Implementierung des DS erfolgt als sog. Service Component, also einer Klasse, welche den Service (besser gesagt: das Service Interface) implementiert. Im Gegensatz zu einem Activator wird diese nicht abgeleitet oder implementiert eine Interface. Sie muss trotzdem folgende zwei Funktionen enthalten, damit die ServiceComponent funktioniert. Diese Funktionieren ähnlich wie die start und stop Methoden des Bundle-Activators.
  • protected void activate(Component context){…}
  • protected void deactivate(Component context){…}
    
• Eine Konfigurationsdatei in XML: Diese Datei wird üblicherweise in einem Verzeichnis namens OSGI-INF abgelegt, der Dateiname ist beliebig. Die XML-Datei selbst folgt dem hier zu findenden Schema. Wichtig ist hier, dass alle Inhalte der XML-Datei, also Tags, Attribute aber Paket- und Klassennamen richtig geschrieben sind, ansonsten kann die Service Component nicht aktiviert werden.

• Änderung im Manifest-File des Bundles: Füge eine neue Zeile hinzu, der Inhalt ist Service-Component: OSGI-INF/service.xml (wenn die XML-Datei service.xml heißt)

Beispiel:

Hierzu ein kleines Beispiel: Eine ServiceComponent soll erstellt werden, die einen Service mit dem Interface MyServiceInterface bereitstellt. Sie soll außerdem eine Liste von Services des Interface OtherService beinhalten. Dazu bindet sie diesen Service (der auch über eine Service Component realisiert werden muss) mit der cardinality=“1..n“, so dass mindestens ein OtherService vorhanden sein muss, um die Service Component zu aktivieren. Die einzige Funktion in MyServiceInterface gibt die Anzahl der angebundenen OtherService zurück.

Service Interface:

package org.example.ds
import ...
public interface MyServiceInterface {
    int getCount();
}

Implementierungs-Klasse:

package org.example.ds.internal
import ...
public class MyServiceImplementation implements MyServiceInterface {

    private ComponentContext context;
    private List<OtherService> servicelist = new Vector<OtherService>(0);

    protected void activate(ComponentContext context){
        this.context = context;
    }

    protected void deactivate(ComponentContext context){
        this.context = null;
    }

    protected void bindOtherService(OtherService otherservice){
        this.servicelist.add(otherservice)
    }

    protected void unbindOtherService(OtherService otherservice){
        this.servicelist.remove(otherservice)
    }

    public int getCount(){
        return this.servicelist.size();
    }
}

Die XML-Datei im OSGI-INF Ordner:

<?xml version="1.0" encoding="UTF-8"?>
<component name="myServiceComponent">
    <implementation class="org.example.ds.MyServiceImplementation"/>
    <service>
        <provide interface="org.example.ds.MyServiceInterface"/>
    </service>
    <reference
        name="otherservice"
        interface="org.example.ds.OtherService"
        bind="bindOtherService"
        unbind="unbindOtherService"
        cardinality="1..n"
        policy="static"
    />
</component>

Fehlersuche:

• Das Bundle startet, aber die Service Component nicht. Dies kann viele Ursachen haben:
  • Schreibfehler in der Manifest- oder XML-File. Am besten nochmal nachschauen, ob alle Paket- und Klassennamen stimmen.
  • Eine geforderte Referenz ist nicht verfügbar. Untersuche alle Referenzen, ob deren Service Components vollständig gestartet wurden.
  • Eintrag in der Manifest-File fehlt oder ist ungültig. Mein absoluter Lieblings-Fehler
  • Funktionen wie activate/deactivate bzw. bind/unbind fehlen oder sind ungültig.
• NullPointerException oder andere krude Exceptions werden geworfen: Dies kann auftreten, wenn Klassenmember in der activate-Funtion belegt werden. Diese wird nämlich erst dann aufgerufen, wenn alle Referenzen erfüllt sind, also erst nach den bind-Funktionen. Wenn in bind schon auf das Member zugegriffen wird, ist es dann noch null und die NullPointerException wird geworfen.
• Hilfe, ich sehe nicht ob sich irgendwas tut!!!
  • Der Status einer Service Component kann leider nicht einfach über den status-Befehl abgefragt werden, da Service Components ein relativ neues Konzept sind.
  • Eine Service Component meldet ihre Services sofort an der Service Registry an, der Befehl services gibt also keinerlei Aufschluss über den Status ser Service Component.
  • Am besten kann der Lebenszyklus über den Log-Service verfolgt werden, den Equinox mitliefert. Er kann über das Bundle org.eclipse.equinox.log angebunden werden