h1

Java Server Faces sobre Sun Application Server: ¿Vale la pena?

06/29/2007

Wizdoc [Icon By Buuf]  Tips & Tricks
Java Server Faces: El último grito de la moda

Continuando con mis labores de Software Architect/SQA/Application Server Administrator (o simplemente, maistro albañil como decimos por aquí), me ha tocado la nada fácil tarea de hacer funcionar una implementación de Java Server Faces sobre el Sun Application Server 8.2. Para los neófitos en el asunto, JSF (JSR 252 para la versión 1.2 de dicha especificación) básicamente define cómo construir un framework MVC basado en eventos y componentes parecido a Tapestry, al contrario de frameworks basados en operaciones como es el caso de Struts.

El conflicto

Pues bien, ésta muy particular implementación de JSF incluye las librerías de Oracle (Oracle ADF Faces) así como de Apache (Apache MyFaces Project). El porqué de incluir ambos frameworks en una misma aplicación es todo un misterio (ya nos hemos puesto algunos madrazos el dueño de la aplicación y yo, pero eso viene más adelante), y me quisieron aplicar la de "… pues sentimos que el Application Server de Sun no está dando el ancho, y recomendamos pasarnos a Weblogic o Tomcat porque ellos sí soportan nuestra aplicación…"

¿Que que que? ¿Pardone moi? ¿Darle entrada a la competencia sólo porque estos weyes no saben cómo deployar su aplicación en SJSAS 8.2? ¡De ninguna manera! Se las voltee: "…Dame tu WAR; les aseguro – al tipo este, mi sponsor y al dueño del proyecto por parte del cliente – que en dos días tengo la aplicación corriendo en el Application Server, y tengo plena confianza en que las broncas son porque has de tener algún batidillo ahí adentro."

Je je, creo que la regué, pues no sólo puse en juego el honor de mi empresa, sino el de mi persona; en caso de no lograr el famoso deploy posiblemente hubiéramos perdido en grande, pues el dueño de la aplicación es uno de los gerentes de desarrollo que nos han apoyado desde el principio y en caso de quedar mal con él, muy difícilmente nos hubiésemos recuperado.

La Victoria

Después de sudarle un buen, estar al borde de tirar la toalla e incluso no poder disfrutar plenamente de la grata sorpresa del México-Brasil de ayer, me apliqué un sombrerito. Hoy hice entrega de la aplicación corriendo, y mandé un correo diciéndole a estos cuates que "… además de no apegarse a la especificación J2EE, que ya de por sí es malo, la aplicación contiene errores de diseño e implementación que difícilmente un programador amateur pasaría por alto…". ¡Goooooooool! (Sobra decir que ya no tuve que lidiar con estos cuates; sólo mandé un correo indicando los detalles de la aplicación a mis clientes, quienes por cierto le metieron una chinga a aquéllos por decir burradas sin estar plenamente informados).

Un Huevo Duro - galerias.ojodigital.com
Hay dos cosas infinitas: el Universo y la estupidez humana. Y del Universo no estoy seguro — Albert Einstein

Qué tenía y cómo se solucionó

Pasando al aspecto técnico, la aplicación tenía varios detalles cuya resolución es difícil de encontrar pues son bugs poco documentados:

1. Excepción relacionada a los drivers de JDBC de Oracle 10g:

java.lang.SecurityException: Sealing violation exception

2. Excepción lanzada en tiempo de ejecución al acceder a la página principal de la aplicación y que tenía que ver con la implementación de JSF:

Exception in PhaseListener RESTORE_VIEW 1 afterPhase
java.lang.NullPointerException at …

3. Warnings asociados al Digester de Apache commons que no se veían bien (Tip: siempre que sale un null en el log, es bueno revisar si no hay algo mal):


WARN org.apache.commons.digester.Digester – [ConverterRule]{faces-config/converter} Merge(null,java.math.BigDecimal)
WARN org.apache.commons.digester.Digester – [ConverterRule]{faces-config/converter} Merge(null,java.math.BigInteger)

La solución de los tres está directamente relacionada a las librerías de la aplicación (cabe mencionar que el WAR que me entregaron pesaba 32 MB de JARs y sólo 400 KB de código efectivo).

Tip: Para frameworks y librerías que no se generan por compilación, es mejor idea dejarlas en el path del dominio de la aplicación (no en el WAR por aspectos de desempeño ni en el classpath del servidor por aspectos de reutilización del ambiente).

La solución se da casi en automático:

1. Los JARs de conexión a base de datos de Oracle 10g del application server chocaban con tres archivos de drivers que tenía la aplicación. Oracle recomienda que para este error, se elimine del classpath (de servidor, de dominio y dentro del WAR) cualquier otro driver de JDBC que no sea el correspondiente a Oracle 10g.

