Java Reference
In-Depth Information
Die Überwachung des Installationsverzeichnisses wird von einem Objekt der Klasse Che-
ckedDirectory vorgenommen. Im Konstruktor dieser Klasse muss der Name des Verzeich-
nisses übergeben werden, das überwacht werden soll. Optional kann ein Filter angegeben
werden, für welche Dateien die Überwachung durchgeführt werden soll. In unserem Fall
wird ein Filter verwendet, der auf alle Dateien passt, die die Endung „.jar“ oder „.zip“ haben.
Mit der Methode addDirectoryListener können Listener angemeldet werden, die benach-
richtigt werden, falls sich im Verzeichnis für die auf den Filter passenden Dateien Änderun-
gen ergeben (Erzeugung, Löschung oder Aktualisierung). Objekte der Klasse CheckedDirec-
tory sind nicht selbst aktiv, indem z. B. im Konstruktor ein Thread für die Überwachung
erzeugt wird. Die Überwachung muss durch wiederholtes Aufrufen der Methode check „von
außen“ am Laufen gehalten werden. In der Methode check werden die Änderungen gegen-
über dem letzten Aufruf dieser Methode festgestellt. Für jede neue Datei wird auf allen
angemeldeten Listenern die Methode detectedNewFile aufgerufen, für jede gelöschte Datei
die Methode detectedMissingFile und für jede aktualisierte Datei die Methode detected-
Modifi edFile.
Wie das Installationsverzeichnis durch ein Objekt der Klasse CheckedDirectory im Frame-
work repräsentiert wird, so erfolgt der Zugriff auf das Arbeitsverzeichnis durch ein Objekt
der Klasse WorkSpace. Für jede Komponente wird im Arbeitsverzeichnis ein eigenes Ver-
zeichnis angelegt. Das Arbeitsverzeichnis bekommt denselben Namen wie die Jar- oder Zip-
Datei der Komponente inklusive der Endung. Wenn also die Datei mit dem Namen „applica-
tion1.zip“ in das Installationsverzeichnis gelegt wird, dann wird ein Verzeichnis mit dem
Namen „application1.zip“ im Arbeitsverzeichnis erzeugt, obwohl es sich nicht um eine Zip-
Datei handelt. In dieses neu erzeugte Verzeichnis werden die Inhalte der Jar- bzw. Zip-Datei
entpackt. Dies alles erfolgt durch die Methode createDirectory (die Installationsdatei der
neuen Komponente ist der Parameter dieser Methode). Der Name der Installationsdatei bzw.
der Name des erzeugten Verzeichnisses dient intern als Name für die Komponente. Mit
analyzeManifestFile (String-Parameter für den Namen der Komponente) wird die Manifest-
Datei analysiert. Das Ergebnis wird in Form einer HashMap<String, String> zurückgege-
ben. Für jede Zeile der Form „x: y“ in der Manifest-Datei gibt es einen Eintrag in der Hash-
Map mit „x“ als Schlüssel und „y“ als dazugehörigem Wert. Von der Methode getClassPath
(wieder mit dem Namen der Komponente als Parameter) wird der vollständige Pfadname für
das Verzeichnis „classes“ innerhalb des für eine Komponente angelegten Verzeichnisses im
Arbeitsverzeichnis zurückgegeben, und dies in Form eines URL-Feldes der Länge 1, damit
es direkt für den Konstruktor von URLClassLoader verwendet werden kann. Mit remove-
Directory (Parameter ist wieder der Komponentenname) wird — wie der Name sagt — das
durch createDirectory angelegte Verzeichnis einer Komponente wieder gelöscht.
Da die beiden Klassen CheckedDirectory und WorkSpace im Wesentlichen den Zugriff auf
das Dateisystem bewerkstelligen und wenig mit dem Komponentensystem zu tun haben,
werden wir in diesem Buch nicht näher auf den Code eingehen. Selbstverständlich können
Sie das gesamte Framework von der Web-Seite zum Buch beziehen und sich bei Interesse
diese Klassen genauer anschauen. Auf die beiden anderen Klassen ComponentManager
und DeploymentDirectoryListener gehen wir dagegen ausführlicher ein.
