Я провел свое собственное исследование (просматривая спецификации и несколько блогов), и ниже я понял, что
EAR
Спецификация НЕ определяет и не предписывает, как загрузчики классов должны работать в EAR. Однако он определяет, что
- ДОЛЖЕН быть загрузчик классов контекста для каждого потока для загрузки классов во время выполнения
- МОЖЕТ существовать иерархический механизм загрузки классов для разрешения классов (поставщики серверов приложений могут свободно реализовывать любой выбранный ими способ)
- загрузчик классов верхнего уровня (WAR / EAR) МОЖЕТ делегировать загрузчикам классов низкого уровня (таким как Bootstrap, расширение и т. Д.). Это соответствует модели делегирования загрузчика классов J2SE (PARENT_FIRST в WAS)
ВОЙНА
Спецификация сервлета определяет и предписывает поддержку модели загрузки классов PARENT_LAST (т.е. WAR / web-inf / classes и WAR / web-inf / lib имеют приоритет над библиотеками, которые поставляются с сервером приложений). Но это только для модулей WAR. В этом случае спецификация сервлета отличается от стандартной модели делегирования J2SE PARENT_FIRST.
1024 * Ссылка *
Спецификация: Servlet 2.3, Раздел: 9.7.2 Webloader Classloader
Спецификация: Java EE 5, Раздел: EE.6.2.4.7 Загрузчик класса контекста
Особенности сервера приложений
Интересно, однако, что большинство основных серверов приложений поддерживают некоторый механизм отключения делегирования для изоляции приложения от сервера приложений, если это необходимо (из-за конфликтов или по иным причинам): WebSphere - «parent-last», GlassFish - <class-loader delegate="false">
, JBoss - java2ParentDelegation=false
, Geronimo - <java2-delgation-model>false</java2-delegation-model>