Zusätzliche Ressourcen mit OSGi-Bundles einbinden

Question

Ich arbeite an einem OSGi-Bundle, das einen Dienst als Wrapper um eine native ausführbare Datei implementiert. Das heißt, der Dienst führt die ausführbare Datei mit ProcessBuilder aus, gibt ihm einige Daten und ruft das Ergebnis ab. Meine Frage ist über die beste Möglichkeit, dieses Bündel zu verpacken. Die native ausführbare Datei enthält eine Anzahl abhängiger Datendateien, die alle auf dem Datenträger vorhanden sein müssen, damit das Tool ausgeführt werden kann. Ich habe viele Hinweise zum Umgang mit nativen DLLs in OSGi gefunden, aber keine, die Dateien adressieren, die zu einem Bundle gehören, das auf dem Datenträger vorhanden sein muss und nicht nur durch den Klassenpfad abrufbar ist.

Ich dachte, dass ich die executable und abhängigen Dateien direkt in das Bundle-Archiv aufnehmen und dann programmatisch in ein Verzeichnis extrahieren könnte, wenn das Bundle gestartet wird. Die andere Option, die ich mir vorstellen kann, ist, die ausführbare Datei irgendwo zu platzieren und eine Systemeigenschaft zu setzen, die auf sie oder etwas verweist, aber ich möchte die Konfiguration auf ein Minimum beschränken.

Eine Lösung, die nicht spezifisch für eine bestimmte OSGi-Implementierung ist, wäre nett, aber wenn nicht, verwende ich Equinox.

Danke!

Answer 1

Ihre Lösung funktioniert natürlich. Sie müssen jedoch darauf achten, auch alle Ressourcen zu stoppen und zu entfernen, die Sie während der Installation extrahiert und gestartet haben. Dies könnte besonders schwierig zu verfolgen sein, wenn eine ausführbare Datei auch irgendeine Art funktionierender Dateien erstellt.

Sie sollten dies tun, weil eine der Stärken von OSGi das Lifecycle Management ist, mit dem Sie auch Pakete und Services spurlos entfernen können. Dazu verfolgt das Framework alles, was ein Bündel tut. Wenn Sie nach dem Entfernen des Bundles, das es installiert und gestartet hat, eine Executable ausführen, ist die Verbindung unterbrochen, und sie kann weiter ausgeführt werden, bis der Computer neu gestartet wird (bei eingebetteten Systemen oft keine Option).

Answer 2

Müssen diese zusätzlichen Dateien mit dem systemeigenen Code beschreibbar sein? Wenn nicht, gibt es nichts, was Sie davon abhält, Dateien, die Sie mögen, in ein Paket zu stecken.

Das übliche Problem, das Sie in OSGi haben, ist den Pfad zur Datei auszuarbeiten, da OSGi nicht davon ausgeht, dass ein Dateisystem verfügbar ist (es ist nicht so seltsam wie es klingt, als OSGi in eingebetteten Geräten begann).

Wie steuern Sie, wo der systemeigene Code nach den zugehörigen Dateien sucht? Müssen Sie ihm einen Weg geben?

Wenn Sie ein Verzeichnis wollen Sachen kopieren oder entpacken, dann verwenden:

org.eclipse.core.runtime.Platform.getStateLocation() 

dem Sie das Arbeitsverzeichnis für das Bündel gibt.

Wenn Sie den Pfad für eine bestimmte Datei in Ihrem Bündel finden möchten, können Sie tun:

org.eclipse.core.runtime.FileLocator.toFileURL((context.getBundle().getEntry("/etc/readme.txt"))) 

, die in diesem Fall wird eine Datei URL zum /etc/readme.txt im aktuellen Bündel zurück.

Beide Codeteile gehen davon aus, dass sie sich innerhalb der start() Methode des Aktivators befinden.