OSGi Service Platform für PHP

[dr.e.]

Hallo Timothy,

ich würde eine Änderung beim Registrieren des Services einführen. Möchte sich ein Service registrieren, muss er dir (=ServiceRegistry) alle Bundle-Informationen samt Klassen mitteilen. Ist prinzipiell Overhead, schafft dir aber Probleme vom Hals. Damit hast du beim wakeup die Möglichkeit, dir die entsprechenden Bundles (~Klassen) zu laden und danach die Objekte zu deserialisieren.

[timothymarc]

Hey Dr.E.,

das ist natürlich eine andere mögliche Variante. Die ServiceRegistry schreibt die aktuell vorgehaltenen Klassenpfade in eine Datei und liest diese beim Deserialisieren der Klasse ServiceRegistry wieder aus. Das ist eine 3. Möglichkeit, die mir persönlich sogar am elegantesten erscheint.

Die ServiceRegistry bedarf dabei keiner großen Anpassungen, da der BundleContext beim Registrieren natürlich über sämtliche Informationen des aktuellen Bundles (das den Service registriert) verfügt.

Tolle Variante, probiere ich heute Abend aus und poste meine Ergebnisse.

Danke dir.
Timothy

[timothymarc]

Hallo Leute,
hat ein wenig gedauert, nun meine Erfahrungen bzgl. des dynamischen Einladens der Klassenbeschreibungen.

Die Variante von Dr.E. hat nihct ganz so funktioniert, wie ich es erhofft hatte, dies hat mit der von mir propagierten ClassLoader-Architektur zu tun. Ich verwende einen eigens implementierten ClassLoader, der die Abhängigkeiten von Bundles prüft und auflöst, ggf. eine Exception wirft, wenn die Export-und Import-Header das Verwenden einer Klasse nicht zulassen. Dazu verwendet der ClassLoader das Framework-Objekt (das zentrale Objekt, in dem die BundleRegistry, etc. vorgehalten werden). Leider steht zur Zeit des Wakeup dieses Objekt nocht nicht zur Verfügung und wenn während des Wakeups Klassen eingeladen werden, die Klassen aus anderen Bundles per ClassLoader einladen (bei Services bspw. das Interface des Services), dann kann der ClassLoader seine Arbeit nicht vollrichten, da das Framework-Objekt noch nicht vollständig wiederhergestellt ist.

Ich hatte 2 Möglichkeiten zur Wahl. Erstere bedeutete Verzicht auf den ClassLoader (abgelehnt). Zweitere verwendet eine externe Textdatei um alle bisher eingeladenen Service-Klassen mit absolutem Pfad zu speichern. Wenn die Framework-Klasse initialisiert wird, gibt es eine Art Static-Konstruktor (wie in Java), der ausgeführt wird, wenn die Klasse geladen wird (nicht wenn das Objekt instanziiert wird). Dann wird der ClassLoader angestoßen, der nunmehr nicht auf das Framework-Objekt zugreift, sondern auf die Textdatei. Einziger Wermutstropfen: Das 'require_once'-Statement für die Framework-Klasse muss vor dem Start der Session erfolgen. Abgesehen von dieser Einschränkung läuft das ganze jetzt sehr rund und angenehm. Der nächste Schritt wird der ServiceTracker sein.

Timothy<