Каква е ползата от конвертирането на буркани в пакети в WAB(OSGI)?

След като проучих OSGi рамката, бях разработил примерно уеб приложение. Пакетът уеб приложения (.war или .jar) е опакован в eba. Военният файл съдържа куп вградени jar файлове в неговата WEB-INF/lib директория. Тези буркани са преобразувани в OSGi пакети(using maven-bundle-plugin) с необходимите пакети за експортиране и импортиране според връзката между бурканите. Сега дори трябва да спомена всички тези буркани(WEB-INF/lib) в пътя на класа на пакета. Горното работи, защото пакетът (wab също е пакет) може да включва един или повече jarфайлове в него и да използва запис Bundle-Classpath manifest.mf, за да сочи към тях.

В случай, че не включа бурканите в bundle-classpath, получавам ClassNotFoundException.

Въпросът е, че тогава няма смисъл да конвертирате бурканите в пакети osgi. Очевидно всички буркани в WEB-INF/lib се зареждат от един и същ зареждащ клас (т.е. зареждащ клас за wab), така че тогава не се възползваме от основните предимства на OSGi, което е главно концепция за зареждане на класове на пакет?


person crackerplace    schedule 21.03.2014    source източник
comment
Звучи правилно, ако имате война с дескриптор за разполагане, тогава това принадлежи към jee контейнер като tomcat и т.н. Вие всъщност не използвате OSGi по предназначение с война, съдържаща собствена библиотека   -  person codesalsa    schedule 22.03.2014
comment
@codesalsa Първоначално предположих, че бурканите в папката lib също ще бъдат разгърнати като пакети, тъй като имат специфични за OSGi записи на манифеста. Но те се третират точно като нормални буркани, както е споменато в класовата пътека на пакета wab.   -  person crackerplace    schedule 22.03.2014
comment
не съм сигурен тогава каква е ползата от конвертиране на уеб приложение в osgi, ако приемем, че нямам нужда от регистъра на услугите на OSGI. Разбира се, не можем ръчно да инсталираме всеки от пакетите от папката lib.   -  person crackerplace    schedule 22.03.2014


Отговори (1)


Поставянето на буркани вътре в WEB-INF/lib е стария стил на нормален Java начин за обработка на зависимостите, а поставянето им извън войната е новият OSGi начин за справяне с тях.

Като опаковате зависимостите на вашата война в WEB-INF/lib, вие ги третирате като нормални буркани (помнете, че пакетът също е буркан). Така че в този случай сте прав, че нямаше много смисъл да се използват пакети.

Едно от предимствата на използването на wabs вместо войни е да се измъкнете от страховитата 100 Mb монолитна война. Вместо да опаковате пакетите в WEB-INF/lib, опитайте да накарате войната да импортира пакетите, от които се нуждае, като използва Import-Package:, и опаковайте зависимостите вътре в eba. (Ако не си спомняте да накарате войната да импортира пакетите, от които се нуждае, ще получите изключенията за класа, които не са намерени, които виждахте, защото OSGi контейнерът няма да знае, че вашата война се нуждае от тези пакети.)

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