Загрузка классов в серверах приложений, особенности JBoss AS 7

[@Evgin]

Модульная система чем-то похожа на OSGi?

[@grossws]

Да, JBoss Modules напоминает OSGi уровень, отвечающий за загрузку, но ориентированы на разное применение.
Modules — легковесная прослойка для загрузки классов, не занимающаяся, например, разделением видимости публичного API и имплементации.

То есть, если Modules указать в зависимостях определенный jar, то все его классы будут доступны для classloader'а. В OSGi окружении будут доступны только классы, указанные в Export-Package в манифесте.

Естественно, OSGi R4 затрагивает и другие уровни (lifecycle, services), что ортогонально применимости JBoss Modules.

[@grossws]

Ещё дополнение. Современные AppServer'а обычно сами строятся на OSGi платформе. В JBoss AS 7 оно тоже доступно, но работает независимо от JBoss Modules, используемого для деплоя и разрешения зависимостей WAR/EJB-JAR/EAR/etc

[@dax]

Естественно, что класс может и не обнаружится — тогда происходит ошибка загрузки оного, как правило, приводящая к падению JVM

Мало того, в сию же минуту умирает 12 ни в чем не повинных котят.

[@webus]

Вы про 12 Томкатов?

[@skywatcher]

А из-под Eclipse'ушки WTP кто-то пробовал запускать с JBoss AS 7? Редеплой там нормально работает?

[@grossws]

Только если они успели допилить. API деплоя изменилось от 7.1.RC (такое же, как в 7.0 ветке) к 7.1.Final, это поломало совместимость в идее (11.0 не работает без скачанной руками сборки plugin'а — см. IDEA-81489, в 11.1 EAP уже всё норм).

Всегда остается workaround: использовать jboss-maven-plugin. Так в idea спасались, когда не было поддержки AS 7 вообще.

[@DbLogs]

Скажите, а можно ли в эти модули выносить фреймворки, чтобы не копировать один и тот же фреймворк во всех своих EAR'ах? Не будет ли проблем, если фреймворк использует статические поля и он указывается как депенденси в двух разных EAR'ах?