Java Reference
In-Depth Information
!
Klassenebene: In der Client-Komponente wird die Schnittstelle Counter verwendet. Wenn
die Service-Komponente nicht vorhanden ist, dann ist die Class-Datei für Counter nicht
verfügbar. Folglich scheitert das Starten der Client-Komponente. Aus diesem Grund (und
auch zur Hot-Deployment-Unterstützung) wird die erste Komponente in zwei Komponen-
ten aufgeteilt: Die Komponente 1a enthält das Package javacomp.osgi.bundle0 mit der
Schnittstelle Counter. Die Manifest-Datei dieser Komponente besitzt keine Zeilen mit
Bundle-Activator und Import-Package. Es gibt lediglich eine Export-Package-Zeile, in der
das oben angesprochene Package exportiert wird. Wir gehen im Folgenden davon aus,
dass sich diese Komponente selten ändert und immer installiert bleibt. Die Komponente
1b enthält das Package javacomp.osgi.bundle1 mit den Klassen CounterImpl und Counter-
ServiceActivator, aber ohne die Schnittstelle Counter (hier wird die Schnittstelle aus dem
Package javacomp.osgi.bundle0 benutzt). Entsprechend muss in der Manifest-Datei auch
das Package javacomp.osgi.bundle0 importiert werden. Diese Komponente muss aber ihr
eigenes Package nicht exportieren. Das heißt: Die Export-Package-Zeile in der Manifest-
Datei kann komplett entfernt werden. In der Manifest-Datei der Client-Komponente muss
beim Import javacomp.osgi.bundle1 durch javacomp.osgi.bundle0 ersetzt werden.
!
Objektebene: Die Client-Komponente soll so programmiert werden, dass sie die Service-
Komponente nicht unbedingt beim Starten, sondern eventuell erst später, sobald sie
vorhanden ist, nutzt. Eine Möglichkeit zur Umsetzung besteht darin, dass in der Start-
Methode der nutzenden Komponente ein Thread gestartet wird, der periodisch mit
getServiceReference prü , ob der von ihm zu nutzende Dienst vorhanden ist. Alternativ
kann man sich vom OSGi-Framework benachrichtigen lassen, sobald sich das Dienstange-
bot ändert. Im Folgenden verwenden wir diese zweite Möglichkeit. Dazu benötigt man
eine Klasse, welche die vom OSGi-Framework vorgegebene Schnittstelle ServiceListener
implementiert. Ein Objekt dieser Klasse muss dann mit addServiceListener am Bundle-
Context registriert werden. Wir verwenden in unserem einfachen Beispiel die Activator-
Klasse zur Implementierung der Schnittstelle ServiceListener. Damit kann das Activator-
Objekt sich selbst beim BundleContext als ServiceListener anmelden. Die einzige Methode
serviceChanged der Schnittstelle ServiceListener wird mit einem ServiceEvent-Parameter
aufgerufen, wenn sich im Dienstangebot etwas geändert hat. Über den ServiceEvent-Para-
meter kann man abfragen, ob ein Dienst hinzugefügt, gelöscht oder geändert wurde. In
Listing 9.7 wird nicht nur auf das Hinzufügen, sondern auch auf das Löschen eines Diens-
tes reagiert. Wenn zum Beispiel die genutzte Komponente nicht mehr vorhanden ist, dann
stellt die nutzende Komponente die Benutzung (freiwillig) ein.
Listing 9.7
V e r ä nderte Klasse CounterClientActivator
package javacomp.osgi.bundle3;
import javacomp.osgi.bundle0.*;
import org.osgi.framework.*;
public class CounterClientActivator
implements BundleActivator, ServiceListener
{
private BundleContext context;
private CounterThread thread;
public void start(BundleContext c) throws Exception
