Ответ 1
Я провел собственное исследование (пройдя через спецификации и несколько блогов), а ниже я понял, что
EAR
Спецификация НЕ определяет или не определяет, как классные загрузчики должны работать в EAR. Однако он определяет, что
- ДОЛЖНО быть на загрузчик классов контекста потока для загрузки классов
- МОЖЕТ быть иерархическим механизмом загрузки классов для разрешения классов (поставщики серверов приложений могут свободно реализовывать в зависимости от того, как они выбирают)
- загрузчик класса верхнего уровня (WAR/EAR) МОЖЕТ делегировать загрузчикам класса низкого уровня (например, Bootstrap, расширение и т.д.). Это соответствует модели делегирования загрузчика класса J2SE (PARENT_FIRST в WAS).
WAR
Спецификация сервлета определяет и обеспечивает поддержку PARENT_LAST (то есть WAR/web-inf/classes и WAR/web-inf/lib имеют приоритет над библиотеками, которые поставляются с сервером загрузки приложений). Но это только для модулей WAR. В этом случае спецификация Servlet расходится со стандартной моделью делегирования J2SE PARENT_FIRST.
Ссылка
Спецификация: Servlet 2.3, раздел: 9.7.2. загрузчик классов веб-приложений
Спецификация: 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>