Модифициране на манифест на пакет по време на изпълнение

Възможно ли е (и ако е така, безопасно) да модифицирате МАНИФЕСТА на пакет по всяко време през жизнения му цикъл (т.е. вероятно само между ИНСТАЛИРАН и РАЗРЕШЕН).

Предполагам, че друг начин да задам въпроса е,

След ИНСТАЛИРАН, но преди РАЗРЕШЕН, МАНИФЕСТЪТ вече напълно ли е оценен (т.е. по-нататъшните промени ще бъдат игнорирани), което прави твърде късно за промяна?

Ако всичко по-горе изглежда абсурдно... тогава следващият ми въпрос ще бъде дали някой мисли, че е възможно (без неприятни хакове на рамка) да се обвие разделителната способност на МАНИФЕСТА (т.е. стъпката на зареждащия клас за получаване на META-INF/MANIFEST.MF от пакет) с персонализирано импл.

История: Помислете за съществуваща модулна рамка, която не е базирана на OSGi, за която бих искал да опростя миграцията към OSGi, като предложа възможност за внедряване на тона на съществуващите „плъгини“ без модификация, и по време на изпълнение извършете анализ ("добавките" са добре дефинирани, така че картографирането не трябва да е трудно), който ги преобразува в истински OSGi пакети, като използвате операции по време на изпълнение на BND, за да генерирате МАНИФЕСТ, който би се използвал вместо потенциално нищо- съществуващ или не-osgi-пакет МАНИФЕСТ.

Надяваме се, че това има смисъл (@njbartlett!)


person Ray    schedule 11.09.2011    source източник


Отговори (2)


Защо не дефинирате URL схема, която променя манифеста като част от процеса на инсталиране/актуализация? Когато рамката има достъп до пакета чрез вашия URLConnection, можете да върнете мутирал пакет с мутиралия манифест. Това е основно това, което прави поддръжката на уеб пакета и трябва да работи и за вас.

person BJ Hargrave    schedule 11.09.2011
comment
Благодаря BJ & njb! Това е нещо, което имах предвид и след като прегледах малко какво прави virgo, подозирах, че това може да е правилният начин, но исках да го чуя от професионалистите. Мразя да навлизам толкова далеч в impl и по-късно да чуя какво направихте това, когато можехте да направите това.... Можете ли да посочите най-чистия impl на тази идея, за да мога да науча някои най-добри практики? - person Ray; 12.09.2011
comment
Разгледайте обвивката на URL адреса на Pax, тя се използва за трансформиране на maven буркани, които не са OSGi, в пакети (т.е. с manifest.mf) по време на изпълнение. github.com/ops4j/org.ops4j. pax.url/commits/master/pax-url-wrap - person earcam; 12.09.2011

Не, не можете да направите това. Целият JAR файл (и следователно MANIFEST.MF) се чете по време на инсталационната операция. За да промените нещо в този JAR, ще трябва или да актуализирате пакета, или да деинсталирате и инсталирате отново.

Относно това, което всъщност искате да направите, защо не можете просто да извършите анализа и трансформацията чрез bnd преди да инсталирате JAR като пакет?

person Neil Bartlett    schedule 11.09.2011
comment
Гъвкавостта на възможността да внедрим това вътре в OSGi рамката като (Framework|Bundle)Listener беше привлекателна. Наясно съм, че можем да го направим и преди. И така ще трябва да бъде начинът! - person Ray; 11.09.2011
comment
Всъщност, не че се опитвам да сменя буркана... а че се опитвам да увия определени части от буркана, за да изглеждат по различен начин. - person Ray; 11.09.2011
comment
Въпреки че, за да бъда честен, gemini-web/virgo прави нещо подобно, когато обвива уеб пакети. - person Ray; 11.09.2011
comment
Рей, виж отговора на BJ. Забравих за тази възможност и ми звучи доста елегантно. - person Neil Bartlett; 12.09.2011