Beneficios (y consejos) de una actualización de JBoss 4.2.x a JBoss 5.x, 6.x, 7.x y WildFly 8.x?

Question

Supongamos que no tengo que preocuparme por el tiempo y los costos de desarrollo: Estoy interesado en los beneficios técnicos generales (mejor rendimiento, mejores API mejoradas) y nuevas características.

Actualmente estoy trabajando en productos que utilizan 4.2.x, y consideramos un cambio importante para las versiones que están por llegar y necesitan converger.

Eché un breve vistazo a las notas de la versión de cada versión y algunos artículos sobre cada versión para 5.x, 6.x, 7.x y 8.x. Pero me gustaría recibir comentarios de primera mano de personas que han realizado el cambio.

Me di cuenta de que hay algunos cambios importantes en relación con la mensajería (cambio de JBoss MQ a JBoss Messenging), y que para JBoss 7.x parece cambiar bastante su capa de configuración. Luego están sucediendo muchas más cosas al cambiar a JBoss/WildFly 8.x.

Por favor, recomendamos buenos artículos que señalen las trampas si es posible. Encontré algunas para migraciones a JBoss 5.x, pero no tantas para 6.x o incluso 7.x, y alguien más está evaluando 8.x para nosotros ahora. También puede recomendar alternativas si cree que son relevantes, aunque preferiría centrarme solo en JBoss.

Para información, utilizamos una mezcla de sistemas basados ​​en plugins JPF y OSGi (usando Eclipse Equinox), con clientes desarrollados en Swing (algunos implementados a través de WebStart).

Actualización: Aunque esta pregunta trajo algunas respuestas ya, creo que se merece una actualización para JBoss (y, de hecho, nuestros proyectos internos retrasó hacer el cambio de 4.2.x 7.x como originalmente se planeó que esperar Vuelo salvaje). Nuevos pensamientos y respuestas son bienvenidos.

Answer 1

he aumentado de JBoss 4 a 5 y de la experiencia los siguientes son los más importantes para tomar nota:

• JBoss 5 (y 6 y 7) no son tan indulgente como JBoss 4 con archivos XML. Debe asegurarse de que todos los archivos XML del descriptor de despliegue sean válidos. Puede que esté utilizando DTD en algunos archivos. Recomiendo actualizarlos para usar el esquema XML.
• Algunas bibliotecas pueden causar incompatibilidades. Esto puede ser particularmente cierto si accede a los servicios web y/o realiza el análisis XML
• Si precompila sus JSP en JBoss 4, probablemente no podrá hacerlo en JBoss 6/7.
• JBoss 4 y 5 utilizan diferentes implementaciones de cola de mensajes. Si tiene colas de mensajes o temas definidos, deberá redefinirlos.
• JBoss TreeCache ya no se utiliza. Si usa esto para el almacenamiento en caché, deberá cambiar para usar el nuevo caché de JBoss.
• La seguridad de JBoss 5 es diferente. Si sus clientes remotos requieren acceso seguro a JBoss, deberá configurarlos de manera diferente.

Algunos recursos útiles son:

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

Oficialmente JBoss 6 sólo está certificado para el perfil web de Java EE, por lo que si se utilizan las funciones "legado" como EJB 2.x, es posible que no sean compatibles en el futuro. Dependiendo del ciclo de vida de su aplicación, esto puede o no ser un problema. JBoss 6 actualmente es compatible con EJB2.1 por completo, pero no está certificado contra esto.

También he encontrado que JBoss 5 se ocupa de la memoria mucho mejor que JBoss 4. Con JBoss 4 Veo mucho más PermGen errores que yo con JBoss 5.

Answer 2

sólo puedo hablar de la experiencia de producción con JBoss 5.1.0 y algo de investigación de la versión 6.

JBoss 5 es Java EE 5 y JBoss 6 y 7 son Java EE 6. La disparidad en las características de API está mejor documentada en esas especificaciones. Es probable que JBoss 6 tenga una vida útil muy corta; es only certified for the Java EE 6 web profile y las correcciones de errores se están dirigiendo a la versión 7 (en su 3ª versión beta al momento de escribir).