2. Los JARs con la implementación de Java Server Faces dentro de la aplicación (5 en total, incluyendo los de Oracle así como los de MyFaces) chocaban con la implementación ya incluida en el SJSAS 8.2. Por esto no tronaba en Tomcat 6 o en Weblogic 8: ambos servidores no soportan JSF out-of-the-box, por lo que el deployment funcionaba en ellos sin problemas. Para este caso particular, tuve que eliminar[1] las librerías con la implementación de JSF del Sun Application Server.

3. Los warnings desaparecieron al corregir el punto 2.

Punto extra: de 68 JARs que contenía la aplicación sólo se requerían 14; los demás se incluyeron porque supongo que formaban parte del template o proyecto base que utiliza el proveedor; sin embargo creo que se le olvidó al arquitecto borrar lo que no se necesitaba (un error muy común pero que puede tener repercusiones muy serias, como es este caso).

Excelente! Pero… ¿Valió la pena? (Comercialote para Apache Tapestry)

Finalmente, la aplicación que instalé tiene integrados Spring y Hibernate (aunque todavía en etapa de desarrollo temprano). El cómo se resolverán los detalles de integración… me imagino que será todo un show (pero seguramente tendré que volver a defender las bondades del SJSAS). Lo que sí es una realidad es que estos cuates necesitan un nuevo arquitecto porque están reinventando la rueda con algo que ya existe desde hace rato: Apache Tapestry.

Hace poco más de 5 años aprendí a usar el framework de desarrollo Tapestry y leyendo la especificación de JSF me pude dar cuenta que prácticamente estaban describiendo los inner workings de aquél. Tomando eso en consideración, ¿no sería más productivo instalar un Tapestry que un remedo mal parchado de una especificación que pocos conocen? Por experiencia, Tapestry siempre ha sido mi elección en cuanto a MVCs, porque además tiene integración con Spring y Hibernate, es fácil de aprender y es muy flexible. Yo creo que este framework será el heredero de Struts, pues ya está a medio camino entre un MVC convencional y una implementación madura de JSF. Para terminar, incluso existe en The Server Side una comparación entre JavaServer Faces vs. Tapestry, ¿y quién creen que gana? ;D).


Notas y Pies de página

1. Es necesario aclarar que de acuerdo a las licencias del Application Server, al hacer esto [quitar librerias del Sun Application Server para que un framework de terceros pueda funcionar] puede cancelarse el soporte hacia el producto.

2 comentarios

  1. Hola yo tengo un problema como el del caso 2 que mencionas, solo que en mi caso el nullpointerexception del phaselistener como bien dices esta poco documentado, no funciona en tomcat pero si hago el deployment con glassfish a pesar de mandar algunas excepciones si funciona, con tomcata al momento de realizar el logueo truena, en la pagina no se ven estos errores pero si me voy al reporte de netbeans se ven los nullpointerexception, en tu blog hablas de que eliminaste las librerias JSF del Sun Application Server, la pregunta es las reemplazaste o simplemente les diste cuello, y si fue asi cuales son estas, disculpa mi ignorancia pero soy nuevo en faces y me he topado con muchas broncas con este framework, sin embargo soy muy persistente en querer usarlo jajaja

    Sin mas por el momento, me despido, de antemano gracias por la antencion


    • En su momento borre por completo los jars con la implementacion de jsf del application server, aunque esto era para demostrar que el problema estaba en la aplicacion, no en el servidor. En tu caso puntual, es posible que de la misma manera, alguno de los jars contenidos en el war de tu aplicacion contenga alguna implementacion puntual de jsf, que esta chocando con la version que viene con tu tomcat/netbeans.

      Ahora bien tengo entendido que por default, tomcat no soporta jsf, por lo que no trae ningun jar con la implementacion de jsf. lo que si puede estar pasando, es que si lo estas corriendo desde netbeans/eclipse, tu classpath esta apuntando a los jars de netbeans, lo que podria estar causando el conflicto. Te recomiendo buscar los siguientes jars y quitarlos del path (o moverlos a un directorio fuera del classpath) para ver si estos son los culpables.

      Los jars mas conocidos de jsf incluyen a:

      jsf-api.jar
      jsf-impl.jar

      mas otros jars comunes que no es conveniente borrar nunca:

      commons-beanutils.jar
      commons-collections.jar
      commons-digester.jar
      commons-logging.jar

      de hecho, si los encuentras repetidos, es un poco mas seguro borrar los que estan dentro del war.



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: