inverse_loading в WASCE 3.0.0.3 / Geronimo 3.0

Я пытаюсь развернуть войну на IBM Websphere Application Server Community Edition (WASCE) 3.0.0.3. У меня были проблемы с конфликтом между банками, которые поставляются с WASCE 3.0.0.3, и банками из-за зависимостей нашего приложения. В конце я исправил проблему, используя свойство ниже в geronimo-web.xml, чтобы заставить WASCE загружать jar-файлы из моего приложения.

<import-package>!the.conflicting.jars</import-package>

Однако я хотел бы заставить WASCE всегда сначала брать jar-файлы из моего приложения, т.е. инвертировать поведение загрузчика классов по умолчанию для загрузки из приложения в первую очередь. Какую конфигурацию следует изменить в этом случае?


После некоторых поисков, WASCE 3.0 основан на Geronimo 3.0 согласно ссылка. Я обнаружил, что установка <inverse-classloading> в geronimo-web.xml может быть полезной. Но ниже в двух документах на веб-сайте Apache Geronimo 3.0 упоминается, что эта функция больше не доступна в Geronimo 3.0.

в Переход с G 2.x на G 3. x, в нем говорится:

обратная загрузка классов Geronimo 3.0 не поддерживает элемент в плане развертывания.

в geronimo-web.xml,

Элемент <sys:environment> содержит следующие элементы:

...

Элемент <inverse-classloading> может использоваться, чтобы указать, что стандартное делегирование загрузчика классов должно быть отменено для этого модуля. Делегирование загрузчика классов Geronimo следует спецификациям Java EE 5, и нормальным поведением является загрузка классов из родительского загрузчика классов (если он доступен) перед проверкой текущего загрузчика классов. ...... ...... (Не поддерживается в версии 3.0, используйте вместо этого <import-package/>)


Итак, если <inverse-classloading> больше не доступен, что эквивалентно этому свойству в WASCE 3.0.0.3? Или как именно это сделать, используя <import-package/> для всех дублированных банок?


person Xiawei Zhang    schedule 24.03.2015    source источник


Ответы (1)


По указанной вами ссылке вы найдете следующий раздел

<sys:environment>

XML-элемент <sys:environment> использует пространство имен Geronimo System, которое используется для определения общих элементов для общих библиотек и сервисов в области модуля, и задокументировано здесь:

http://geronimo.apache.org/schemas-3.0/docs/geronimo-module-1.2.xsd.html

Элемент содержит следующие элементы:

Элемент <moduleId> используется для предоставления имени конфигурации веб-приложения, развернутого на сервере Geronimo. Он содержит элементы для groupId, artifactId, версии и типа модуля. Идентификаторы модулей обычно печатаются с косой чертой между четырьмя компонентами, такими как GroupID / ArtifactID / Version / Type.

Элемент <dependencies> используется для предоставления конфигураций и сторонних библиотек, от которых зависит веб-модуль. Эти конфигурации и библиотеки доступны веб-модулю через иерархию загрузчика классов Geronimo.

Элемент <bundle-activator> используется для создания заголовка Bundle-Activator в файле манифеста веб-приложения. Он указывает точку входа веб-приложения, развернутого на сервере Geronimo.

Элемент <bundle-classPath> используется для создания заголовка Import-Package в файле манифеста веб-приложения. Он содержит список каталогов или встроенных файлов jar, которые также называются ресурсами пакета и расширяют путь к классам веб-приложения.

Элемент <import-package> используется для создания заголовка Import-Package в файле манифеста веб-приложения. Он определяет список пакетов, которые необходимо разрешить перед запуском веб-приложения. Используйте <import-package>!packagename</import-package>, чтобы переопределить конкретный пакет на сервере.

Элемент <export-package> используется для создания заголовка Export-Package в файле манифеста веб-приложения. Он определяет список пакетов для экспорта.

Элемент <require-bundle> используется для создания заголовка Require-Bundle в файле манифеста веб-приложения. Он определяет список пакетов для привязки независимо от их пакетов.

Элемент <dynamic-import-package> используется для создания заголовка DynamicImport-Package в файле манифеста веб-приложения. Он определяет список упакованных файлов для динамического импорта, особенно во время загрузки класса.

Итак, в основном вам нужно добавить следующую директиву, т.е.

<sys:import-package>!package-class-name-here*</sys:import-package> в строфе <sys:environment>. Обычно перед директивой Application Context-Root.

Как вы уже знаете, это файл geronimo-web.xml, встроенный в WAR / EAR приложения, как указано в ссылке.

http://geronimo.apache.org/GMOxDOC30/geronimo-webxml.html

person Naveen Shetty    schedule 25.03.2015
comment
Спасибо за помощь, но не совсем ответ на мой вопрос. <inverse-classloading> всегда загружает jar-файлы сначала с уровня веб-приложения, а затем с WASCE, дублированные jar-файлы не будут загружаться дважды. Проблема здесь в том, что если мне нужно использовать <sys:import-package>!package-class-name-here*</sys:import-package>, это означает, что мне нужно точно знать, какие jar-файлы / пакеты не следует импортировать с сервера WASCE. и мне, вероятно, нужно добавлять дополнительные строки этого каждый раз, когда в мой проект вводится новый jar-файл, который также не очень прост в обслуживании. - person Xiawei Zhang; 25.03.2015
comment
Хотя это не совсем то, о чем я просил, в конце концов, это то, что я сделал, чтобы решить проблему. На выявление всех дубликатов уходит некоторое время, и в будущем это может вызвать проблемы при добавлении новых jar-файлов. - person Xiawei Zhang; 17.11.2015