Это вариант использования функции «изолированные общие библиотеки» на сервере WebSphere. Для любых технологий, для которых вам нужно принести собственную версию, а не использовать версию, поставляемую с сервером, поместите необходимые jar-файлы в какой-то каталог за пределами приложения, создайте общую библиотеку, указывающую на это местоположение, выберите «использовать загрузчик изолированного класса». msgstr "в конфигурации библиотеки, и связать библиотеку с приложениями, которые в ней нуждаются. Приложение выполнит поиск изолированного загрузчика классов библиотеки перед делегированием его родительским загрузчикам, и вместо предоставленных сервером версий будут найдены классы.
Несколько предостережений: это следует использовать ТОЛЬКО для технологий, которые на 100% уверены, что вам нужна собственная версия, а не серверная. Стиль «родительского последнего» загрузки классов, используемый изолированными общими библиотеками, включает в себя некоторый риск конфликтов между загрузчиками классов, и его избегание (с помощью API, предоставляемых сервером), как правило, является более безопасным вариантом.
Обратите внимание, что не все может быть переопределено. API Servlet, EJB и JPA, например, прервут запуск приложения, если он будет включен в изолированную общую библиотеку, поскольку контейнеры сервера требуют согласованных версий классов API при обработке объектов приложения. Кроме того, вы не можете использовать API какой-либо технологии без связанной реализации - это обычно является рецептом для VerifyError или LinkageError, вызванным дублированием видимости для нескольких версий API.