Java Reference
In-Depth Information
Als Lösung für dieses Problem bietet unser prototypisches Komponenten-Framework an, in
der Manifest-Datei durch eine mit „Uses:“ beginnende Zeile anzugeben, dass eine Kompo-
nente K1 eine andere Komponente K2 benutzt. Eine Komponente wird dabei durch den
Namen ihrer Jar- bzw. Zip-Datei identifi ziert. Wir ergänzen also die Manifest-Datei der
CounterClient-Komponente durch eine entsprechende Zeile, wobei davon ausgegangen
wird, dass die CounterService-Komponente in einer Datei mit dem Namen application2.zip
dem Framework zur Verfügung gestellt wurde. Die Manifest-Datei der Komponente Nr. 3 hat
damit folgenden Inhalt:
Main: javacomp.prototype.application3.CounterClient
Uses: application2.zip
Nachdem wir diese Erweiterung durchgeführt haben, funktioniert unsere Komponente wie
gewünscht. Nach der Installation erscheint folgende Ausgabe auf dem Bildschirm:
CounterClient.start
client1: 1
client2: 101
client1: 2
client2: 102
...
Das Laufen der beiden Threads wird durch die sich stä ndig wiederholenden Ausgaben belegt.
Für die erfolgreiche Installation der dritten Beispielkomponente ist es übrigens unerheb-
lich, ob sich die Class-Datei Counter.class immer noch in der Installationsdatei der Kompo-
nente befi ndet (wie im zweiten Versuch) oder wieder gelöscht wurde (wie im ersten Ver-
such). Es wird in jedem Fall die Counter-Klasse der CounterService-Komponente benutzt.
Warum dies so ist und was die „Uses:“-Zeile bewirkt, wird im Abschnitt 6.2 deutlich werden,
in dem wir die Implementierung des Frameworks beschreiben.
Nachdem die Installationsdatei dieser Komponente gelöscht wurde, verstummen die Mel-
dungen, da die Threads in der Stop-Methode angehalten werden. Wird dagegen nur die
Installationsdatei der zweiten Komponente gelöscht, so hat dies keine Auswirkungen auf
die dritte Komponente. Zwar wird die Stop-Methode der zweiten Komponente aufgerufen,
was die Entfernung der beiden Einträge aus der Registratur bewirkt, aber die Referenzen
auf die beiden von der zweiten Komponente erzeugten Objekte werden der dritten Kompo-
nente nicht entzogen. Auch wird die Klasse Counter dadurch nicht „entladen“. Selbst wenn
die zweite Komponente anschließend mit einer neuen Version der Klasse Counter erneut
installiert werden würde, könnte die dritte Komponente auf diese neue Klassenversion
nicht zugreifen. Sollte sich Ihnen die Begründung für diesen Sachverhalt nicht erschließen,
so vertröste ich Sie abermals auf den Abschnitt 6.2; im Zusammenhang mit der Implemen-
tierung des Frameworks sollte es klar werden.
6 .1 . 4 Rückblick
Nachdem wir drei Beispielkomponenten für unser prototypisches Komponentensystem
kennengelernt haben, blicken wir nochmals auf Bild 6.1 zurück, das jetzt noch besser ver-
standen werden sollte. Die vertikalen Pfeile von unten nach oben symbolisieren die Start-
