Первое знакомство с Red Hat JBoss Fuse

Здравствуйте, коллеги.

Сегодня проводил семинар в Accenture Riga Delivery Center по поводу интересной для меня темы Red Hat JBoss Fuse и решил поделиться своими впечатлениями от этой сервисной шины с вами.

Что такое Red Hat JBoss Fuse? По сути это - среда исполнения для реализации набора паттернов интеграции корпоративных приложений (Enterprise Application Integration Patterns (EIP)) Apache Camel.

Данная среда исполнения поставляется в двух вариантах:

• Apache Karaf - готовая к промышленному использованию реализация стандарта OSGi.
  
  
• Red Hat JBoss Enterprise Application Platform - широко известный Java EE-совместимый сервер приложений с коммерческой поддержкой. К сожалению, Red Hat JBoss Fuse устанавливается только на версию 6.4.0 данного сервера приложений, реализующую лишь стандарт Java EE 6, что приводит к проблемам, некоторые из которых описаны ниже.
  

Механизм ограничений на импорты в Eclipse (Access restriction)

Возможно каждый использующий интегрированную среду разработки Eclipse SDK программист сталкивался с подобной ошибкой: Access restriction: The type JLabel is not accessible due to restriction on required library ..\lib\rt.jar

Механизм ограничений на импортируемые классы появился в Eclipse 3.1 и предназначен в первую очередь для разработчиков плагинов, чтобы бить по рукам за доступ ко внутренним API бандлов. Выглядят данные ограничения следующим образом: в (Project) Properties -> Java Build Path -> Libraries -> JRE определены Access Rules для всей JRE или для каждого jar'а внутри данной JRE. По-умолчанию проект создается в среде исполнения (Execution Environment) JavaSE-1.7, которая накладывает ограничения на rt.jar - запрещены все пакеты javax.* кроме 160+ базовых.

Проблема с классами из Swing может возникнуть, если в результате экспериментов разработчик выставит в качестве Execution Environment или JRE-1.1, или вообще какие-то CDC/OSGi-Minimum. При работе с классами Eclipse проблема может возникнуть при попытке использования неразрешенных классов.

Можно отказаться от использования Execution Environment и при создании проекта выбирать опции JRE - Use a project specific JRE или Use default JRE. Все советы вида "удалите из проекта System Library, а потом руками добавьте ее" основаны именно на этом - замените Execution Environment на просто JDK.

При необходимости можно изменить поведение Eclipse, для этого есть два пути:

Windows -> Preferences -> Java -> Compiler -> Errors/Warnings

(Project) Properties -> Java Compiler -> Errors/Warnings

Нужно поменять значение у опции Forbidden References на Warning (по-умолчанию - Error), но делать это нужно в самом крайнем случае.

Для получения более подробной информации можно посмотреть данный пост или этот вопрос на Stack Overflow.

Понравилось сообщение - подпишитесь на блог

Eclipse Indigo: Пять причин обратить внимание на ECF

Поздравляю всех читателей с официальным выходом Eclipse 3.7 Indigo. Здесь камрад James Sugrue написал статью на JavaLobby - Eclipse Indigo Highlights: Five Reasons to Check Out ECF. Позволю себе перевести ее на русский язык.

Eclipse Communication Framework [1] - традиционный участник Eclipse release trains (перевод "поездов релизов Eclipse" мне как-то не очень нравится, однако термин "поезд" применительно к релизу ПО меня забавляет уже третий год) - непрерывно добавляет новое в свой впечатляющий список возможностей. Данный год не стал исключением - в релиз Eclipse Indigo включен ECF 3.5. В данной статье я сосредоточусь на пяти ключевых возможностях новой версии.

ECF: Выпущен ECF 3.5

Через четыре месяца разработки выпущена новая версия Eclipse Communication Framework - ECF 3.5.

Из основных нововведений:

1. Поддержка спецификации OSGi Remote Services Admin - части 122 т.н. OSGi Enterprise Specification. Данная спецификация определяет сервис управляющих агентов для администрирования удаленных сервисов. Теперь архитектура ECF позволяет гибко и на лету заменять OSGi-совместимые модули, обеспечивающие взаимодействие и обнаружение сервисов. Под модулями взаимодействия подразумеваются различные протоколы, поддерживаемые ECF: R-OSGi, ECF Server, JMS, REST, SOAP, XMPP и т.д. Под модулями обнаружения сервисов подразумеваются: SLP, ZeroConf, ZooDiscovery и т.д.

