W tym dodatkowe zasoby z pakietami OSGi

Question

Pracuję nad pakietem OSGi, który implementuje usługę jako wrapper wokół natywnego pliku wykonywalnego. Oznacza to, że usługa uruchamia plik wykonywalny z ProcessBuilder, przekazuje mu pewne dane i pobiera wynik. Moje pytanie dotyczy najlepszego sposobu na spakowanie tego pakietu. Natywny plik wykonywalny zawiera wiele zależnych plików danych, które wszystkie muszą znajdować się na dysku, aby narzędzie mogło działać. Znalazłem wiele referencji dotyczących radzenia sobie z natywnymi bibliotekami DLL w OSGi, ale żaden z nich nie odnosi się do plików powiązanych z pakietem, które muszą być obecne na dysku, a nie tylko można je odzyskać za pośrednictwem ścieżki klas.

Wydawało mi się, że mogę dołączyć do plików opcjonalnych i zależnych bezpośrednio w archiwum pakunku, a następnie programowo wyodrębnić do jakiegoś katalogu, gdy pakiet zostanie uruchomiony. Inną opcją, o której myślę, jest umieszczenie pliku wykonywalnego gdzieś i ustawienie właściwości systemu, które wskazuje na to lub coś takiego, ale chcę zachować konfigurację do minimum.

Rozwiązanie, które nie jest specyficzne dla konkretnej implementacji OSGi byłoby miłe, ale jeśli nie, używam Equinox.

Dzięki!

Answer 1

Twoje rozwiązanie działa, oczywiście. Musisz jednak uważać, aby także zatrzymać i usunąć wszystkie zasoby, które zostały wyodrębnione i uruchomione podczas instalacji. Może to być szczególnie trudne do śledzenia na wypadek, gdyby plik wykonywalny również tworzył jakiekolwiek pliki robocze.

Powinieneś to zrobić, ponieważ jednym z atutów OSGi jest zarządzanie cyklem życia, co pozwala ci również usuwać pakiety i usługi bez śladu. W tym celu framework śledzi wszystko, co robi pakiet. Jeśli zachowujesz możliwość uruchamiania programu po usunięciu pakietu, który zainstalował i uruchomił, połączenie zostanie utracone i będzie działało, dopóki komputer nie zostanie ponownie uruchomiony (często nie jest to opcja dla systemów wbudowanych).

Answer 2

Czy te dodatkowe pliki muszą być zapisywane przez natywny kod? Jeśli nie, nic nie stoi na przeszkodzie, aby umieścić pliki, które lubisz w pakiecie.

Zwykły problem w OSGi polega na wypracowaniu ścieżki do pliku, ponieważ OSGi nie zakłada, że ​​system plików jest dostępny (nie jest tak dziwny, jak brzmi, jak OSGi zaczął w urządzeniach wbudowanych).

W jaki sposób kontrolujesz miejsce, w którym kod macierzysty szuka powiązanych plików? Czy musisz podać mu ścieżkę?

Jeśli chcesz skopiować lub katalog rozpakować rzeczy, a następnie użyć:

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

Który daje katalog roboczy dla wiązki.

Jeśli chcesz odnaleźć ścieżkę do konkretnego pliku w wiązce, można zrobić:

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

, który w tym przypadku zwróci plik URL do /etc/readme.txt w obecnym pakiecie.

Obydwa fragmenty kodu zakładają, że znajdują się one w metodzie aktywatora start().