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."

One comment

  1. Generalmente en las versiones posteriores se van dando "ventajas" y comodidades en cuanto a la sintaxis. Esto es claramente un paso atras. Desconozco los motivos que llevaron a esto pero es muy incómodo.



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: