Подтвердить что ты не робот

Как развернуть приложения и зависимости OSGi?

OSGi, по-видимому, имеет отличную выгоду от наличия небольших развертываемых артефактов, не обертывая десятки зависимостей JAR в каталог lib. Однако я не могу найти ничего, что подсказывает мне простой и надежный способ развертывания зависимостей с контейнером. Например, у меня есть приложение, которое использует CXF и несколько подпроектов Spring. Если мне нужно развернуть это приложение на новом сервере Glassfish, что было бы лучшим способом сделать это, гарантируя, что все зависимости будут установлены?

Я использую Maven, и казалось бы, что может быть какой-то способ захвата, который смотрит на каталог META-INF/maven и вытаскивает список зависимостей из pom.xml и отправляет и выбирает необходимые библиотеки (возможно, из локального репо). Есть ли способ сделать это?

Плагин Pax похож на звук, похожий на это, но, похоже, он основан на расширении контейнера Felix? Это не то, что я хочу, я имею дело с уже запущенным удаленным контейнером.

Есть ли какой-нибудь выстрел, такой как инструмент командной строки, в отличие от графического интерфейса?

4b9b3361

Ответ 1

Существует несколько способов развертывания зависимых пакетов в контейнерах OSGi. Вот некоторые из них:

1 Репозиторий пакетов Felix OBR

Сначала вам нужно создать файл индекса XML для ваших доступных пакетов, используя такой инструмент, как bindex. Если вы используете модуль maven-bundle-plugin, он автоматически поддерживает индекс OBR в ~/.m2/repository/repository.xml.

Загрузите индекс с помощью интерфейса командной строки OBR:

> obr:addUrl file:/Users/derek/.m2/repository/repository.xml

Затем попросите OBR развернуть ваш целевой пакет с зависимостями, определенными из индекса OBR:

> obr:deploy com.paremus.posh.sshd
Target resource(s):
-------------------
   Paremus Posh Ssh Daemon (1.0.23.SNAPSHOT)

Required resource(s):
---------------------
   Paremus Command API (1.0.23.SNAPSHOT)

Optional resource(s):
---------------------
   Paremus Config Admin Commands (1.0.23.SNAPSHOT)
   Paremus OSGi & LDAP Types (1.0.23.SNAPSHOT)

2 Apache Karaf

Karaf поддерживает "функции", которые в основном представляют собой списки пакетов, необходимых для обеспечения этой функции:

[email protected]> features:info obr
Description of obr 2.0.0 feature
----------------------------------------------------------------
Feature has no configuration
Feature has no dependencies.
Feature contains followed bundles:
  mvn:org.apache.felix/org.apache.felix.bundlerepository/1.6.4
  mvn:org.apache.karaf.shell/org.apache.karaf.shell.obr/2.0.0
  mvn:org.apache.karaf.features/org.apache.karaf.features.obr/2.0.0

[email protected]> features:install obr

3 Eclipse Virgo

Дева использует планы для определения артефактов, составляющих приложение, и может автоматически предоставлять зависимости приложения, включая пакеты, планы, архивы планов (PAR) и конфигурации из локальных и удаленных репозиториев.

4 Paremus Nimble

Nimble использует OBR (или собственные расширенные) индексы репозитория, чтобы автоматически развернуть все зависимые пакеты, необходимые для активации целевого пакета (и удаляет их, когда целевой пул остановлен). Он также может обнаруживать другие зависимости, например, пакет WAB требует веб-расширителя и автоматически устанавливает его в соответствии с настраиваемой политикой.

Nimble также может быть сконфигурирован для запуска Glassfish, так что его функции доступны для пакетов в контейнере Glassfish.

В приведенном ниже примере также показано, что поддержка регистрации автоматически устанавливается при активации sshd:

