Glassfish v2 en producción
La semana pasada salió la versión final de glassfish v2, y aprovechando la ocasión decidí instalarlo para un nuevo proyecto que he comenzado en NHT-Norwick y que cuenta con varios servicios Web.
La integración netbeans 6 / glassfish es perfecta (no podía ser de otra forma) y desarrollar servicios web con JavaEE5 es de lo más sencillo
El único problema que tuve fue con la instalación del enlace mod_jk para glassfish, que obliga a introducir commons-logging dentro de las librerías del servidor y esto produjo conflictos con el log4j de mi aplicación. La solución fue mover log4j a las librerías del servidor para que lo cargase el mismo ClassLoader que commons-logging. La verdad es que había olvidado este tipo de problemas con los ClassLoaders desde que abandonamos el desarrollo de aplicaciones con EJB1.x y 2.x sobre JBoss, esperemos que solo fuese un susto ;-)
Por lo demás, sigo notando un poco lenta la interfaz de administración, pero me encuentro bastante cómodo con la interfaz de comandos, asadmin, así que posiblemente solo la use puntualmente para visualizar las estadísticas de los servicios Web.
Hola lasterra:
Supongo que es porque desconozco tu configuración del sistema, pero ¿no te hubiera sido suficiente un ProxyPass de Apache WebServer?
Un saludo
Enviado por Manuel J. Recena Soto en septiembre 28, 2007 a las 09:35 AM CEST #
Hola Manuel, hay varias razones para usar mod_jk
1.- En principio creo que mod_jk y su protocolo AJP son más eficientes que hacer una redirección proxy/http
2.- Con mod_jk puedes hacer cosas que creo son imposibles vía mod_proxy, como balanceo de carga entre nodos de un cluster.
3.- Como he dicho, la idea de utilizar glassfish es facilitar el desarrollo de los servicios Web, y aquí encontre un problema con mod_proxy. Al generar glassfish el WSDL del servicio web, crea como dirección de acceso la url y puerto de glassfish, y por tanto en caso de ponerlo detrás del apache, es una URL "interna" y/o un puerto no público.
Según la documentación (en el panel de administración no se ve), existe un parámetro en la configuración del listener (external-port) que debería de prevenir el problema del puerto (esta opción existe en Tomcat, proxy-port) pero no funcionaba o no lo hice funcionar. Tengo que estudiarlo un poco más para reportar el bug y/o mejora.
Un saludo.
Enviado por lasterra en septiembre 28, 2007 a las 11:06 AM CEST #
Depende tambien un poco de la configuración que tengas que montar. En mi caso ataco unos 8-9 servidores de aplicaciones distribuidos por detras, en algunos casos con diferentes versiones, así que hemos optado por el ProxyPass.
Como tenemos las distintas versiones y el pequeño overhead de rendimiento no es un problema, pues nos va estupendamente.
Lo del external-port espero que lo arreglen por que si no es un obstaculo gordo. Pero bueno, nosotros no usamos Glassfish asi que... ;)
S!
Enviado por GreenEyed en septiembre 29, 2007 a las 03:15 PM CEST #