Posts Tagged ‘JSF’

h1

JSF with JSP 2.1 on Sun App Server 9.1

06/24/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks

SP

Versión en Español

Otra vez la burra al trigo[1]. Now, a user needs to publish a web service implemented in XFire and two Web applications that include Java Server Faces, Spring and Hibernate on an application server; As we were originally asked for Weblogic licenses, we said to ourselves "ummm… we should include a Sun Application Server quotation instead, to see if they like it". Of course, considering they needed 10 licenses, the amount saved by our customers is pretty step (more than US$100,000 in savings) and we were asked for a small proof of concept (POC) that included load testing to see if the App Server was well suited to their needs.

As I had to do some juggling bringing together people from development, application support and infrastructure, I could not perform the tests as I wanted and I opted instead for the installation of two working instances of the last versions of the Application Server (8.2 and 9.1), in such way that they will eventually perform their own tests. I hope that by speaking with the department manager it is easier to close the deal, and I no longer have to be dealing with these boys. This is because every minute they keep annoying me with comments like "hey, I can do this with Weblogic, you can’t do it with your application server, do you?" and obviously I have to show them you can – as a reference, the Sun Application Server 9.1 is the equivalent in almost all functionality aspects to the Weblogic 9 – but the explanations consume a lot of my time and we can’t move forward with the installation and testing.

The technicalities

When deploying the web application on the Sun Application Server 9.1 it throws the following error:

[#| 2008-03-11T19:11:19.343+0000 | SEVERE | sun-appserver9.1 | javax.enterprise.system.container.web | _ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-0;_RequestID=5b0615d8-92de-49d1-b74a-c07777fc1175; | StandardWrapperValve[jsp]: PWC1406: Servlet.service() para el servlet jsp desencadenó una excepción

org.apache.jasper.JasperException: /WEB-INF/tags/ext/body.tag(104,4) PWC6038: "${empty(extLocation)?"js/ext-2.0":extLocation}" contiene expresiones no válidas: javax.el.ELException: Error Parsing: ${empty(extLocation)?"js/ext-2.0":extLocation}

at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:62)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:357)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:169)

Where the code snippet that is the root of the problem is as follows:


 98 <%@ include file="inc/taglibs.jsp" %>
 99 <%@ tag import="org.apache.commons.beanutils.BeanUtils, java.util.Scanner"
100   dynamic-attributes="dynamicAttributes"
101   description="" %>
102
103 <c:set var="extLocation">
104   ${empty(extLocation)?"js/ext-2.0":extLocation}
105 </c:set>
106
107 <link rel="stylesheet" type="text/css" href="${extLocation} /resources/css/ext-all.css" />

And although at first glance there is nothing wrong with it and in some forums it is recommended to configure the web.xml to prevent expression parsing among the jsp tags, the real source of the problem has to do with the JSP specification, which is the version 2.1 for the Sun Application Server 9.1; the libraries that throw this kind of errors are written with the JSP 2.0 Specification.

The solution

The amazing news is, the new JSP Specification for JEE 5 requires spaces for the ternary operator (<expression> ? <if true> : <if false>). Therefore, if we change the previous code snippet with the following:


 98 <%@ include file="inc/taglibs.jsp" %>
 99 <%@ tag import="org.apache.commons.beanutils.BeanUtils, java.util.Scanner"
100   dynamic-attributes="dynamicAttributes"
101   description="" %>
102
103 <c:set var="extLocation">
104   ${empty(extLocation) ? "js/ext-2.0" : extLocation}
105 </c:set>
106
107 <link rel="stylesheet" type="text/css" href="${extLocation} /resources/css/ext-all.css" />

The application should work correctly. Note: You may need to do the same "space adding" scheme in more than one configuration file in order to prevent any error of this kind from happening again.

Conclusions

Although I do not know the JEE 5 Specification cin all its extent, it is unusual that it has problems with the OGNL libraries such as this, which are practically the base of any web framework like Struts or Tapestry. In the meantime, I am waiting for these "kids" to end up their load tests successfully so I can go with the Head Honcho to tell him "Did you see? Everything works just as fine; please sign this cheque here."

h1

JSF con JSP 2.1 sobre Sun App Server 9.1

03/11/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks

EN

English Version