$ posh
________________________________________
Welcome to Paremus Nimble!
Type 'help' for help.
[denzil.0]% nim:add --dry-run [email protected]
-- sorted parts to install --
4325   osgi.resolved.bundle/ch.qos.logback.core:0.9.22
-- start dependency loop --
5729   osgi.resolved.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
5727   osgi.active.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
3797   osgi.resolved.bundle/ch.qos.logback.classic:0.9.25.SNAPSHOT
3792   osgi.resolved.bundle/slf4j.api:1.6
-- end dependency loop --
436   osgi.resolved.bundle/org.apache.mina.core:2.0.0.RC1
6533   osgi.resolved.bundle/sshd-core:0.3
398   osgi.resolved.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
396   osgi.active.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT

(отказ от ответственности: я разработчик в Paremus)

5 Apache Felix Gogo

gogo - это новая стандартная командная строка RFC147. Он уже используется в Felix, Karaf, Nimble и скоро будет доступен в Glassfish.

Gogo позволяет запускать любые команды, которые вы можете вводить в интерактивном режиме, как script. Таким образом, вы можете создать список пакетов для установки и преобразования в script или даже захватить установленные пакеты из рабочей конфигурации, чтобы их можно было восстановить заново с чистого старта.

Ответ 2

Если вы создаете приложение OSGi и классическое приложение Java, которое делает то же самое и использует те же библиотеки, вам понадобится точно такой же набор JAR. Большая разница заключается в возможности явно определять ваши зависимости (и, возможно, создавать более подробные JAR для вашего приложения).

Существует только один чистый OSGi-сервер, о котором я знаю (Eclipse Virgo, ранее Spring DM Server). У Glassfish и Websphere есть поддержка OSGi, но я не играл с ними, поэтому не могу сказать много. Я могу сказать, что все они требуют контейнера OSGi и обычно Eclipse Equinox или Apache Felix.

Ваш вопрос, похоже, действительно касается предоставления приложения (разработка того, что нужно развернуть). Я знаю, что для Maven 3.0 они сделали кучу вещей, работающих с инфраструктурой обеспечения Eclipse P2.

Для вашего приложения вы используете EAR или WAR? Для любой из них ваша система сборки должна будет создавать архив со всеми зависимостями, иначе это не сработает. Это немного запутывает, почему у вас есть проблема, потому что люди используют Maven, потому что он выполняет переходное управление зависимостями для своих сборок.

Ответ 3

Существует фундаментальный аспект вашего вопроса, который еще не рассмотрен.

Glassfish - действительно полноценный сервер приложений, как и большинство современных серверов приложений: они предоставляют вам веб-контейнер (где вы будете разворачивать WAR-архивы), контейнер Java EE > (для развертывания EJB в архивах JAR и EAR), а также для интеграции контейнера OSGI. Затем более поздняя версия используется для собственных внутренних механизмов запуска сервера приложений.

В сущности, вы можете настроить таргетинг на три контейнера. Современные средства IDE и сборки предоставляют вам средства для упаковки вашей логики для любого из них. Поэтому возникает вопрос: как мне создать приложение со всеми этими возможностями?

