Включая дополнительные ресурсы с комплектами OSGi - PullRequest
5 голосов
/ 11 сентября 2009

Я работаю над пакетом OSGi, который реализует службу как оболочку вокруг собственного исполняемого файла. То есть служба запускает исполняемый файл с ProcessBuilder, передает ему некоторые данные и извлекает результат. Мой вопрос о том, как лучше всего упаковать этот комплект. Собственный исполняемый файл включает в себя ряд зависимых файлов данных, которые все должны присутствовать на диске для запуска инструмента. Я нашел множество ссылок по работе с нативными библиотеками DLL в OSGi, но ни одной, в которой не упоминаются файлы, связанные с пакетом, которые должны присутствовать на диске, а не просто извлекаться через путь к классам.

Я думал, что мог бы включить исполняемые и зависимые файлы непосредственно в архив пакета, а затем программно распаковать его в какой-нибудь каталог при запуске пакета. Другой вариант, о котором я могу подумать, это поместить исполняемый файл куда-нибудь и установить системное свойство, которое указывает на него или что-то еще, но я хочу, чтобы конфигурация была минимальной.

Было бы неплохо решение, не относящееся к конкретной реализации OSGi, но если нет, я использую Equinox.

Спасибо!

Ответы [ 2 ]

4 голосов
/ 15 сентября 2009

Должны ли эти дополнительные файлы быть доступными для записи собственным кодом? Если нет, то ничто не мешает вам поместить любые файлы в пакет.

Обычная проблема, с которой вы сталкиваетесь в OSGi, это определение пути к файлу, так как OSGi не предполагает, что файловая система доступна (это не так странно, как кажется, как OSGi запускалась во встроенных устройствах).

Как вы контролируете, где нативный код ищет связанные файлы? Вам нужно пройти по этому пути?

Если вы хотите, чтобы каталог копировал или распаковывал вещи, используйте:

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

Что дает вам рабочий каталог для пакета.

Если вы хотите найти путь к определенному файлу в вашем комплекте, вы можете сделать:

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

Который в этом случае вернет URL файла к /etc/readme.txt в текущем пакете.

Обе части кода предполагают, что они находятся внутри метода start() активатора.

2 голосов
/ 13 сентября 2009

Ваше решение работает, конечно. Но вы должны быть осторожны, чтобы также остановить и удалить любой ресурс, который вы извлекли и запустили во время установки. Это может быть особенно трудно отследить в случае, если исполняемый файл также создает какие-либо рабочие файлы.

Вы должны сделать это, потому что одной из сильных сторон OSGi является управление жизненным циклом, которое позволяет вам также удалять пакеты и сервисы без следа. Для этого фреймворк отслеживает все, что делает пакет. Если вы выполняете исполняемый файл после удаления пакета, который установил и запустил его, соединение теряется, и оно может продолжаться до перезагрузки компьютера (часто не вариант для встроенных систем).

...