Otra vez la burra al trigo. En esta ocasión, un usuario necesita publicar un web service en XFire y dos aplicaciones web que incluyen Java Server Faces, Spring y Hibernate sobre un application server; Como originalmente nos pidieron licencias de Weblogic, dijimos "mmm…¿por qué no también les hacemos una cotización con el Sun Application Server, a ver si les gusta?" Por supuesto que considerando que son 10 licencias, el ahorro de nuestros usuarios es considerable (más de US$100,000) y nos pidieron hacer una pequeña prueba de concepto que incluyera carga para ver si dicho App Server les conviene.

Como tuve que hacer algunos malabares juntando a gente de desarrollo, soporte aplicativo e infraestructura, no pude realizar las pruebas como quería y mejor les dejé las dos últimas versiones del Application Server (8.2 y 9.1) instaladas y funcionando y ya ellos harán sus pruebas. Espero que hablando ya con el director del área me sea más fácil cerrar el business y no tener que estar lidiando con estos chavos. Esto porque a cada ratito me sacan la de "oye, esto sí lo puedo hacer con Weblogic, ¿a poco no se puede con el tuyo?" y obvio que tengo que comprobarles que sí se puede – como referencia, el Sun Application Server 9.1 es equivalente en prácticamente todos los aspectos al Weblogic 9 – pero consume mucho de mi tiempo y no podemos avanzar con la instalación y pruebas.

Lo técnico

Al deployar la aplicación web en el Sun Application Server 9.1 aparece el siguiente error:

[#| 2008-03-11T19:11:19.343+0000 | SEVERE | sun-appserver9.1 | javax.enterprise.system.container.web | _ThreadID=21;_ThreadName=httpSSLWorkerThread-8080-0;_RequestID=5b0615d8-92de-49d1-b74a-c07777fc1175; | StandardWrapperValve[jsp]: PWC1406: Servlet.service() para el servlet jsp desencadenó una excepción

org.apache.jasper.JasperException: /WEB-INF/tags/ext/body.tag(104,4) PWC6038: "${empty(extLocation)?"js/ext-2.0":extLocation}" contiene expresiones no válidas: javax.el.ELException: Error Parsing: ${empty(extLocation)?"js/ext-2.0":extLocation}

at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:62)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:357)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:169)

Donde el fragmento de código que genera el problema es el siguiente:


 98 <%@ include file="inc/taglibs.jsp" %>
 99 <%@ tag import="org.apache.commons.beanutils.BeanUtils, java.util.Scanner"
100   dynamic-attributes="dynamicAttributes"
101   description="" %>
102
103 <c:set var="extLocation">
104   ${empty(extLocation)?"js/ext-2.0":extLocation}
105 </c:set>
106
107 <link rel="stylesheet" type="text/css" href="${extLocation} /resources/css/ext-all.css" />

Y aunque a primera instancia no se ve nada extraño y en algunos foros recomiendan configurar el web.xml para que no parsee las expresiones de los jsp tags, en realidad el problema tiene que ver con la especificación JSP, que para el Sun Application Server 9.1 es la versión 2.1 y las librerías que marcan este tipo de errores están compiladas con la especificación JSP 2.0.

La solución

Lo más sorprendente es que la nueva especificación para J2EE 5 requiere espacios para el operador trinario (<expresión> ? <if true> : <if false>). Por lo que si cambiamos el código previamente mostrado por lo siguiente:


 98 <%@ include file="inc/taglibs.jsp" %>
 99 <%@ tag import="org.apache.commons.beanutils.BeanUtils, java.util.Scanner"
100   dynamic-attributes="dynamicAttributes"
101   description="" %>
102
103 <c:set var="extLocation">
104   ${empty(extLocation) ? "js/ext-2.0" : extLocation}
105 </c:set>
106
107 <link rel="stylesheet" type="text/css" href="${extLocation} /resources/css/ext-all.css" />

La aplicación deberá funcionar correctamente. Nota: Es posible que sea necesario hacer esta misma "adición de espacios" en más de un archivo de configuración para que se elimine cualquier error de este tipo.

Conclusiones

Aunque no tengo bien al 100% la especificación J2EE 5, me causa extrañeza que tenga problemas con las librerías OGNL como ésta, que son prácticamente la base de cualquier framework web como Struts o Tapestry. Por lo pronto, a ver que las pruebas de estos "niños" terminen satisfactoriamente para que pueda llegar con el patrón a decirle "¿Vio? todo funciona muy bien; firme el cheque aquí por favor."

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.