Есть несколько очень важных технических проблем, которые нельзя потерять из виду. (Здесь я фокусируюсь на объективных и фактических соображениях, избегая любых субъективных выборов, философии, стратегии и других контекстно-зависимых соображений, которые действительно могут также сильно повлиять на ваше окончательное решение):

  • Контейнер OSGI не предоставляет вам Неявное или декларативное Управление потоками, Стойкость или Управление транзакциями таких как Web и Java EE. Итак, планируйте анализировать эти проблемы и создавать код для управления вашими потоками и, например, заниматься распространением транзакций по этим потокам. Конечно, OSGi предоставляет все необходимые API для решения этих аспектов, но требует кодирования (где AOP может помочь). С другой стороны, в контейнерах Web и Java EE вы полагаетесь на службы, управляемые контейнерами, и/или используете аннотации EJB, дескрипторы развертывания и управляемые сервером объекты, такие как пулы, просто объявляете, сколько потоков вы хотите параллельно, размеры пулы соединений и атрибуты транзакций. Есть преимущества и недостатки в любом стиле (процедурный в OSGi в сравнении с декларативными или неявными в java-приложениях).
  • OSGI обеспечивает упорядоченный способ загружать ваш код, управлять зависимостями модуля, даже иметь дело с несколькими сосуществующими версиями того же модуля и динамически добавлять/удалять и запускать/останавливать так называемые пакеты (блоки развертывания OSGI), при условии, что действительно ваш пакет содержит логику для обработки потенциальных проблем запуска/остановки, например, надлежащего прерывания всех запущенные потоки на стоп-потоках, которые могли бы "распространяться" через другие зависимые модули. С другой стороны, Java EE и Web-контейнеры будут часто запускать копии зависимого JAR, которые могут привести к более жирным развертываниям, если вы не начнете рассматривать иерархию загрузчика классов приложений и не используйте его для развертывания "разделяемых библиотек" либо как простые POJO JAR, или как Java EE beans, упакованные в JAR. Во всяком случае, в более поздних случаях управление зависимостями развертывания становится проблемой, которую вам придется решать, по крайней мере, во время сборки, используя фреймворки, такие как Maven. Затем во время выполнения вам может понадобиться script запуск/остановка каскадов в зависимости от зависимостей; в противном случае используйте преимущества отдельных расширений сервера приложений, которые устраняют эти проблемы динамического развертывания в контейнерах Web и Java EE (например, Weblogic).
  • Как уже говорилось, OSGI теперь используется большинством серверов приложений для управления собственной стартовой последовательностью . С ростом сложности платформ, умножением API, в число разработчиков команд для сборки единого конечного продукта, а также использование множества сторонних/открытых компонентов, OSGI становится незаменимым сервером-запуском инструмент для обеспечения стабильных выпусков и согласованного набора совместимых версий всех компонентов. Подумайте о Eclipse IDE: с каталогом тысяч плагинов и высоким уровнем новых выпусков эта IDE будет очень хрупкой платформой без OSGI в качестве базы. Современные серверы приложений сталкиваются с одной и той же проблемой.
  • Исходя из вышеизложенных соображений, вы можете быть очень склонны к уровню вашего кода на некоторые средства, которые вы можете использовать в уровне OSGI, что, в свою очередь, предоставляет основные услуги для уровня Java EE bean хостинг бизнес-логики, а затем слой веб-сервлета для взаимодействия всего... но возникают два других вопроса: (a) Как вы объединяете все эти компоненты вместе?OSGI имеет свой собственный механизм репозитория, а развернутый JAR API не будет отображаться другими модулями, если он явно не опубликован в OSGI. Контейнеры Web и Java EE используют совершенно другую технологию репозитория для доступа к интерфейсам каждого другого компонента, а именно JNDI. Опять же, посмотрите на свою конкретную документацию сервера приложений, которая может предоставить средства для адресации Java EE beans из пакетов OSGI и наоборот (Glassfish, например, с V3); но будьте осторожны в отношении управления потоками и областей транзакций. (b) Как вы могли бы избежать вмешательства в последовательность запуска сервера приложений? OSGI имеет тенденцию стать основной системной функцией (при управлении поставщиками) по сравнению с контейнерами Web и Java EE, естественно ориентированными на разместите свой код приложения (под вашим управлением). Модернизация сервера приложений или установка новой версии могут помешать вашим собственным развертываниям OSGI; в результате вы должны будете проверить проблему и организовать сценарии развертывания.

Вопрос богат, и его анализ сложный. Дальнейшее рассмотрение должно учитывать природу приложения для построения. Более того, если вы намерены использовать инфраструктуру разработки, такую ​​как open source Spring и/или Camel, а также специфичные для поставщика компоненты, такие как Oracle Fusion SOA composites, JBoss Switchyard и т.д., Вам придется учитывать многие другие технические ограничения.

В этих вопросах нет ответа "одного размера", и это, по сути, оправдывает текущее множество перекрывающихся технологий.

Когда этот вопрос архитектуры впервые разрешен, вы можете посмотреть, как оптимизировать производительность с помощью подходящего хранилища для управления конфигурацией и развертывания.