Creo que obtendrías mejores respuestas en el foro de la comunidad JBoss.

Answer 3

He aquí un interesante hilo en JBoss AS 7 compromisos y futuro, mencionando también problemas con AS y AS 5 6:

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

Answer 4

Sólo quería llevar esto a la atención de cualquiera que pudiera estar enfrentando PermGen tema hinchazón después de actualizar a la última. El Microcontenedor JBoss-6 intenta buscar anotaciones específicas de Jboss cargando las clases de todos los JAR en la ruta de clase al inicio. Esto hace que la inflamación de PermGen comience a cargar todas las clases no deseadas. Para reducir la cantidad de escaneo, el Microcontenedor proporciona otro gancho de descripción, mediante jboss-scanning.xml. Agregue este 'jboss-scanning.xml' al WEB-INF dentro de WAR y ascle 'jboss-scanning.xml' al META-INF dentro de los EAR.

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

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

</scanning> 

Answer 5

Nos pasaron de JBoss AS 5 a 7 JBoss AS y se presiente hacia JBoss AS 8.1. En este momento no podemos migrar a 8 porque no hay MQ Series JMS 2 RAR.

Algunas de las diferencias:

• La configuración es mucho mejor y más simple. Ya no está distribuido en 20 archivos XML en los que configura aspectos en archivos XML. En cambio, todo es un lugar central. Todos los puertos están configurados en un lugar central, ya no existe un archivo XSL que transforma server.xml. Puede dar sentido al archivo de configuración sin conocer los detalles de implementación de las clases. Es difícil apreciar esto si nunca has configurado un JBoss 5.x.
• El modelo de carga de clases parece cuerdo y se obtiene una gran cantidad de control a través de jboss- despliegue a structure.xml
• El registro centralizado (SLF4J, Jul, JCL, Log4j, ...) es muy agradable.
• La biblioteca del cliente EJB parece mucho más limpia. Se han reducido a 10 JAR de 20, la mitad de ellos incluso paquetes OSGi (nuestro cliente es una aplicación Eclipse RCP).
• El lío de dependencia del cliente de EJB se ha ido, en su lugar ahora obtiene un BOM POM.
• Obtiene un BOM POM para las API del servidor.
• Inicio más rápido y menos uso de memoria. Desplegamos 80 EJB y el RAR de la serie MQ en 6 segundos sin mucha afinación. Nuestro conjunto de datos en vivo está en algún lugar por encima de 200 MB.
• La carpeta de implementaciones está vacía de forma predeterminada
• La (falta de) calidad de XNIO da miedo. En 7.x solo se usa para la comunicación remota EJB y acertamos varios errores de tope de show (deadlocks, double free, socket handle leaks, ...). En 8.x, también se usa para servlets en lugar de Tomcat. Todavía hay muchos errores de servlets muy básicos que se arreglan en undertow.

Los cambios que tuvimos que hacer nuestra aplicación:

• cambiar los nombres JNDI de EE 6 nombres normalizados
• migran desde JBoss Cache a Infinispan (parte de nuestro código se ha migrado a la API plana , algunas partes todavía utilizan la API de árbol)
• seguridad es un poco menos flexible (ya no se puede arreglar autenticado y llamadas no autenticadas)
• algún código horrible que se basó en datos de JNDI remoto
• la configuración del cliente EJB es diferente
• todos ustedes guiones para instalar, implementar, iniciar, detener, ...
• ExternalContext se ha ido, tuvimos que reemplazarlo con un enfoque diferente
• reemplazamos MBeans en los SAR con @StartUp EJB
• algunos hacks feo para Cocoon

la serie como 7.x tiene mucho de errores con correcciones sólo está disponible en la serie EAP. Si desea ir con 7.x en lugar de 8.x, le recomendamos encarecidamente que compre EAP 6.