Muy buenas.
En mi empresa hemos heredado una aplicación que lleva varios años desarrollándose y manteniéndose.
La tecnología que se utiliza es JSF 1.2 + Apache Trinidad 1.1.13 + Spring 2.5.6 (con Spring Security) + EJB 3.0 + JPA/Hibernate (nunca sabré porque mezclaron Spring y EJB 3.0).
El contenedor de aplicaciones utilizado es JBOSS 5.1, pero nos pedirán migrar al 7.1 en breve.

La cosa es que vamos a proponer migración tecnológica, de JSF 1.2 a 2.0 (y su correspondiente migración de Apache Trinidad). Pero he visto que hay problemas de comunicación entre Spring 2.5.6 y JSF 2.0, por lo que habría que migrar la versión de Spring también (de la 2 a la 3 creo que cambian algunas cosillas, ¿no?).

Además, el formato de las páginas de la aplicación es ".jspx", lo que también da conflictos con la nomenclatura EL de JSF. Sería necesario cambiar las extensiones de los archivos por "xhtml".

En resumen, habría que liar un buen pitote. Solo para cambiar de versión de JSF.
Más adelante es posible que haya una nueva refactorización, para eliminar Spring y quedarnos solo con EJB (al utilizar interfaces remotas, no se puede eliminar EJB y dejar Spring, creo).

La cosa es, ¿creeis que merece la pena la migración tecnológica en estos casos?. La aplicación tiene un contrato por varios años... Y no se si viene bien "sanear" los frameworks utilizadfos de vez en cuando, aunque su coste sea elevado para lo que va a aportar al usuario final (nuestro cliente, en este caso).

¿Que opinais?.
¿Creeis que merecen la pena las migraciones propuestas?.
JSF 1.2 -> JSF 2.0
JBoss 5.1 -> JBoss 7.1
EJB + Spring -> full EJB 3.0

Un saludo, y gracias.

Comentar también que la aplicación sufre algunas penalizaciones de rendimiento.
No se si el cambio de versión de JSF (o Spring, o JBoss) pueden afectar positiva o negativamente a dicho rendimiento.

Hola,

En lo que respecta a JSF, no, no creo que merezca la pena el cambio. No es solo cambiar la nomenclatura de archivos, implica bastantes más cosas (estas pasando de jsp a facelets) y seguramente acabarías tocando todas y cada una de las páginas, con la pesadilla que puede ser eso.
Por otra parte la única diferencia importante de JSF 2.1(si te vas a meter en actualizar, actualiza a la última, no te quedes en medianías) es en general más facilidad para la interacción mediante ajax, con lo cual, ¿piensas reescribir todo el cliente para aprovechar estos cambios?
Sinceramente, creo que el pitote que quieres montar no esta justificado, ya puestos a sanear habría que sanear la arquitectura completa (como bien dices, esa mezcla de EJB y Spring suena rara y habría que ver si realmente se estan usando las interfaces remotas).
En cuanto al rendimiento... no tiene por qué tener nada que ver JSF ahí, tendrías que hacer un estudio de rendimiento para ver donde estan los problemas (me inclino más por esa capa de "negocio" sobredimensionada o incluso por JPA mal usado).

Un saludo.

Buenas.

Por otra parte la única diferencia importante de JSF 2.1(si te vas a meter en actualizar, actualiza a la última, no te quedes en medianías)

Pensé en JSF 2.0, y no la 2.1, porque en la página de Trinidad indicaba que era compatible con esa versión... No vi que fuera compatible con 2.1 (y tampoco quería arriesgarme). Pero si son compatibles... ¡mejor!.

En cuanto al rendimiento... no tiene por qué tener nada que ver JSF ahí, tendrías que hacer un estudio de rendimiento para ver donde estan los problemas (me inclino más por esa capa de "negocio" sobredimensionada o incluso por JPA mal usado).

Efectivamente, el problema de rendimiento es el negocio de la aplicación, muy mal diseñado. La mezcla aún no la entiendo bien. Pero si, se usan las interfaces remotas (de hecho, son el "nucleo" de la aplicación).
Además, para recuperar esas interfaces remotas usan JNDI en lugar de DI e IoC (pero eso es otro cantar). Pero si utilizar esta versión suponía (aunque fuera mínima) una mejora de rendimiento de algún tipo, podría usarlo para justificar el cambio.

La idea era ir haciendo migraciones poco a poco de los distintos frameworks (o ir eliminándolos directamente, prefiero EJB a Spring, pero es algo personal). De hecho la integración es tan poco "sutil" o "limpia" que tienen que utilizar interceptores en los beans EJB para enchufarle el EntityManager a los beans de Spring (que son los que finalmente realizan la persistencia.. vamos, un cacao). Y teniendo JBoss... pudiendo utilizar EJB y quitarnos las librerías de Spring del medio... (lo mismo opinais lo contrario, y veis más útil eliminar EJB).

Lo que me parecía más sencillo a priori era JSF, pero me da a mi que todo lo contrario, sería lo más costoso y no aportaría mucho respecto al esfuerzo que supondría.

Lo que no quería era que se conviertiera poco a poco en un "dinosaurio". Tenemos aquí aplicaciones con Struts 1, sin Spring, con conexiones JDBC, mal diseñadas, sin uso de patrones... (usar esas tecnologias no es necesariamente malo, pero nos supone una inversión extra de tiempo). Además, ya como profesionales, me parecía interesante ir actualizando nuestros conocimientos en los distintos frameworks y especificaciones.
Pero claro, este tipo de migraciones y actualizaciones suele correr de la cuenta de los miembros del equipo, y no del propio proyecto.

Seguiremos con la versión 1.2 de JSF entonces.

¡Muchísimas gracias por tu comentario!.