Java Reference
In-Depth Information
{
System.out.println("app1.start6()");
}
@Stop
public void stop1()
{
System.out.println("app1.stop1()");
}
@Stop
public int stop2()
{
System.out.println("app1.stop2()");
return 0;
}
@Stop
public void stop3()
{
System.out.println("app1.stop3()");
}
}
Bei der Installation der Komponente werden folgende Zeilen ausgegeben:
hello from application1 (version 1)
app1.start1()
app1.start6()
Wie der Ausgabe zu entnehmen ist, werden nach der Erzeugung eines Objekts der Klasse
MainClass die Methoden start1 und start6 aufgerufen. Die Methode start2 wird nicht auf-
gerufen, weil sie nicht annotiert ist, start3 hat nicht den Rückgabetyp void, start4 ist nicht
parameterlos und start5 ist nicht öff entlich.
Entsprechend sollte klar sein, dass nach der Entfernung der Jar- bzw. Zip-Datei Folgendes
zu sehen ist:
app1.stop3()
app1.stop1()
Das Beispiel soll u. a. auch zeigen, dass sowohl beim Starten als auch beim Stoppen mehrere
Methoden aufgerufen werden können. Eine Komponentenentwicklerin sollte dabei aller-
dings nicht von einer festen Reihenfolge ausgehen (z. B. von der Reihenfolge der Methoden
im Quelltext).
Unser prototypisches Komponenten-Framework unterstützt übrigens Hot Deployment.
Wenn man also die Klasse MainClass verä ndert (z. B. die Ausgabe im Konstruktor von „Ver-
sion1“ in „Version 2“ ändert), dann ist beim Neuinstallieren (Redeployment) unserer Bei-
spielkomponente die neue Meldung zu sehen, ohne dass das Framework zwischenzeitlich
neu gestartet wurde. Bitte erinnern Sie sich in diesem Zusammenhang aber an die Ausfüh-
rungen im Kapitel über Hot Deployment: Das Laden der neuen Klassenversion funktioniert
nur dann, wenn sich die Klasse MainClass nicht auch noch im Klassenpfad des Komponen-
ten-Frameworks befi ndet, sondern ausschließlich in der Jar- bzw. Zip-Datei.
