Как определяется начальный уровень пучка OSGi?
Я использую Apache felix и хотел бы сохранить начальный уровень в рамках исполнения оболочки. Я не ожидаю необходимости очень часто менять начальный уровень пакета очень часто, поскольку запись в Manifest.MF кажется наиболее разумной. Я должен быть org.osgi.framework.startlevel, но не видел практического примера.
Я также использую maven с плагином maven-bundle, если есть элегантный способ включить начальный уровень в POM, который был бы блестящим.
Связки не определяют свой начальный уровень во время сборки; администратор или агент, который устанавливает пакет в фреймворк, определяет его.
Основная структура определяет интерфейс начального уровня в разделе 8. Цитата:
API уровня запуска предоставляет следующие функции:
Управляет начальным начальным уровнем OSGi Framework.
Используется для изменения активного начального уровня Framework.
Может использоваться для назначения определенного начального уровня для пакета.
Можно установить начальный начальный уровень для вновь установленных пакетов.
Последние два относятся к вашему запросу здесь. Раздел 8.3.4. Изменение уровня начала пула - означает, что структура сохранит присвоенный начальный уровень настойчиво.
Если вы используете Apache Felix, вы можете установить пакеты и назначить их начальный уровень, явно или разрешить им наследовать начальный уровень по умолчанию для установленных пакетов:
felix.fileinstall.start.level, хотя оно не входит в комплект)felix.auto.install.<n> свойство)bundlelevel)Также см. felix.startlevel.bundle свойство, которое управляет пакетами, установленными с помощью других средств, кроме указанных выше.
Что касается установки свойства манифеста (например, с Maven во время сборки), раньше это был способ сделать это в Equinox &mdash, теперь он устарел - mdash, но нет стандартных средств для пакета, чтобы указать инфраструктуре, что ее правильный начальный уровень должен быть.
X
Я думаю, что есть более простой способ сделать то, о чем вы говорите. В настоящее время вы используете реализацию Felix OSGi напрямую, что очень эффективно. Однако, если вы хотите получить подробный контроль над развертыванием пакетов, который встроен в контейнер OSGi под названием Karaf. Подумайте о Karaf как о машине, чей двигатель может быть либо Felix, либо Equinox. Это что-то, что распространяется на реализацию реализаций OSGi и предлагает дополнительную функциональность. Например, Karaf предоставляет механизм Provisioning. Развертывание нескольких пакетов называется Provisioning. Поскольку Provisioning не является частью спецификации OSGi, различные контейнеры OSGi реализуют инициализацию по-разному. В Karaf мы делаем это через что-то, называемое файлом features.xml.
В файле features.xml вы идентифицируете определенный набор пакетов, которые хотите развернуть вместе. Затем вы назовете эту группу. В этом файле вы также можете указать конкретный порядок начала, в котором вы хотели бы, чтобы Karaf развертывал пакеты.
Слово о стартовых ордерах OSGi. Пучок не может быть запущен до тех пор, пока не произойдет все обязательные проводки. Это означает, что вы можете определить начальный порядок, но OSGi принимает это как руководство, а не обязательное. Например, если у вас есть пакет A, который требует импорта пакета b "foo", вы можете сказать, что контейнер запускает A до B, который вы хотите. Но он не будет уважать этот порядок, потому что на самом деле B нужно начать, чтобы начать А. Его нормально, хотя, контейнер знает (обычно), какой порядок запускать пакеты.
Втирает использование необязательного и обязательного импорта в комплекте. Если ваш пакет импортирует b.foo, но этот импорт является необязательным, контейнер будет уважать начальный порядок пучка (A, затем B). Но будьте осторожны, если A на самом деле нужно импортировать b.foo, но вы пометили его как необязательный, A начнется без подключения к b.foo, и A будет генерировать исключение ClassNotFoundException. Эта неприятная ошибка может возникать при использовании различных пакетов в Spring.
Чтобы сделать вашу жизнь легкой, Spring делает большую часть своего импорта "опциональной". Если данный пакет Spring действительно должен разрешить зависимость перед работой и что импорт отмечен как необязательный, ваши пакеты будут развертываться спарически. Конечно, исправление для этого заключается в создании фрагмента пакета, который изменяет импорт пакетов в "обязательный", но это действительно выходит за рамки вашего вопроса.
Надеюсь, это прояснит вам все.
bundle.adapt(BundleStartLevel.class).setStartLevel(startlevel);