Преимущества (и советы) обновления от JBoss 4.2.x до JBoss 5.x, 6.x, 7.x и WildFly 8.x?

Ответ 1

Я обновил JBoss 4 до 5, и из опыта наиболее важно отметить:

• JBoss 5 (и 6 и 7) не так просты, как JBoss 4 с XML файлами. Вы должны убедиться, что все ваши XML файлы дескриптора развертывания действительны. Вы можете использовать DTD в некоторых файлах - я рекомендую их обновить, чтобы использовать схему XML.
• Некоторые библиотеки могут вызывать несовместимость. Это может быть особенно актуально, если вы обращаетесь к веб-службам и/или выполняете разбор XML
• Если вы прекомпилируете свои JSP в JBoss 4, вы, вероятно, не сможете в JBoss 6/7.
• JBoss 4 и 5 используют разные реализации очереди сообщений. Если у вас есть какие-либо очереди сообщений или определенные темы, вам необходимо их переопределить.
• JBoss TreeCache больше не используется. Если вы используете это для кеширования, вам нужно будет изменить вместо нового кеша JBoss.
• Безопасность JBoss 5 отличается. Если вашим удаленным клиентам требуется защищенный доступ к JBoss, вам нужно будет настроить их по-разному.

Некоторые полезные ресурсы:

http://java.dzone.com/articles/migrating-jboss-4-jboss-5 http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga

Официально JBoss 6 сертифицирован только для веб-профиля Java EE, поэтому, если вы используете "устаревшие" функции, такие как EJB 2.x, они потенциально не будут поддерживаться в будущем. В зависимости от жизненного цикла вашего приложения это может быть или не быть проблемой. JBoss 6 в настоящее время полностью поддерживает EJB2.1, но он не сертифицирован на это.

Я также обнаружил, что JBoss 5 обрабатывает память намного лучше, чем JBoss 4. С JBoss 4 я вижу намного больше ошибок PermGen, чем с JBoss 5.

Ответ 2

Я могу говорить только из опыта производства с JBoss 5.1.0 и некоторым исследованием версии 6.

JBoss 5 Java EE 5 и JBoss 6 и 7 Java EE 6. Несоответствие функций API лучше всего описано в этих спецификациях. Вероятно, у JBoss 6 очень короткий срок хранения; это только сертифицированный для веб-профиля Java EE 6, и исправления нацелены на версию 7 (в ее 3-й бета-версии на момент написания).

Думаю, вы получите лучшие ответы на форуме сообщества JBoss.

Ответ 3

Мы перешли от JBoss AS 5 к JBoss AS 7 и смотрим в сторону WildFly AS 8.1. Прямо сейчас мы не можем перейти на 8, потому что нет MQ Series JMS 2 RAR.

Некоторые отличия:

• Конфигурация намного лучше и проще. Он больше не распространяет более 20 файлов XML, в которых вы настраиваете аспекты в файлах XML. Вместо этого все одно центральное место. Все порты настроены в одном центральном месте, больше нет файла XSL, который преобразует server.xml. Вы можете понять конфигурационный файл, не зная деталей реализации классов. Это трудно понять, если вы никогда не настраивали JBoss 5.x.
• Модель загрузки классов выглядит разумно, и вы получаете большой контроль через jboss-deployment-structure.xml
• Централизованное ведение журнала (Slf4j, JUL, JCL, Log4j,...) действительно приятно.
• Клиентская библиотека EJB выглядит намного более очищенной. Это до 10 JAR с 20, половина из них - даже пакеты OSGi (наш клиент - приложение RCP Eclipse).
• Неисправность зависимостей клиентов EJB-клиента отсутствует, вместо этого теперь вы получаете BOM POM.
• Вы получаете BOM POM для API-интерфейсов сервера.
• Более быстрый запуск и уменьшение использования памяти. Мы разворачиваем 80 EJB и RAR MQ Series за 6 секунд без большой настройки. Наш живой набор данных находится где-то выше 200 МБ.
• По умолчанию папка развертывания пуста
• Качество (отсутствие) XNIO страшно. В 7.x он используется только для удаленного EJB, и мы нажимаем несколько пробных пробных ошибок (взаимоблокировки, двойные свободные, утечки дескрипторов сокетов). В 8.x он используется также для сервлетов, а не для Tomcat. Есть еще очень много базовых ошибок сервлета, которые фиксируются в подходе.

Изменения, которые мы должны были выполнить:

• изменить имена JNDI на стандартизованные имена EE 6
• перейти от JBoss Cache к Infinispan (часть нашего кода была перенесена в плоский API, некоторые части по-прежнему используют API дерева)
• безопасность немного менее гибкая (вы больше не можете исправлять аутентифицированные и неавторизованные вызовы)
• некоторый ужасный код, основанный на деталях удаленного JNDI
• конфигурация клиента EJB отличается
• все ваши скрипты для установки, развертывания, запуска, остановки,...
• ExternalContext ушел, нам пришлось заменить его другим подходом
• мы заменили MBeans в SAR на @StartUp EJBs
• некоторые уродливые хаки для Cocoon

Серия AS 7.x содержит много ошибок с исправлениями, доступными только в серии EAP. Если вы хотите использовать 7.x вместо 8.x, мы настоятельно рекомендуем вам купить EAP 6.

Ответ 4

Вот интересная тема о компрометации и будущем JBoss AS 7, также упоминающая проблемы с AS 5 и AS 6:

http://community.jboss.org/message/613171

Ответ 5

Просто хотел привлечь внимание всех, кто может столкнуться с проблемой вздутия PermGen после обновления до последней. Микроконтейнер JBoss-6 пытается отсканировать конкретные аннотации Jboss, загружая классы из всех JAR-пакетов в пути класса при запуске. Это приводит к раздуванию пермгена, когда он начинает загружать все нежелательные классы. Чтобы уменьшить объем сканирования, Microcontainer предоставляет другой дескрипторный крючок с помощью jboss-scan.xml. Добавьте этот "jboss-scan.xml" в WEB-INF внутри WARs и "jboss-scan.xml" в META-INF внутри EAR.

<scanning xmlns="urn:jboss:scanning:1.0">

    <!-- Purpose: Disable scanning for annotations in contained deployment. -->

</scanning>