Блог

Пожалуйста, предположите, что мне не нужно беспокоиться о времени и затратах на разработку: меня интересуют общие технические преимущества (улучшенная производительность? улучшенные 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). Новые мысли и ответы приветствуются.

Я обновился с JBoss 4 до 5, и, исходя из опыта, наиболее важно отметить следующее:

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

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

https://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.

Я могу говорить только исходя из опыта работы с 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.

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

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

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

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

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

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

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

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

Просто хотел довести это до сведения всех, кто мог столкнуться с проблемой раздувания PermGen после обновления до последней версии. Микроконтейнер JBoss-6 пытается сканировать аннотации, специфичные для Jboss, загружая классы из всех JAR-файлов в пути к классу при запуске. Это приводит к раздуванию PermGen, поскольку он начинает загружать все ненужные классы. Чтобы уменьшить объем сканирования, Микроконтейнер предоставляет другой дескрипторный интерфейс посредством jboss-scanning.xml . Добавьте это ‘jboss-scanning.xml «для ВЕБ-инфы внутри войн и задницы»jboss-scanning.xml ‘ к META-INF внутри EARs.

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

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

</scanning>