Так же добавлена поддержка Endpoint Description Extender Format (EDEF) - части 122.8 Enterprise Specification. Данная реализация пришла на замену используемому ранее модулю основанного на файлах обнаружения сервисов.

2. XML-RPC провайдер. Данный провайдер реализует ECF Remote Services API, позволяя обращаться к XML-RPC серверам как удаленным OSGi-сервисам. Поддерживается вызов сервисов через прокси, а также асинхронное взаимодействие. Скромно замечу, что данный провайдер реализован вашим покорным слугой.

3. ECF4Felix - позволяет использовать все возможности ECF на OSGi R4-совместимой платформе Apache Felix.

4. Maven-репозиторий, доступный по-адресу.

С полным списком нововведений можно ознакомиться в разделе New and Noteworthy. Для установки через механизм p2 существует update site: http://download.eclipse.org/rt/ecf/3.5/site.p2.

Напомню, что исходники фреймворка теперь располагаются в Git-репозитории.

Помимо официальной ветки существует и ECF Extras, расположенные на GitHub. В состав ECF Extras входят провайдеры для NNTP, JMS, Yahoo, Call API (VoIP), Google Wave, JGroups, Net4J, JXTA, Skype, Twitter и т.д., в частности - OSCAR/ICQ-провайдер и большой набор примеров использования ECF от Сурового.

Стоит отметить, что в отличие от множества других OpenSource-проектов, в том числе и разрабатываемых под эгидой Eclipse Foundation, ECF является проектом, развиваемым исключительно сообществом. Нас не спонсируют крупные компании, такие как IBM, Oracle, Microsoft и т.д.

Понравилось сообщение - подпишитесь на блог

Введение в OSGi: Среда исполнения (Execution Environment)

Среда исполнения (Execution Environment) в мире OSGi - это символьное представление версии JRE, т.е. указание платформе с какой версией JRE совместимы классы, составляющие бандл.

Понятие "среда исполнения" становится необходимо, когда бандл разрабатывается на одной JRE, но предполагается, что использоваться он будет на другой JRE или, что более характерно, нескольких JRE. Возникновение данного понятия имеет глубокие исторические причины, т.к. OSGi изначально создавалась для использования во встроенных решениях, для которых имеется довольно широкое многообразие различных версий Java-платформы.

В общих чертах идея использования среды исполнения заключается в следующем: при разработке бандла указывается в каких версиях JRE предполагается его использовать, в зависимости от этого становятся доступными те или иные API. Во время исполнения же, если среда исполнения бандла не совместима со средой, в которой запущена платформа OSGi, он не будет загружаться.

В данной статье мы подробно рассмотрим следующие вопросы:
- Стандартные среды исполнения.
- Конфигурирование среды исполнения в Eclipse SDK.
- Настройка Eclipse PDE для верификации API, доступных в той или иной среде исполнения.
- Создание бадла и использование информации о среде исполнения при его разработке.
- Запуск бандлов в различных средах исполнения.

Eclipse RCP: Понятие "возможности" (feature) в Eclipse RCP

Одним из важных понятий платформы Eclipse является понятие "возможности" (feature). Под возможностью понимается логическая группа бандлов, которые рассматриваются как единое целое. Важность понятия "возможность" проистекает из того факта, что механизм обновления и инсталяции программного обеспечения, применяемый в платформе Eclipse, - Eclipse Equinox p2 - позволяет выбирать для установки/обновления только возможности.

Строго говоря, общепринятого перевода данного термина на русский язык не существует, поэтому здесь и далее будет употребляться слово "возможность". Если у вас есть другое мнение по данному вопросу - добро пожаловать в комментарии.

Если бандл является элементом технической декомпозиции, т.к. любое приложение, построенное на платформе Eclipse, с технической точки зрения может рассматриваться как множество бандлов, то возможность - это элемент маркетинговой декомпозиции, позволяющий указать, что некоторая группа бандлов является отдельной функциональностью, созданной разработчиком X, имеющей название Y и решающей тот или иной набор задач. Оперирование при установке/обновлении приложений возможностями, а не бандлами облегчает работу пользователей, т.к. позволяет им оперировать меньшим количеством более крупных компонентов, нежели отдельные бандлы.

При этом необходимо четко понимать, что возможность - это лишь логическое объединение бандлов, она не содержит jar-архивов, а значит один бандл может быть включен в несколько возможностей.

Знакомимся: Tycho - набор плагинов к Maven для сборки OSGi-бандлов и RCP-приложений

Сообщество разработчиков Eclipse не перестает радовать новыми проектами. Об одном из молодых проектов мне бы и хотелось сегодня рассказать. Встречайте - проект Eclipse Tycho - набор плагинов к системе сборки Maven 3, позволяющий собирать OSGi-бандлы и RCP-приложения.

Допустим вполне резонный вопрос: зачем нужна еще одна система сборки для бандлов, если уже есть Eclipse PDE и BND-Tools? Основной особенностью Tycho является то, что он помогает разрешать зависимости, основываясь на файлах манифестов и Eclipse-специфичной метаинформации (файлы plugin.xml и feature.xml), что отличает его от BND-Tools и в тоже время делать это из командной строки с помощью Maven, не требуя установленного и запущенного Eclipse'а, в отличие от PDE. Первая возможность - manifest-based разрешение зависимостей - избавляет от необходимости делать двойную работу: прописывать зависимости в манифесте, а затем еще и в POM-файле. Вторая особенность - интеграция c Maven - позволяет управлять сборкой бандлов/плагинов с помощью систем непрерывной интеграции, например Hudson, а также использовать для разработки другие IDE - не содержащие Eclipse PDE, например IntelliJ IDEA.

Другой приятной возможностью Tycho является управление модульным и интеграционным тестированием в OSGi-среде. Можно создавать бандлы, которые будут содержать JUnit-тесты для плагинов, а Tycho возьмет на себя работу по запуску данных тестов, причем все это будет производиться в стандартном цикле сборки Maven'а. Данная функция аналогична возможности Run as JUnit Plug-in Test, предоставляемой PDE.

И, наконец, Tycho позволяет гибко управлять целевыми платформами, используемыми при сборке и тестировании бандлов/приложений, что облегчает пользователям подключение новых разработчиков к команде, т.к. позволяет не тратить время на решение вопросов вида "где взять тот или иной бандл, требуемый для приложения".

ECF: Выпущен ECF 3.4

После четырех месяцев разработки выпущена версия 3.4 Eclipse Communication Framework.

Введение в OSGi - Снова о доступности классов

Шпаргалка по механизму, обеспечивающему доступность классов в OSGi.

1. Один класслоадер на бандл

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

Данное решение имеет следствия:
- Classpath больше не линеен - у каждого бандла он свой.
- Классическая иерархия класслоадеров (Bootstrap -> Extension -> System) не работает.
- По-умолчанию в качестве родительского используется Bootstrap classloader, но данное поведение настраивается.

Eclipse RCP: Целевые платформы Eclipse (Eclipse Target Platforms)

Начиная с Eclipse 3.3 существует удобная возможность управления бандлами, доступными при разработке плагинов/RCP-приложений с помощью Eclipse PDE. Речь идет о таком понятии, как "целевая платформа" (Eclipse Target Platform) - списке бандлов и параметров, которые будут доступны при компиляции, отладке и тестировании плагинов из рабочего пространства (Eclipse Workspace).

Зачем создавать собственные целевые платформы

По-умолчанию в качестве целевой платформы используется содержимое каталога plugins запущенного экземпляра Eclipse. Обычно в такой целевой платформе содержатся сотни бандлов (в моем Eclipse for RCP and RAP Developers их 467), что как правило очень много и вовсе не нужно для компиляции/отладки/тестирования RCP/RAP-приложения или плагина. Зачем тратить время (особенно при разработке, когда перезапускать приложение приходится довольно часто) на ожидание старта сотен бандлов, если их нужно от силы 20-30?

Взаимодействие c OSGi - Проблемы загрузки классов

Итак, вы разрабатываете фреймворк и хотите, чтобы была возможность использовать его в OSGi-среде, причем желательно без необходимости написания оберток и изменения/перекомпиляции исходного кода. Т.е., другими словами, вы хотите добиться минимум первого уровня совместимости вашего фреймворка с технологией OSGi. В данной заметке мы рассмотрим как обеспечить в такой библиотеке корректную работу динамической загрузки классов.

Взаимодействие с OSGi - Уровни взаимодействия с OSGi

Известный OSGi-евангелист Neil Bartlett начал интересную серию статей о разработке библиотек, способных корректно работать в среде OSGi.

В принципе, многие библиотеки могут работать в OSGi среде, даже если они не предоставляют OSGi-дескриптора (т.е. файла MANIFEST.MF, содержащего поля Bundle-SymbolicName и т.д.), если только они не используют паттерны, создающие проблемы, такие как сканирование ClassPath и вызовы Class.forName(). Данные библиотеки Neil обозначает термином compliant. Другие фреймворки могут более глубоко интегрироваться с OSGi, например использовать сервисы, настраиваться через Config Admin и т.д.

Чтобы сделать диалог между авторами библиотек и OSGi-сообществом более продуктивным Neil предлагает договориться о терминах и ввести следующую шкалу уровней взаимодействия между библиотекой и OSGi.

Сервлеты и OSGi: разворачиваем бандлы на GlassFish v3

В ноябре 2008-го года тогда еще живая SUN Microsystems выпустила новую экспериментальную версию сервера приложений с открытым исходным кодом - GlassFish v3 Prelude. С тех пор вышло несколько стабильных версий данного сервера, последней из которых на сегодняшний день является 3.0.1. Отличительными чертами GlassFish v3 являются модульность и расширяемость, обеспечиваемые использованием технологии OSGi (в реализации Apache Felix). Соответственно, с одной стороны GlassFish v3 предоставляет сервлет-контейнер (как часть спецификации JavaEE 6.0), а с другой - OSGi-фреймворк (Apache Felix или Eclipse Equinox), что позволяет добавлять свои бандлы, в которых можно регистрировать сервлеты.

Подробно вопрос регистрации сервлетов с помощью сервиса HttpService рассматривался в предыдущих статьях серии, поэтому сейчас мы сконцентрируемся только на вопросах развертывания бандлов, содержащих сервлеты, на GlassFish v3.

Запускаем GlassFish v3 на OSGi-фреймворке Equinox

Введение

Одним из преимуществ сервера приложений GlassFish v3 является модульность, которая обеспечивается за счет использования технологии OSGi. По-умолчанию, в качестве OSGi-фреймворка для GlassFish используется Apache Felix, однако имеется возможность запускать данный сервер приложений и поверх другого популярного OSGi-фреймворка с открытым исходным кодом - Eclipse Equinox. Напомню, что на базе Eclipse Equinox построена широкоиспользуемая Java-разработчиками IDE Eclipse, да и вообще вся платформа Eclipse RCP/RAP.

Внимание! Из-за различий в лицензиях GlassFish и Eclipse Equinox сам фреймворк Equinox не поставляется вместе с сервером приложений. Нужно или скачать последнюю версию данного фреймворка или скопировать Jar-файл org.eclipse.osgi_3.x.x.vxxx.jar из имеющейся у вас поставки Eclipse в каталог $GlassFish_HOME/osgi/equinox.

Существует два способа заставить GlassFish запускаться на Equinox: использование переменной окружения GlassFish_Platform и использование опции JVM -DGlassFish_Platform. Рассмотрим эти способы подробнее.

Сервлеты и OSGi: Equinox в сервлет-контейнере. Equinox Servletbridge

Наконец-то пришло время рассмотреть, как выполняется развертывание приложения, основанного на OSGi, в обычном, а не приспособленном специально для Equinox, сервлет-контейнере (или сервере приложений, в дальнейшем будем употреблять только термин "сервлет-контейнер"), таком как Tomcat, GlassFish, IBM WebSphere и т.д.

Eclipse RCP: Сборка и развертывание RCP-приложения. Понятие "Продукт"

Итак, в прошлый раз мы рассмотрели понятие RCP Application и поняли, что процесс развертывания приложения вручную достаточно трудоемок. Сегодня мы поговорим о механизме, который позволяет добавить к приложению специфичные для него параметры брендинга, такие как иконки, лицензию, экран загрузки, окно приветствия и т.д. и, самое главное, создать нужную структуру каталогов, файлы конфигурации и экспортировать все бандлы, от которых зависит приложение. Такой механизм называется продуктом (product).

Проект состоит из двух частей: файла с расширением product в котором хранятся все специфичные для приложения настройки (иконки и т.д.) и точки расширения org.eclipse.core.runtime.products с помощью которой продукт регистрируется в реестре. Рассмотрим подробно создание продукта с помощью встроенного в Eclipse PDE редактора и развертывание приложения с помощью соответствующего визарда. Все примеры приведены для Eclipse Helios, запущенного под ОС Gentoo GNU/Linux.

Eclipse RCP: О понятии RCP Application

