JBoss Fuse — Apache Karaf
В этой главе мы обсудим Apache Karaf и почему он называется облегченным OSGi-контейнером, а также его преимуществами и другими важными функциями.
Проблема с JVM
Виртуальная машина JVM или Java не действует как фактическая виртуальная машина. Машина, которая позволит вам на лету останавливать, запускать или перезапускать компоненты, работающие внутри. Иногда может быть разрешено горячее развертывание на уровне класса, но вы не сможете развернуть или отменить развертывание компонента своего приложения на виртуальной машине без перезапуска.
Чтобы решить эту проблему и разрешить модульность в Java-приложении, Fuse использует среду исполнения на основе OSGi, известную как Apache Karaf.
Технология OSGi — это набор спецификаций, которые определяют систему динамических компонентов для Java. Эти спецификации позволяют разработать модель, в которой приложения (динамически) состоят из множества различных (повторно используемых) компонентов.
Преимущества ОСГи
Уменьшенная сложность. Приложение построено как взаимодействующие компоненты, которые скрывают детали реализации друг от друга, что приводит к снижению сложности.
Возможность повторного использования — многие компоненты могут использовать один и тот же компонент, развернутый в контейнере.
Развертывание — OSGi обеспечивает поддержку запуска, остановки и обновления компонентов на лету с помощью API-интерфейсов управления жизненным циклом без перезапуска контейнера.
Уменьшенная сложность. Приложение построено как взаимодействующие компоненты, которые скрывают детали реализации друг от друга, что приводит к снижению сложности.
Возможность повторного использования — многие компоненты могут использовать один и тот же компонент, развернутый в контейнере.
Развертывание — OSGi обеспечивает поддержку запуска, остановки и обновления компонентов на лету с помощью API-интерфейсов управления жизненным циклом без перезапуска контейнера.
Пакеты Vs Особенности
Ниже приведено сравнение комплектов и функций.
Связки
Пакеты эквивалентны OSGi, что jars для JVM. Пакеты — это артефакты, которые можно развернуть в контейнере OSGi. Пакеты — это компоненты, которые работают вместе или независимо друг от друга, образуя приложение.
Будущее за микросервисными архитектурами на Apache Karaf
Мне нравятся микро сервисные архитектуры.
Существует много описаний того, что представляет собой микро-сервис, и множество спецификаций, которые можно описать как следующие шаблону. Короче говоря, я склонен описывать их как наименьшую единицу работы, которую приложение может выполнять в качестве службы для других. Объединяя эти сервисы, мы можем создавать более крупные архитектуры, которые являются модульными, легкими и устойчивыми к изменениям.
С точки зрения современной системной архитектуры возможность предоставления небольшим приложениям полного контроля жизненного цикла является нашей идеальной платформой. Операторам нужно только развернуть нужные им сервисы, обновить их на месте, раскрутить дополнительные экземпляры по мере необходимости. Другой способ описать это как Приложения как Сервис (AaaS). Возьмите определенные небольшие сервисы, такие как маршруты Apache Camel или конечные точки Apache CXF, и поднимайте их вверх и вниз, не разрушая всего приложения. Apache Karaf — платформа для предоставления микро-услуг.
Чтобы упростить микроуслуги, Караф предоставляет множество полезных функций прямо из коробки;
Один из моих любимых шаблонов микросервисов — использование Apache Camel с фабрикой управляемых сервисов (MSF) на Apache Karaf. Camel предоставляет простой DSL для соединения шаблонов корпоративной интеграции, например, для перемещения данных из конечной точки A в конечную точку B. Фабрика управляемых услуг — это модульная модель для конфигураций, основанных на развертывании ваших микро-сервисов — она связывает вместе ConfigAdmin, реестр служб OSGi и код нашего приложения.
Например, пользователь может создать конфигурацию для подключения своего маршрута Camel, используя MSF, для каждой конфигурации будут созданы уникальные PID. Эта модель действительно мощная. Создайте 100 конфигураций, и будут созданы 100 соответствующих микросервисов (верблюжьи маршруты). Однако требуется только один набор кода.
Внедряем OSGI на платформе Karaf
OSGI это не сложно
Я много раз встречал мнение, что OSGI это сложно. И более того, у самого когда-то такое мнение было. Году в 2009, если быть точным. На тот момент мы собирали проекты при помощи Maven Tycho, и деплоили их в Equinox. И это действительно было сложнее, чем разрабатывать и собирать проекты под JavaEE (в тот момент как раз появилась версия EJB 3, на которую мы и переходили). Equinox был намного менее удобен по сравнению с Weblogic, например, а преимущества OSGI тогда мне были не очевидны.
Зато потом, через много лет, мне пришлось на новой работе взяться за проект, который был задуман на основе Apache Camel и Apache Karaf. Это была не моя идея, я давно знал к тому моменту про Camel, и решил почитать про Karaf, даже еще не имея оффера. Почитал один вечер, и понял — вот же оно, простое и готовое, практически то же самое решение некоторых проблем типового JavaEE, аналогичное которому я когда-то делал на коленке при помощи Weblogic WLST, Jython, и Maven Aether.
Итак, допустим вы решили попробовать OSGI на платформе Karaf. С чего начнем?
Если хочется более глубокого понимания
Можно конечно начать с чтения документации. А можно и с Хабра — тут были весьма неплохие статьи, скажем вот совсем уже давно такая. Но в целом karaf получил пока незаслуженно мало внимания. Была еще пара обзоров этот или этот. Вот это упоминание karaf лучше пропустить. Как говорится, не читайте на ночь советских газет… ибо вам там скажут, что karaf это OSGI фреймворк — так вы не верьте. OSGI фреймворки — это Apache Felix или Eclipse Equinox, на базе которых karaf как раз и работает. Можно при этом выбрать любой из них.
Надо заметить, что когда упоминается Jboss Fuse, или Apache ServiceMix, то следует это читать как «Karaf, с предустановленными компонентами», т.е. по сути — тоже самое, только собранное вендором. Я бы не советовал начинать с этого на практике, но почитать вполне можно и обзорные статьи про ServiceMix, например.
Для начала, я попробую тут определить совсем кратко, что из себя представляет OSGI, и для чего можно это применять.
По большому счету OSGI это средство для создания Java-приложений из модулей. Близким аналогом можно считать, например JavaEE, и в какой-то степени OSGI контейнеры могут выполнять JavaEE модули (скажем, web-приложения в виде War), а с другой стороны, многие JavaEE контейнеры содержат OSGI внутри, как средство реализации модульности «для себя». То есть, JavaEE и OSGI — это вещи похожие до совместимости, и удачно взаимодополняющие.
Важная часть любой модульной системы — это определение самого модуля. В случае OSGI модуль называется бандлом (bundle), и является хорошо известным всем разработчикам jar архивом с некоторыми дополнениями (то есть, и тут очень похож например на war или ear). По аналогии с JavaEE бандлы могут экспортировать и импортировать сервисы, являющиеся, по сути, методами классов (то есть, сервис — это интерфейс, или все публичные методы класса).
Метаданные бандла — это знакомый всем META-INF/MANIFEST.MF. Заголовки манифеста OSGI не пересекаются с заголовками для JRE, соответственно, вне OSGI контейнера бандл — это обычный jar. Существенно, что среди метаданных обязательно есть:
Это «координаты» бандла, и тут важен тот факт, что мы можете иметь в одном контейнере две и более одновременно установленных и работающих версии одного бандла.
По аналогии с JavaEE бандлы имеют жизненный цикл, который выглядит так: 
Кроме сервисов бандлы могут импортировать и экспортировать также пакеты (packages, в обычном для java смысле этого термина). Экспортируемые пакеты определены внутри бандла, и делаются доступными другим компонентам, когда бандл устанавливается в систему. Импортируемые определены где-то извне, должны быть кем-то экспортированы, и предоставлены бандлу контейнером, прежде чем он сможет начать работать.
Импорты пакетов могут быть объявлены необязательными, также как и импорты сервисов. И еще довольно существенно, что импорт и экспорт содержат указание на версию (или диапазон версий).
Отличия от JavaEE
Ну хорошо, что они похожи — мы поняли. А чем они отличаются?
На мой взгляд, основное отличие состоит в том, что OSGI дает нам намного большую гибкость. Как только бандл перешел в состояние STARTED, возможности ограничены только вашей фантазией. Скажем, вы можете спокойно создавать потоки (да, да, я знаю про ManagedExecutorService), пулы коннектов к базам, и т.п. Контейнер не берет на себя управление всеми ресурсами в той же мере, что JavaEE.
Вы можете в процессе работы экспортировать новые сервисы. Попробуйте скажем в JavaEE динамически создать новый сервлет? А тут это вполне возможно, более того, сервлетный контейнер karaf, созданный на базе jetty, ваш созданный сервлет тут же обнаружит, и он будет доступен клиентам по определенному URL.
Хотя это и является небольшим упрощением, но если JavaEE приложение в его классическом виде состоит в основном из компонентов:
Отличия karaf от чистого OSGI
Помимо фреймворка karaf включает много чего полезного. В сущности, karaf есть средство для удобного управления OSGI фреймворком — установки туда бандлов (в том числе группами), их конфигурирования, мониторинга, описания ролевой модели и обеспечения безопасности, и тому подобного.
А давайте уже практиковаться?
Ну чтож, начнем сразу с установки. Тут писать особо нечего — идем на сайт karaf.apache.org, скачиваем дистрибутив, распаковываем. Версии karaf отличаются между собой поддержкой разных спецификаций OSGI (4, 5 или 6), и версий Java. Семейство 2.x я не советую, а вот и 3 (если у вас Java 8, как у меня), и 4 вполне можно пользоваться, хотя развивается на сегодня только семейство 4.x (текущая версия 4.2.2, она поддерживает OSGI 6 и Java вплоть до 10).
Karaf вполне нормально работает под Windows и Linux, все что нужно для создания сервиса и автозапуска, имеется. Поддержка MacOS и многих других видов Unix тоже декларируется.
Обычно можно запустить karaf сразу, если вы в интернете. Если нет, то как правило стоит подправить файл конфигурации, указав, где у вас репозиторий(-ии) maven. Обычно это будет корпоративный Nexus, или скажем Artifactory, кому что нравится. Конфигурация karaf располагается в папке etc дистрибутива. Названия файлов конфигурации не слишком очевидны, но в этом случае вам нужен файл org.ops4j.pax.url.mvn.cfg. Формат этого файла — java properties.
Задать репозиторий(и) можно как в самом файле конфигурации, перечислив список URL в настройках, так и просто показав, где лежит ваш settings.xml. Там же караф возьмет расположение вашего proxy, что в интранете как правило знать обязательно.
Kafar нужны несколько портов, это порты HTTP, HTTPS (если web настроен, по умолчанию нет), SSH, RMI, JMX. Если они у вас заняты, или вы хотите запустить на одном хосте несколько копий, то придется изменить и их. Всего этих портов примерно пять.
Порты типа jmx и rmi — вот тут: org.apache.karaf.management.cfg, ssh — org.apache.karaf.shell.cfg, чтобы поменять порты http/https, нужно будет создать (его скорее всего нет) файл etc/org.ops4j.pax.web.cfg, и записать в него значение org.osgi.service.http.port=нужный-вам-порт.
Дальше точно можно запускать, и как правило все заведется. Для промышленного использования очевидно придется внести изменения в файл bin/setenv, или bin/setenv.bat, чтобы например выделить нужный объем памяти, но для начала, чтобы посмотреть, это не нужно.
Можно запустить Karaf сразу с консолью, командой karaf, а можно в фоновом режиме, командой start server, и потом подключиться к нему по SSH. Это вполне стандартный SSH, с поддержкой SCP, и SFTP. Вы можете выполнять команды, и копировать туда-сюда файлы. Вполне можно подключиться любым клиентом, например моим любимым инструментом является Far NetBox. Доступен вход по логину и паролю, а также и по ключам. В потрохах jsch, со всеми вытекающими последствиями.
Рекомендую иметь сразу дополнительное окно консоли, для просмотра логов, которые размещаются в data/log/karaf.log (и другие файлы обычно там же, хотя это настраивается). Логи вам пригодятся, из кратких сообщений в консоли не все бывает понятно.
Я бы посоветовал сразу установить web, и hawtio web-консоль. Эти две вещи позволят вам намного проще ориентироваться в том, что происходит в контейнере, и в значительной степени рулить процессом оттуда (как бонус, вы получите jolokia и возможность мониторинга по http). Установка hawtio выполняется двумя командами из консоли karaf (как описано тут), и увы, на сегодня версия karaf 3.x уже не поддерживается (вам придется поискать более старые версии hawtio).
Из коробки https сразу не будет, для этого нужно предпринять некоторые усилия типа генерации сертификатов и пр. Реализация основана на jetty, поэтому все эти усилия по большей части делаются так же.
Хорошо, оно запустилось, что дальше?
Собственно, а вы чего ожидали? Я же говорил, будет ssh. Tab работает, если что.
Самое время установить какое-нибудь приложение. Приложение для OSGI либо является бандлом (bundle), или состоит из нескольких бандлов. Караф умеет деплоить приложения в нескольких форматах:
Простой jar
Самый простой вариант — это установить обычный jar. Если он у вас лежит в maven репозитории, то для установки достаточно команды:
При этом Karaf понимает, что перед ним обычный jar, и обрабатывает его, создавая на лету бандл-обертку, т.н. wrapper, генерируя манифест по умолчанию, с импортами и экспортами пакетов.
Смысла от установки просто jar как правило немного, так как этот бандл будет пассивным — из него только экспортируются классы, которые будут доступны другим бандлам.
Этот способ применяется для установки компонентов типа Apache Commons Lang, для примера:
А вот и не получилось 🙂 Вот верные координаты:
Как видите, вполне можно установить две версии одного компонента. Update location — это то место, где мы взяли бандл, и откуда его можно при необходимости обновить.
Jar и Spring context
Если внутри вашего jar имеется Spring Context, все становится интереснее. Karaf Deployer автоматически ищет xml-контексты в папке META-INF/spring, и создает их, если успешно нашлись все нужные бандлу внешние пакеты.
Таким образом, все сервисы, которые были внутри контекстов, уже запустятся. Если у вас там были например Camel Spring, то Camel routes запустятся тоже. Это означает, что скажем REST сервис, или сервис, слушающий TCP-порт, вы уже можете запустить. Разумеется, запустить несколько сервисов, слушающих один порт, так просто не выйдет.
Просто Spring XML context
Spring DM
Чем в сущности отличается Spring DM (версия с поддержкой OSGI) от классического Spring? Тем что в классическом случае у вас все бины в контексте создаются на этапе инициализации контекста. Новых появиться не может, старые никуда не денутся. В случае OSGI новые бандлы могут быть установлены, а старые удалены. Среда становится более динамичной, на это нужно как-то реагировать.
Способ реагирования называется сервисами. Сервис — это как правило некий интерфейс, со своими методами, который опубликован каким-либо бандлом. Сервис имеет метаданные, позволяющие его искать и отличать от другого сервиса, реализующего аналогичный интерфейс (от другого DataSource, очевидно). Метаданные — это простой набор свойств key-value.
Так как сервисы могут появляться и пропадать, те, кому они нужны, могут либо подписаться на сервисы при старте, либо слушать события, чтобы узнать об их появлении или пропадании. На уровне Spring DM, в XML, это реализовано как два элемента, service и reference, базовое назначение которых достаточно простое: опубликовать имеющийся бин из контекста как сервис, и подписаться на внешний сервис, опубликовав его в текущий spring-контекст.
Соответственно, при инициализации такого бандла, контейнер найдет для него нужные ему внешние сервисы, и опубликует реализуемые внутри бандла, сделав их доступными извне. Бандл стартует только после того, как ссылки на сервисы будут разрешены.
На самом деле, все немножко сложнее, потому что бандл может пользоваться списком похожих сервисов, и подписаться сразу на список. Т.е. у сервиса, в общем случае, есть такое свойство, как cardinality, принимающее значение 0..N. При этом подписка, где указано 0..1, описывает необязательный сервис, и в этом случае бандл успешно стартует, даже если такого сервиса в системе нет (а вместо ссылки на него получит заглушку).
Замечу, что сервис — это именно любой интерфейс (а можно публиковать и просто классы), поэтому вы вполне можете в качестве сервиса опубликовать java.util.Map с данными.
Кроме всего прочего, service позволяет указать метаданные, а reference — искать сервис по этим метаданным.
Blueprint
Blueprint — это более новая инкарнация Spring DM, которая немного попроще. А именно, если в Spring у вас есть custom XML элементы, то тут их нет, за ненадобностью. Иногда это все же доставляет неудобства, но прямо скажем — нечасто. Если вы не мигрируете проект из Spring, то можно начать сразу с Blueprint.
Суть тут таже самая — это XML, где описаны компоненты, из которых собирается контекст бандла. Для знающих Spring тут нет вообще ничего незнакомого.
Вот пример, как описать DataSource, и экспортировать в виде сервиса:
Теперь в списке бандл в статусе Failed. В чем дело? Очевидно, в том, что ему тоже нужны зависимости, в данном случае — Jar с классами Oracle JDBC, а еще точнее — пакет oracle.jdbc.pool.
Находим нужный jar в репозитории, или скачиваем с сайта Oracle, и устанавливаем, как было описано раньше. Наш DataSource запустился.
Как этим всем воспользоваться? Ссылка на сервис называется в Blueprint reference (где-то, в контексте другого бандла):
Затем данный бин становится, как обычно, зависимостью для других бинов (в примере camel-sql):
Jar и Activator
Канонический способ инициализации бандлов — это класс, реализующий интерфейс Activator. Это типичный интерфейс жизненого цикла, содержащий методы start и stop, которым передается контекст. Внутри них бандл как правило запускает свои потоки, если нужно, начинает слушать порты, подписывается на внешние сервисы при помощи OSGI API, и так далее. Это самый пожалуй сложный, самый базовый, и самый гибкий способ. Мне он за три года не понадобился ни разу.
Настройки и конфигурирование
Понятно, что такая конфигурация DataSource, как приведена в примере, мало кому нужна. Логин, пароль, и прочее, все хардкодится внутри XML. Нужно вынести эти параметры наружу.
Решение достаточно простое, и похожее на то, что применяется в классическом Spring: в определенный момент жизненного цикла контекста происходит подстановка значений свойств из разного рода источников.
На этом мы закончим первую часть. Если будет интерес к этой теме, то продолжение последует. Мы рассмотрим как собирать приложения из бандлов, конфигурировать, мониторить, автоматически развертывать системы на этой платформе.
Русские Блоги
Apache Karaf Research
I. Терминология
(A) OSGi
Разработано на основе Spring DM.
Основные цели использования OSGi: высокомодульная, сильно отделенная, SOA и простота обслуживания.
Наиболее важные особенности OSGi:
ClassLoader является очень важной концепцией в Java, и все знают, что сама JVM не предоставляет очень мощных функций в ClassLoader, таких как разработка модулей очень важна Изоляция модуля Механизм ClassLoader, механизм загрузки версий и т. Д. OSGI использует JVM ClassLoader для формирования модуля для изоляции механизма ClassLoader, а также расширяет различные функции ClassLoader, такие как загрузка по версии и атрибуты фильтрации.
Модели загрузки классов Java и J2EE являются иерархическими и могут быть делегированы только загрузчику классов верхнего уровня, тогда как модель загрузки классов OSGi подобна сети и может передаваться друг другу между пакетами. Это более разумно, потому что зависимости между пакетами не являются иерархическими.
(Б) Караф
Karaf предоставляет множество функций, которые помогают разработчикам и пользователям более гибко развертывать приложения, такие как: горячее развертывание, динамическая настройка, несколько систем обработки журналов, интеграция локальной системы, программируемая консоль расширения, удаленный доступ по SSH, встроенный механизм аутентификации при установке и так далее.
(Три) Связка
Модули в ОСГИ. Это заканчивается как упаковка фляги в контейнере karaf. Один пакет соответствует одному OSGi ClassLoader.
Разделение классов между Пакетами:
(Четыре) модули
Модуль должен иметь следующие 3 характеристики:
Файл Jar языка Java не может полностью реализовать три характеристики модуля, в основном он сталкивается со следующими тремя проблемами:
(5) особенность
То есть набор связок с определенными функциями.
(VI) План
Инфраструктура DI OSGi или стандарт внедрения OSGi, очень похожий на контекст Spring. Сборка приложений в XML. Он используется для обработки сборки объектов POJO, которые могут достигать объектов через связки. Опубликуйте xxService в качестве службы OSGi, используя контекст проекта.
Он имеет две конкретные реализации: Овен Apache, Близнецы Eclipse.
Включены под-теги: bean, service, reference, reference-list и т. Д.
(7) Конфигурация администратора
Контейнер OSGi содержит очень хорошую спецификацию конфигурации: службу Config Admin из спецификации уровня предприятия. Файлы конфигурации могут быть автоматически развернуты в комплекте.
(Восемь) CXF
Инфраструктура CXF представляет собой инфраструктуру разработки приложений SOA, основанную на технологии сервлетов.Для запуска корпоративного приложения, разработанного на основе инфраструктуры приложений CXF, в дополнение к самой платформе CXF также требуется поддержка контейнеров JDK и сервлетов.
CXF наследует лучшие из двух проектов с открытым исходным кодом Celtix и XFire, обеспечиваяJAX-WSКомплексная поддержка, а также поддержка различных типов Binding, DataBinding, Transport и различных форматов. В зависимости от потребностей конкретного проекта вы можете использовать Code First или WSDL First для простой реализации Web-сервисов. Выпуск и использование.
Во-вторых, Караф часто используемые команды
(1) Просмотр состояния запуска всех пакетов
(Два)Посмотреть список всех профилей
(Три) изменить конфигурацию
(D) начать
(5) Стоп
(6) Получить помощь
(7) Просмотр журнала
(Н)Добавить, установить и развернуть функциональные приложения
(Ix)Остановите и удалите приложения
(Х)Посмотреть список всех http сервисов
В-третьих, структура каталогов
В-четвертых, характеристики Карафа
Выдающиеся характеристики Карафа:
Все эти функции делают разработку серверных приложений OSGi почти такой же простой, как и обычные приложения Java.
Пять, создать и установить небольшое приложение OSGi
Пример расположения источника списка задач проекта:
Пример списка задач содержит 4 подпроекта:
Moudle
описание
Сервисные интерфейсы и классы задач
Простая, постоянная реализация, которая обеспечивает TaskService
Сервлет, использующий TaskService для отображения списка задач
Характеристика приложения, поэтому установка в Караф будет легкой
(A) родительский пом и общие настройки проекта
Он также экспортирует все пакеты, которые не содержат строку impl или internal. В нашем случае мы хотим импортировать пакет модели, а не пакет persistence.impl. Благодаря соглашению об именах нам не требуется дополнительная настройка.
(Два) Tasklist-модель
Этот проект содержит модель, в нашем случае это класс Task и интерфейс TaskService. И Tasklist-Persistence и TaskList-UI используют эту модель. Любой пользователь TaskService нуждается только в этой модели. Так что он никогда не будет напрямую связан с нашей текущей реализацией.
(Три) Список задач-постоянство
Очень простая постоянная реализация TaskServiceImpl управляет задачами в простой HashMap. Этот класс использует аннотацию @Singleton, чтобы представить класс в виде bean-компонента.
Аннотация @Service представляет компонент в качестве службы OSGi, а атрибут properties позволяет добавлять атрибуты службы. В нашем примере свойство service.exported.interfaces, которое мы устанавливаем, может использоваться CXF-DOSGi, мы представим его в следующем уроке. Для этого урока вы также можете удалить атрибуты.
blueprint-maven-plugin Обработает вышеприведенный класс и автоматически создаст соответствующий шаблон XML, что избавляет нас от необходимости вручную писать проект XML.
Вы можете найти автоматически созданный проект xml в target / generate-resources.
Автоматически сгенерированный xml:
(4) Tasklist-UI
Проект пользовательского интерфейса содержит небольшой сервлет TaskServlet для отображения списка задач и отдельных задач. Для обработки задач сервлетам нужен TaskService. Мы используем аннотацию @Inject для внедрения TaskService, аннотация @Inject может внедрять любой компонент по типу, а аннотация @Service создает ссылку на проект службы OSGi данного типа.
Весь класс предоставляется в качестве службы OSGi интерфейса java.http.Servlet со специальным атрибутом osgi.http.whiteboard.servlet.pattern = / tasklist. Это вызовет расширение доски pax web, которое будет извлекать службу и экспортировать ее в виде сервлета в относительный URL / список задач.
Фрагмент соответствующего кода:
Автоматически сгенерированный xml:
(5) Tasklist-функции
Последний проект только установил дескриптор функции для репозитория maven, поэтому мы можем легко установить его в Karaf. Дескриптор определяет функцию под названием tasklist и пакеты, которые нужно установить из репозитория maven.
features.xml：
Функция может содержать другие функции, которые должны быть установлены, и связывать пакеты для установки. Связки обычно используют URL-адреса mvn. Это означает, что они загружаются из настроенного репозитория maven или локального репозитория maven в
(Шесть) установки приложений
Команда Караф:
Добавьте дескриптор функции в Karaf, чтобы добавить его к доступным функциям, а затем установите и запустите функцию списка задач. После выполнения этой команды должно быть запущено приложение списка задач.
(VII) Дополнительное резюме
1.pom.xml конфигурация
Родительский и функциональный проект pom.xml указывают:
TaskList-модель, TaskList-постоянство, TaskList-UI спецификации проекта:
2.Maven связанная конфигурация плагина
maven-bundle-plugin Создайте банку с помощью OSGi Manifest.
blueprint-maven-plugin Соответствующий blueprint xml будет автоматически создан для классов с аннотациями blueprint, что избавляет нас от необходимости писать blueprint xml вручную.
Шесть, автоматически развернуть файлы конфигурации в комплекте
Пример расположения исходного кода configadmin проекта:
Давайте сначала кратко рассмотрим спецификацию службы администратора конфигурации. Для нас есть два основных интерфейса, которые можно использовать:
2 способа обработки изменений файла конфигурации:
Пока контекст проекта находится в каталоге OSGI-INF / blueprint и загружается расширитель проекта, контекст проекта просто активируется.
Определяет cm:property-placeholder Элементы. Функция обработки атрибутов-заполнителей файла аналогична, но здесь происходит обработка службы Config Admin. Нам нужно предоставить настроенный PID и стратегию обновления. Для стратегии обновления мы выбираем «перезагрузить». Это означает, что после изменения конфигурации контекст проекта перезагружается или изменяется для отражения. Мы также устанавливаем свойства по умолчанию. Эти значения по умолчанию будут использоваться, когда настроенный PID не может быть найден или свойство не существует.
После того, как мы успешно используем службу Config Admin, остается только развернуть пакет с конфигурацией по умолчанию. Это может быть достигнуто с помощью файлов функций Karaf. Мы определяем функцию с нужными ей пакетами и просто добавляем элемент configfile. Это позволяет Karaf развернуть указанные файлы в каталоге etc места установки Karaf. Если этот файл уже существует, он не будет перезаписан.
Семь других
Следующие разделы Karaf опущены в этом документе:
OSGi в чайнике
(I) Связанные предметы
Проект сборки pentaho-karaf содержит компоненты Karaf и два подмодуля, активаторы проекта pentaho-blueprint и функции pentaho-karaf.
pentaho-karaf-features Содержит файлы функций Pentaho Karaf для Open (стандарт) и EE (предприятие). Каждый файл объектов публикуется с использованием собственного классификатора pentaho-karaf-features- [классификатор].
pentaho-blueprint-activators Содержит определения с компонентами активации OSGI Blueprint Файл. На них ссылаются функции Pentaho и они предназначены для управления функциональной средой. Каждый файл публикуется с использованием собственного классификатора, поэтому артефакт представляет собой pentaho-blueprint-activators- [классификатор]. Добавьте активаторы по мере необходимости для поддержки ваших функций. Однако, если функция включает в себя пакет Pentaho, который может содержать файл активатора, сделайте это вместо добавления здесь.
Основная сборка сначала строит функциональные и активаторные модули.
(Два) PDI-OSGi Bridge
Как следует из названия, «мост» выступает в качестве посредника между PluginRegistry PDI и OSGI. Мост может найти любые классы подключаемых модулей PDI, опубликованные пакетом OSGI в Реестре служб. Поскольку OSGI является динамической системой, которая может устанавливать и удалять пакеты в любое время во время выполнения программы, в PluginRegistry была добавлена новая функция для прослушивания этих событий плагина. Например, пользовательский интерфейс Spoon обновляет шаги по мере их добавления или удаления.
Разработчикам плагинов, которые хотят воспользоваться преимуществами технологии OSGI, не нужно разбираться во внутренних деталях Bridge, им нужно только понимать, как разрабатывать пакеты OSGI и как их развертывать в среде PDI.
(3) почему выбирают OSGi
Фактически, переход на OSGI не заменял одну систему плагинов на другую. Вместо этого он переходит к архитектуре, которая вообще не требует подключаемой системы.
(D) Процесс запуска чайника и процесс загрузки плагина
На следующем рисунке показан скрипт запуска Kettle:
Анализируя скрипт studio.bat, нетрудно найти загрузочный пакет Kettle launcher.jar.
Файл launcher.jar является производным от проекта component / pentaho-common / pentaho-application-launcher, поэтому, если вы хотите начать с компиляции всего проекта Kettle, сначала необходимо скомпилировать компонент, а затем скомпилировать основной.
Для отладки добавьте приведенный выше оператор отладки.
Прочитайте файл launcher.properties, загрузите и запустите метод main класса Spoon в соответствии с его конфигурацией. Содержимое файла выглядит следующим образом:
1. Созданы некоторые файлы журналов или другие каталоги;
2. Запустите пул потоков и зарегистрируйте плагин;
Класс KettleEnVironment содержит все конфигурации Kettle для чтения, а также может регистрировать различные плагины следующим образом:
