Какая польза от преобразования jar-файлов в пакеты в WAB (OSGI)?

Изучив структуру OSGi, я разработал образец веб-приложения. Пакет веб-приложений (.war или .jar) упакован внутри eba. Файл war содержит кучу встроенных файлов jar в своем каталоге WEB-INF/lib. Эти jar-файлы были преобразованы в OSGi bundles(using maven-bundle-plugin) с необходимыми пакетами экспорта и импорта в соответствии с соотношением между jar-файлами. Теперь я должен даже упомянуть все эти jars(WEB-INF/lib) в пути к классам пакетов. Вышеупомянутое работает, потому что пакет (wab также является пакетом) может включать в себя один или несколько файлов jar и использовать запись Bundle-Classpath manifest.mf для указания на них.

Если я не включаю jar-файлы в путь пакета-класса, я получаю ClassNotFoundException.

Вопрос в том, что тогда нет смысла конвертировать jar-файлы в пакеты osgi. Очевидно, что все jar-файлы в WEB-INF/lib загружаются одним и тем же загрузчиком классов (то есть загрузчиком классов wab), поэтому мы не пожинаем основных преимуществ OSGi, в основном концепция загрузчика классов для каждого пакета?


classloader osgi manifest.mf osgi-bundle wab
person crackerplace    schedule 21.03.2014    source источник
comment
Звучит правильно, если у вас есть война с дескриптором развертывания, тогда он принадлежит jee-контейнеру, например, tomcat и т. Д. На самом деле вы не используете OSGi, как задумано, с войной, содержащей его собственную библиотеку.   -  person codesalsa    schedule 22.03.2014
comment
@codesalsa Изначально я предполагал, что jar-файлы в папке lib также будут разворачиваться в виде пакетов, так как они содержат Manifest Entry для OSGi, но они обрабатываются так же, как обычные jar-файлы, как указано в пути к классам wab-пакета.   -  person crackerplace    schedule 22.03.2014
comment
не уверен, в чем польза преобразования веб-приложения в osgi, если предположить, что мне не нужен реестр служб OSGI. Конечно, мы не можем вручную установить каждый из пакетов из папки lib.   -  person crackerplace    schedule 22.03.2014

Ответы (1)


arrow_upward
1
arrow_downward

Помещение jar-файлов в WEB-INF / lib - это старый способ обработки зависимостей, основанный на нормальном java, а вывод их за пределы войны - это новый способ обработки OSGi.

Упаковывая зависимости вашей войны в WEB-INF / lib, вы обрабатываете их как обычные банки (помните, что пакет также является банкой). Так что в этом случае вы правы, что в использовании бандлов особого смысла не было.

Одно из преимуществ использования wabs вместо войн - уйти от ужасной монолитной войны размером 100 Мбайт. Вместо того, чтобы упаковывать пакеты внутри WEB-INF / lib, попробуйте заставить war импортировать необходимые пакеты с помощью Import-Package: и упаковать зависимости внутри eba. (Если вы не помните, чтобы война импортировала необходимые пакеты, вы получите исключения класса «не найден», которые вы видели, потому что контейнер OSGi не будет знать, что вашей войне нужны эти пакеты.)

person Holly Cummins    schedule 22.03.2014
comment
хорошо, значит, вы имеете в виду wab, и пакеты из WEB-INF / lib должны быть на одном уровне, то есть на одном шаге внутри eba, чтобы банки (с OSGi Manifest), которые были внутри WEB-INF / lib, также устанавливались как пакеты . Пример: enterprise.eba (META-INF, webapp.wab, ​​util.jar и т. Д.). Да, требуется импорт на уровне войны, поскольку теперь внутри войны нет jar-файлов, а путь к классам пакетов пуст. - person crackerplace; 22.03.2014
comment
Да, именно так. При желании вы также можете переместить банки на следующий уровень, на тот же уровень, что и eba, чтобы их можно было разделить между разными eba. - person Holly Cummins; 23.03.2014
comment
Пакетирование в EBA - это простой выход, поскольку нам нужно просто развернуть его за один раз. Кроме того, эти пакеты относятся к конкретному приложению, поэтому они не распространены, и их место в EBA помогает. связки на один уровень выше, потребуют огромных усилий, так как установка 30-40 пакетов один за другим будет сложной задачей, если не будет автоматизированных решений, которые можно создавать сценариями. - person crackerplace; 23.03.2014
comment
В любом случае мы переместим 2 или 3 общих модуля и зарегистрируем их как службы. - person crackerplace; 23.03.2014