Подтвердить что ты не робот

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

Предположим, что мне не нужно беспокоиться о времени разработки и затратах: меня интересуют общие технические преимущества (улучшенная производительность? улучшенные API-интерфейсы?) и новые функции.

В настоящее время я работаю над продуктами, использующими 4.2.x, и мы рассматриваем большой сдвиг для версий, которые долгое время впереди и должны сходиться.

Я кратко рассмотрел примечания к выпуску каждой версии и некоторые статьи о каждой версии для 5.x, 6.x, 7.x и 8.x. Но я был бы рад получить из первых рук отзывы от людей, которые сделали переключатель.

Я заметил, что произошли некоторые важные изменения, связанные с обменом сообщениями (переход от JBoss MQ к JBoss Messenging), а для JBoss 7.x, похоже, он изменил свой уровень конфигурации. Тогда при переключении на JBoss/WildFly 8.x происходит гораздо больше.

Пожалуйста, порекомендуйте хорошие статьи, указывающие на ловушки, если сможете. Я нашел несколько для переноса в JBoss 5.x, но не так много для 6.x или даже 7.x, а кто-то сейчас оценивает 8.x для нас. Не стесняйтесь рекомендовать альтернативы, если вы считаете, что они актуальны, хотя я бы предпочел сосредоточиться только на JBoss.

Для получения информации мы используем сочетание плагинов с поддержкой JPF и OSGi (с использованием Eclipse Equinox) с клиентами, разработанными в Swing (некоторые из них развернуты через WebStart).

Обновление:. Хотя этот вопрос принес несколько отличных ответов, я думаю, что он заслуживает обновления для WildFly (и на самом деле наши внутренние проекты откладывают переход от 4.2.x до 7.x как изначально планировали ждать WildFly). Новые идеи и ответы приветствуются.

4b9b3361

ОТВЕТЫ

Ответ 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>