Погружение в технологии java начинает все больше и больше мне нравиться. Сразу после ознакомления с сервлетами сделал для себя открытие, в виде сервера приложений и его возможностей. Планирую ближайшее время посвятить серверной части программирования на Java EE и ознакомления со спецификацией EJB. В качестве поля для деятельности выбрал сервер приложений JBoss. После бинов займусь JSF ну и попутно захвачу jQuery.
В той бочке меда, которую я описал выше есть одна маленькая ложка дегтя 🙁 в виде отсутствия актуальной документации и справки. На ютубе нашел очень хороший канал, в котором в том числе даются и основы работы с java, однако при изучении их я постоянно сталкиваюсь с проблемами несоответствия и то что получается у ведущего, не всегда получается у меня, поэтому я реши обратится к первоисточнику (в принципе, как и предыдущих парочке постах) и нацарапал свою интерпретацию на русском языке документации расположенной на домашней страничке проекта. Сие творение я и выкладываю на ваш суд. Документ постоянно в работе. Не спеша буду добавлять главы.
По традиции, ссылка на оригинал: https://docs.jboss.org/author/display/AS71/Developer+Guide
6.2 Загрузка классов в сервер приложений JBoss 7
Загрузка классов в AS7 (Application server 7) значительно отличается от предыдущих версий jBoss. Загрузка классов основана на проекте jBoss Modules. Вместо более привычной среды загрузки иерархии классов, загрузка классов AS7 основана на модулях, которые имеют явное определение зависимостей в других модулях. Модули публикуемые на AS7 не имеют доступа к классам определенным в jar архивах на сервере приложений, кроме тех, чья зависимость определена явно.
6.2.1 Имена модулей развертывания
Имена модулей развертывания верхнего уровня соответствуют формату: deployment.myarchive.war в то время как «подразвертывания» именуется как deployment.myear.ear.mywar.war.
Это означает что для развертывания возможно импортировать классы из других развертываний используя имя импортируемых развертываний. Детали добавления явных зависимостей объяснены ниже.
6.2.2 Автоматические зависимости
И хотя модули в AS7 изолированы по умолчанию, в рамках процессов развертывания некоторые зависимости модулей определены средой сервера приложений. Например, если Вы разворачиваете приложение Java EE, зависимость от API Java EE будет добавлена автоматически. Аналогично, если Ваш модуль включает файл beans.xml зависимость от JSF Weld будет так же добавлена автоматически, наряду с любыми модулями которые необходимы weld для работы.
Для полного списка автоматически добавляемых зависимостей см. эту страницу.
Автоматические зависимости могут быть отключены в файле jboss-deployment-structure.xml.
6.2.3 Приоритет загрузки классов.
Наиболее частый источник ошибок в Java приложениях заключается в включении API классов в развертывание, которые определены в контейнере приложений. Это может быть результатом различных версий создаваемых классов, и развертывание не может быть установлено корректно. Для предотвращения этого модули зависимостей добавляются в определенном порядке, который не должен допустить возникновение такой ситуации.
Порядок включения от высокого приоритета к низкому
- Системные зависимости – Эти автоматические зависимости включаемые контейнером приложений, включая API Java EE.
- Пользовательские зависимости – Зависимости добавляемые из файла jboss-deployment-structure.xml или через пункт значение манифеста Dependencies.
- Локальные ресурсы — файлы классов верхнего уровня развертывания. Например, файлы классов из WEB-INF/classes или WEB-INF/lib war архива.
- Зависимости между развертываниями – Эти зависимости от других развертываний в ear-файлах развертываний. Это может включать классы в директории lib ear файла, или классы определенные jar файлах других ejb.
6.2.4 Загрузка WAR классов
War файл считается одним модулем, поэтому классы, определенные в WEB-INF/lib рассматриваются так же как классы расположенные в WEB-INF/classes. Все классы упакованные в war файл будут загружены одним загрузчиком.
6.2.4 Загрузка EAR классов
Ear развертывания являются мульти модульными. Это значит, что не все классы, включенные в ear обязательно будут иметь доступ ко всем другим классам включенных в ear, если не было определено явных зависимостей. По умолчанию, каталог EAR/lib является единым модулем, и каждое WAR или EJB развертывание является отдельным модулем. Под развертывание (war и ejb jar файлы) всегда имеют зависимость от родительского модуля, что даем им доступ к классам в EAR/lib, однако они не всегда автоматически имеют доступ к любому другому. Такое поведение управляется настройкой ear-subdeployments-isolated конфигурации подсистемы.
<sybsystem xmlns=”urn:jboss:domain:ee:1.0”>
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
< sybsystem>
По умолчанию значение установлено в false, что позволяет суб-развертываниям видеть классы приналежащие другим суб-развертываниям в ear.
Например, рассмотрим следующие равертывание:
Myapp.ear | |--web.war | |--ejb1.jar | |--ejb2.jar
Если ear-subdeployments-isolated установлено в false, тогда классы в web.war имеет доступ к классам расположенным в ejb1.jar и ejb2.jar. Аналогично, классы из ejb1.jar имеют доступ к классам из ejb2.jar (и наоборот).
Значение ear-subdeployments-isolated не влияет на изолированный загрузчик классов war файлов. Т.е. независимо от того, установлен этот флаг в false или true, .war в .ear будет иметь независимый загрузчик класса и другие суб-развертывания в этом .ear файле не будут в состоянии получить доступ к классам внутри .war файла. Это определено спецификацией.
Если ear-subdeployments-isolated установлено в true, тогда установлены неавтоматические зависимости между модулями суб-развертываний. Пользователь может вручную установить эти зависимости используя значения Class-Path, или настроив явные зависимости модулей.
Переносимость
Спецификация Java EE говорит что переносимые приложения не должны полагаться на суб развертывания имеющие доступ к другим суб развертываниям если не установлено явное значение Class-Path в MANIFEST.MF. Таким образом, переносимые приложения должны явным образом заявить о своих зависимостях.
Кроме того, можно переопределить значение элемента ear-subdeployments-isolated на каждом уровне развертывания. См. раздел по jboss-deployment-structure.xml ниже.