В прошлый раз я обещал написать про то, как деплоить OSGi-приложение в сервлет-контейнерах, отличных от Jetty. Для решения данной задачи используется Equinox ServletBridge, однако, прежде чем разбираться с данным механизмом, необходимо вникнуть в основы построения и деплоймента Eclipse RCP-приложений. О деплойменте поговорим чуть позже, а сегодня разберемся с тем, что такое "приложение" в терминах Eclipse RCP.

Приложением называется класс, реализующий интерфейс IApplication. В каком-то смысле приложение является точкой входа в Eclipse RCP и является аналогом метода main Java или C/C++ программы. В поставку Eclipse Plugins Development Environment включено несколько примеров приложений. Вот код класса, реализующего интерфейс IApplication из примера Hello RCP:

Сервлеты и OSGi: будь проще и люди к тебе потянутся

Данную заметку можно рассматривать как продолжение предыдущей - О любви и дружбе между сервлетами и OSGi. Рассмотрим еще один способ регистрации сервлета в OSGi-контейнере - использование декларативных сервисов.

Использование декларативных сервисов обеспечивает следующее преимущество по сравнению с использованием точек расширения и сервис-трекера: OSGi контейнер в этом случае сам управляет жизненным циклом бандла. Имеется ввиду следующее: в декларативном сервисе определяются методы регистрации зависимостей и старта/останова сервиса. Пока все зависимости не будут удовлетворены - сервис не будет запущен. Таким образом гарантируется, что в момент запуска декларативного сервиса регистрации сервлета, сервис HttpService будет доступен. Данное обстоятельство позволяет существенно упростить код регистрации сервлета, сделать его короче и понятнее. К тому же, в случае использования декларативных сервисов, нам не нужен активатор бандла.

ECF: Пишем SOAP-клиента на примере использования веб-сервиса "Аэрофлота"

В версии 3.2 Eclipse Communication Framework появилась возможность разрабатывать клиенты к SOAP-сервисам (до этого была возможность использовать только REST-сервисы), используя Remote Services API. Инкапсулирована данная возможность в бандле org.eclipse.ecf.remoteservice.soap.

Есть одно радикальное отличие в реализации ECF-клиента к SOAP веб-сервису от реализации клиентов к другим типам удаленных сервисов. Дело в том, что бандл org.eclipse.ecf.remoteservice.soap содержит лишь набор неких базовых классов, конкретный же контейнер, представляющий собой клиента к конкретному веб-сервису, придется писать самостоятельно. Точно так же самостоятельно придется реализовывать непосредственно логику обращения к веб-сервису, используя для этого такие библиотеки, как Axis, Axis 2 или XFire.

Давайте рассмотрим пример - реализуем бандл, name.samolisov.ecf.webservices.demo, который будет содержать удаленный сервис, инкапсулирующий обращение к некоторым методам веб-сервиса компании "Аэрофлот". WSDL-описание веб-сервиса компании "Аэрофлот" расположено здесь. Данный сервис предоставляет информацию об аэропортах, рейсах, предоставляет табло прилетов и табло вылетов. Мы реализуем обращение к следующим методам: AirportList - предоставляет список аэропортов, в/из которые/ых летают самолеты "Аэрофлота", AirportInfo - возвращает информацию об аэропорте по его коду и метод Arrival - принимает код эропорта, дату, поле по которому будет осуществляться сортировка и направление сортировки и возвращает табло прилетов для данного аэропорта на данную дату, отсортированное по указанным критериям. Мы реализуем обращение к данному методу, с сортировкой по аэропорту по возрастанию.

Сервлеты и OSGi: о любви и дружбе между сервлетами и OSGi

Как известно, одной из основных областей применения языка и платформы Java является разработка веб-приложений, по крайней мере в России, если ищут программиста на данном языке, то в описании вакансии как правило указывают J2EE, Servlets, JSP, JSF и прочие умные слова. В сферу моих интересов входит разработка модульных приложений с использованием технологии OSGi и у меня есть хорошая новость: сервлеты тоже могут быть модульными и могут интегрироваться с данной технологией.

В такой реализации OSGi, как Equinox присутствует сервлет-контейнер (Jetty) и специальные сервисы, предназначенные для регистрации сервлетов и управления их жизненным циклом. Строго говоря, для Equinox разработаны средства интеграции и с другими сервлет-контейнерами и серверами приложений, но в данной заметке будет рассмотрено только использование Jetty.