Верблюд на JBoss EAP с пользовательскими модулями

Apache Camel — лучшая библиотека интеграции с открытым исходным кодом

Apache Camel — это потрясающая библиотека интеграции с открытым исходным кодом, которую можно использовать в качестве основы ESB или в отдельных приложениях для маршрутизации, преобразования или передачи систем (см .: интеграция нескольких систем). Camel довольно универсален и не заставляет пользователей развертываться в какой-либо конкретный контейнер или технологию JVM. Развертывание в OSGi для гибкой модульности, развертывание в Java EE при использовании стека Java EE или развертывание в Plain Jane Java Main, если вы выполняете легкие развертывания в стиле микросервисов .

Бегущий верблюд по EAP

Недавно у меня было несколько человек, которые задавали вопросы о работе Camel на платформе JBoss Enterprise Application Platform , и я обычно могу сказать: « Хорошо, посмотрите на этот потрясающий блог, который кто-то делал по этому поводу ».

Однако для некоторых людей в крупных компаниях, которые предпочитают курировать использование сторонних библиотек и предпочитают помещать их в глобально доступный путь к классам, упаковка библиотек Camel в их WAR / EAR невозможна.

Вот несколько причин, по которым вы можете захотеть упаковать Camel в EAP в качестве глобальной библиотеки:

• Золотое изображение, список кураторов
• уменьшить раздутые военные развертывания
• может исправлять / обновлять библиотеки в одном месте
• убедитесь, что все приложения используют утвержденные версии

Почему вы НЕ МОЖЕТЕ сделать это:

• Контейнеры Java EE предназначены для мультитенантов
• Не гибкий в вариантах / версиях развертывания
• Возможные проблемы / коллизии пути к классам в зависимости от сторонней библиотеки и транзитивных зависимостей
• Сложно управлять контейнером Java EE

Модули EAP

Независимо от подходов pro / con, как лучше всего поставить Camel в виде модуля на JBoss EAP, чтобы вы могли использовать его из глобального пути к классам? Ответ заключается в использовании собственной модульной системы JBoss EAP, которая называется « Модули ». Мы можем создавать настраиваемые модули для EAP и включать их в наши тощие войны .

Шаг за шагом

Для этого блога я буду использовать ранее созданный пример Camel, развернутый как простой WAR-проект . Однако вместо включения всех банок верблюда в <scope>compile</scope> мы изменим область действия на следующую:

Просто обновите, параметры области maven помогут вам точно контролировать, как ваши зависимости упаковываются и представляются в classpath:

• compile — область по умолчанию, используется для компиляции проекта и упакована в classpath как часть фазы package
• предоставленный — зависимость требуется для времени компиляции, но НЕ упаковывается в артефакт, созданный на этапе сборки package
• время выполнения — зависимость должна находиться в пути к классам при запуске, но не требуется для компиляции и также не упаковывается

Есть пара других, но вы можете проверить документы, чтобы получить полное понимание.

Итак, теперь, когда мы изменили область действия на предоставленную, если мы сделаем сборку, мы сможем проверить нашу WAR и убедиться, что в ней нет банок Camel:

Создайте проект из $ SOURCE_ROOT

Перечислите содержание WAR

Если мы попытаемся развернуть этот проект в EAP, мы наверняка столкнемся с проблемами пути к классам, потому что Camel по умолчанию не включен в путь к классам в EAP. Итак, давайте построим модули сами.

Сначала получите доступ к EAP, загрузив его с портала поддержки Red Hat. (Обратите внимание, что эти шаги могут работать в Wildfly, но я использую EAP для этого обсуждения).

ПРИМЕЧАНИЕ: я буду использовать JBoss EAP 6.2 для этого примера, а также дистрибутив Apache Camel для Red Hat, который поставляется из JBoss Fuse 6.1

Для каждой зависимости в вашем pom, для которой вы хотите создать пользовательский модуль, вам придется повторять эти шаги (обратите внимание, что эти шаги формализованы в базе знаний EAP на портале поддержки Red Hat ):

создайте папку в $ EAP_HOME / modules для хранения вашего нового модуля

создайте папку с именем main в папке модуля, так как именно здесь мы разместим фляги для модуля

Теперь нам нужно выяснить, какие зависимости / файлы должны входить в этот модуль. Если вы используете Maven’s Dependency Plugin, это очень поможет.

ПРИМЕЧАНИЕ: эти шаги являются одноразовыми, однако, возможно, стоит потратить немного времени на автоматизацию этих шагов с помощью скрипта perl / python / bash. для этой демонстрации я не создавал сценарий, но если вы это сделаете, я буду признателен, если вы поделитесь им со всеми, либо сообщите мне об этом в твиттере @christianposta, либо сделайте запрос на извлечение проекта github, связанного с этим блогом .. спасибо !

покажите зависимости для проекта и каждого артефакта:

Это дает вам полный список зависимостей для вашего проекта и каждой из верхних и транзитивных зависимостей. Теперь вы знаете, какие банки должны идти в каждый модуль.

Следующим шагом является загрузка всех этих jar-файлов, чтобы их было легко скопировать в папку модуля:

Скопируйте все зависимости проекта в цель / зависимость

Теперь мы находим, какие jar-файлы отправляются в какие зависимости и создаем модули. Например, глядя выше, мы видим, что у camel-core есть зависимость от com.sun.xml.bind:jaxb-impl:jar:2.2.6 К счастью, это единственная зависимость, и это системная зависимость, которую уже обеспечивает JBoss EAP.

Поэтому все, что нам нужно скопировать в каталог нашего модуля JBoss — это зависимость org.apache.camel:camel-core:jar:2.12.0.redhat-610379 . Но где мы можем получить это? Ну, так как мы использовали зависимость: копия-зависимости, она должна быть просто в вашей папке назначения / зависимости.

Но официальный ответ: баночки с верблюжьими куратами Red Hat поставляются как часть JBoss Fuse .

Поэтому, если вы скачаете дистрибутив для JBoss Fuse и распакуете его, вы должны увидеть папку /extras в этом дистрибутиве. Внутри этого дистрибутива находится архивный файл с именем apache-camel-2.12.0.redhat-610379.zip . Если вы распакуете этот архив и проверите папку /lib , у вас будут все компоненты и файлы Camel, которые поддерживает Red Hat.

Теперь, когда мы знаем, что camel-core — единственный jar-файл, который нам понадобится для модуля camel-core, давайте скопируем его в папку нашего модуля на EAP:

Скопируйте все зависимости и транзитивные зависимости в папку модуля

Создать module.xml

Теперь нам нужно добавить простой xml-дескриптор, чтобы EAP знал, что это допустимый модуль:

А теперь у вас есть EAP-модуль на camel-core ! Если у вас есть зависимости от других модулей, вы можете добавить их, например, так, но это необязательно для модуля Camel-Core (это всего лишь пример того, как это будет выглядеть для других модулей, которые будут нуждаться в этом):

Включите модуль Camel-Core:

Последнее, что нужно сделать, — включить модуль в глобальном пути к классам. Для этого найдите автономный файл конфигурации и добавьте его в раздел <global-modules> «Подсистемы EE»:

Теперь сделайте это для компонента camel-cxf (подсказка, это jar-файлы). ИЛИ, если у вас уже есть некоторые из ваших пользовательских модулей, и вы хотите разделить это на модули многократного использования, разделить их по технологии (spring, cxf, cxf) -транспорт и т. д.):

Обратите внимание, что вы можете разделить различные сторонние зависимости на их собственные модули. (Например, Spring Framework, Camel Spring и т. Д.)

Разверните наш проект в EAP:

Теперь из командной строки перейдите в корень исходного кода для примера проекта и выполните сборку и развертывание:

Куда пойти дальше?

Если у вас возникли проблемы с вышеуказанным, я с радостью помогу или обратитесь в службу поддержки Red Hat для более быстрого ответа!