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

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

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

Мало того, в сию же минуту умирает 12 ни в чем не повинных котят.
А из-под Eclipse'ушки WTP кто-то пробовал запускать с JBoss AS 7? Редеплой там нормально работает?
Только если они успели допилить. API деплоя изменилось от 7.1.RC (такое же, как в 7.0 ветке) к 7.1.Final, это поломало совместимость в идее (11.0 не работает без скачанной руками сборки plugin'а — см. IDEA-81489, в 11.1 EAP уже всё норм).

Всегда остается workaround: использовать jboss-maven-plugin. Так в idea спасались, когда не было поддержки AS 7 вообще.
Скажите, а можно ли в эти модули выносить фреймворки, чтобы не копировать один и тот же фреймворк во всех своих EAR'ах? Не будет ли проблем, если фреймворк использует статические поля и он указывается как депенденси в двух разных EAR'ах?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.