Una de la razones por las que usuaria Glassfish en vez de Tomcat sería la posibilidad de eliminar Apache y conseguir que mis aplicaciones corran completamente sobre la plataforma Java. A día de hoy todas mis aplicaciones usan Apache por la mejora de rendimiento al servir contenido estático y por la configuración de los VirtualHost de cada una de las aplicaciones. Si con Grizzly parece que el rendimiento del servicio HTTP/S de Glassfish parece que no va a ser un problema, veamos si su soporte de Virtual Hosts es suficiente.
Ya veíamos en el ultimo post que a través de la consola de administración podíamos configurar el servicio HTTP. Esta configuración se base en tres apartados:
- El propio Servicio HTTP donde podemos configurar:
- El sistema de logs de acceso a nuestras aplicaciones (rotado e información que se registra)
- Configuración del tratamiento de peticiones HTTP entrantes (RequestProcessing)
- Gestión de las conexiones "keep-alive" (configuración de timeouts, y limete de conexiones)
- Configuración del Pool de conexiones HTTP que están a la espera de recibir peticiones
- Definición de los valores por devolverá el servidor en las cabeceras HTTP
- Configuración de la cache de contenido estático para mejorar el rendimiento
- Listeners HTTP son sockets (IP+Puerto) que estan a la escucha de peticiones HTTP. Además de esta configuración un listener puede estar asociado a un VirtualServer / VirtualHost por defecto y a varios nombres de máquina. Todos los listeners utilizan la configuración del Servicio HTTP de Glassfish.
- Por último los Virtual Servers (Me gusta más el nombre de VirtualHost) son la configuración del direccionamiento de un dominio/host a uno o varios listeners. De esta forma asignamos la dirección de acceso de nuestras aplicaciones a una instancia de Glassfish. Un Virtual Server se puede asociar a una aplicación en concreto, por lo que al escribir el dominio se direccionaría a dicha aplicación montada como ROOT. Es importante destacar que tras cambiar la configuración de un Virtual Server no es necesario reiniciar Glassfish.
La verdad es que se pueden realizar las configuraciones básicas, yo diría que esta al mismo nivel del Tomcat pero con una administración más sencilla, pero sigo echando en falta algunas cosas que suelo usar en el Apache como por ejemplo la posibilidad de hacer redirecciones. Para solventar esto en glassfish podemos utilizar URLRewriteFilter, que es muy completo y funciona a las mil maravillas.
En cualquier caso, si las funcionalidades de Glassfish como servidor Web no te parecen suficientes o si bien necesitas Apache por otras razones, Glassfish soporta el protocolo AJP, por lo que puedes configurar el Apache con mod_jk por delante de el.
Para ello debemos seguir los siguientes pasos:
1.- Añadir una propiedad al lanzar la JVM a través de la consola de administración,
o desde la consola
$GLASSFISH_HOME/bin/asadmin create-jvm-options
-Dcom.sun.enterprise.web.connector.enableJK=8009
2.- Copiar desde Tomcat 5.5.x a %GLASSFISH%/lib las librerias
- %TOMCAT%/server/lib/tomcat-ajp.jar
- %TOMCAT%/server/lib/commons-modeler2.0.jar
3.- Copiar commons-logging.jar a %GLASSFISH%/lib
4.- Opcionalmente, configurar el conector AJP con un fichero de propiedades mediante la variable de la JVM
$GLASSFISH_HOME/bin/asadmin create-jvm-options
-Dcom.sun.enterprise.web.connector.enableJK.propertyFile=
/path/glassfish/domains/domain1/config/glassfish-jk.properties
La verdad es que esperaba un paso más por parte de Glassfish en este sentido. Siguen trabajando en ello y para la v2 se ha introducido el soporte de directorios virtuales, pero Apache sigue dando mucha más versatilidad. Veremos si Grizzly ahora independiente de Glassfish tiene también algo que decir.
Virtual Servers with Glassfish and/or Apache
