Además asistiré a las sesiones magistrales impartidas después de las ponencias, donde algunos emprendedores de Internet con éxito nos hablarán de temas cruciales.

El programa completo ya es público y reconozco que en principio me gusta y me ilusiona (sí, así de bobo soy). Pase lo que pase, eso que me llevo. La semana que viene os contaré como ha ido.

Los cambios en esta versión se limitan a pequeñas correciones internas, que afectan mínimamente al usuario final. Las nuevas características que tenía planeadas para esta versión las trasladaré a la siguiente y asunto resuelto. La ventaja de crear tu propio producto

Ya estoy trabajando en un par de ideas que van a mejorar mucho la funcionalidad de la aplicación, espera un par de semanas y verás como la versión 0.5 sí que vale la pena.

>$ grails test-app

Con este comando ejecutamos todas las pruebas que tengamos definidas, las unitarias y las de integración. Cuando estás codificando las pruebas unitarias y quieres lanzarlas poco a poco resulta molesto tener que esperar a que arranque todo el framework y que se ejecuten también las pruebas de integración.

Si quieres ejecutar sólo las pruebas unitarias ejecuta el siguiente comando:

>$ grails test-app -unit

Para ejecutar sólo las pruebas de integración:

>$ grails test-app -integration

Y en cualquier caso, si quieres filtrar para ejecutar sólo las pruebas que has definido en un fichero, añade el nombre de dicho fichero al final de la línea de comandos (sin el sufijo “Tests“):

1
2
3

>$ grails test-app -integration MisPruebas
>$ grails test-app -unit MisPruebas
>$ grails test-app MisPruebas

El comando de la línea 1 ejecutaría las pruebas de integración definidas en el fichero MisPruebasTests.groovy. El comando de la línea 2 ejecutaría las pruebas unitarias definidas en el fichero MisPruebasTests.groovy, y el tercer comando ejecutaría todas las pruebas que hallara en un fichero con nombre MisPruebasTests.groovy. Recuerda que grails distingue entre las pruebas unitarias y las de integración en función de la carpeta en la que estén colocados los ficheros de prueba: test/unit para las primeras y test/integration para las segundas.

Además de seguir corrigiendo errores que detecto constatemente, las principales novedades de esta versión son:

• Posibilidad de mostrar todos los checkpoints de un quest desde el comienzo, nada de tener que superarlos secuencialmente.
• Tags para los quests.
• Mayor integración con twitter.
• Más facilidad para añadir quests a grupos de quests y a la listas de objetivos de los clanes.
• Exportación en CSV de datos estadísticos de los quests.

Continúa leyendo el post para ver los detalles de cada punto.

Posibilidad de mostrar todos los checkpoints de un quest desde el comienzo

Hasta ahora los checkpoints debían ser superados por los jugadores en el orden que el creador los había colocado. No existía la posibilidad de intentar resolver un checkpoint posterior si no se habían superado con éxito todos los anteriores. La alternativa que se presenta a partir de esta versión es la de ofrecer a los participantes todos los checkpoints desde el principio, permitiendo que intenten resolverlos en el orden que quieran. Los creadores podrán configurar este aspecto en el momento de crear los quests.

Si se hace uso de esta nueva funcionalidad, al acceder a la página del quest los participantes verán algo parecido a lo mostrado en la siguiente imagen.

La columna “Estado” muestra algunos iconos que representan información intesante:

• El usuario no ha superado aún el checkpoint.
• El usuario ha superado el checkpoint.
• El usuario no ha superado aún el checkpoint y ha sobrepasado el número máximo de intentos, por lo que deberá esperar un tiempo para poder volver a intentarlo.

Tags para los quests

Los creadores podrán asociar a cada uno de sus quests un conjunto de tags o etiquetas. Estos conjuntos podrán ser editados en cualquier momento por los creadores desde la página de edición del quest.

Cualquier usuario podrá acceder al conjunto de quests etiquetados con un determinado tag a través de URL’s sencillas de recordar similares a http://thuest.com/tag/el-tag

Los tags serán visibles en las páginas de los quests y en la página de inicio de sesión, donde se mostrará un subconjunto de los tags empleados en toda la aplicación.

Mayor integración con twitter

Ahora es posible recibir automáticamente notificaciones en twitter mediante Direct Messages, con información sobre eventos que pueden afectar al usuario, como la recepción de un mensaje privado de otro usuario, la republicación de un quest en el que participaba, la definición de un nuevo quest objetivo en un clan del que forma parte, etc.

Además, es posible mostrar en la página del perfil público del usuario el username de twitter.

Más facilidad para añadir quests a grupos de quests y a la listas de objetivos de los clanes

Este tema pedía una mejora como agua de Mayo. Ahora se proporciona un simple buscador con el que localizar los quests que estamos buscando. Una vez obtenidos los resultados, simplemente pulsando el icono el quest pasará a formar parte de nuestro grupo de quests o de la lista de objetivos para nuestro clan.

Exportación en CSV de datos estadísticos de los quests

Además de poder salvar los gráficos como imágenes ahora también es posible exportar los datos en formato CSV, lo cual facilitará su análisis offline.

Para ti…

Para terminar, de nuevo el avance en la definición y resolución de los issues asociados a esta versión. Para los morbosos.

Y ahora a por Thuest 0.4!

Son muchas las cosas que podemos probar y Grails nos ayuda en muchos temas específicos proporcionándonos clases de las que extender para desarrollar nuestros tests. Tendremos que dejar nuestras pruebas en los directorios test/integration o test/unit, siguiendo la jerarquía de paquetes de los elementos a probar y heredando de determinadas clases en función de lo que estemos probando:

• Clases de dominio: heredar grails.test.GrailsUnitTestCase
• Controladores: heredar grails.test.ControllerUnitTestCase
• Tag libs propias: heredar grails.test.TagLibUnitTestCase
• Servicios: heredar grails.test.GrailsUnitTestCase
• URL Mappings: heredar grails.test.GrailsUrlMappingsTestCase

Para lanzar las pruebas deberemos ejecutar la siguiente orden desde la línea de comandos:

$> grails test-app

En futuros posts iré hablando del resto de pruebas, pero ahora me centraré en las relacionadas con los mapeos de URL’s.

Por defecto los mapeos de URL’s en Grails se declaran en el fichero grails-app/conf/UrlMappings.groovy. Se pueden hacer muchas virguerías, pero eso lo dejamos para otra ocasión. Las pruebas que vamos a desarrollar tienen como objetivo asegurar el correcto funcionamiento de dos procesos que tendrán lugar en nuestra aplicación constatemente:

1. Extraer de la URL que llega al servidor en una petición los siguientes elementos: controlador, acción y parámetros.
2. Formar URL’s mediante algunos de los tags proporcionados por Grails, como <g:link> y <g:form>

Es necesario que nuestros tests sean de integración, pues necesitamos que todo el entorno de Grails esté operativo. Al fin y al cabo son sus librerías las que se encargan mágicamente de los dos puntos anteriores. Por lo tanto nuestros tests irán en la carpeta test/integration. Si hemos respetado el nombre del fichero de mapeos usado por defecto, bastará con que coloquemos en este directorio un fichero con el nombre UrlMappingsTest.groovy. En este fichero, todos los métodos que comiencen por test serán considerados pruebas y se ejecutarán una detrás de otra. Los demás métodos se ignorarán. Es posible definir los clásicos métodos setUp y tearDown, que se ejecutarán antes y después de cada prueba respectivamente.

Podemos probar por separado cada uno de los puntos antes comentados, usando el método assertForwardUrlMapping para el primer caso y el método assertReverseUrlMapping para el segundo. Pero en general podemos usar el método assertUrlMapping para ejecutar los dos tipos de prueba.

Utilizaré un ejemplo real de Thuest para ilustrar la explicación. Tenemos los siguientes mapeos definidos:

"/quest/$idText?"{
    controller = "quest"
    action = "show"
    constraints {
        idText(validator:{return !(it in CH.config.theq.urlMappingExceptions.quest)})
    }
}
"/quest/$action?/$idText?"{
    controller = "quest"
}

Con el primer mapeo, para todas las peticiones del estilo /quest/XXX se ejecutará la acción show del controlador quest, almacenando en params.idText el valor XXX como un String. Hay un restricción, según la cual cuando XXX sea alguno de los valores definidos en una lista que tengo declarada en la configuración de Grails (archivo grails-app/conf/Config.groovy), el mapeo no será válido, forzando a Grails a buscar otro mapeo.

El segundo mapeo es más genérico y sirve para capturar URL’s como /quest/listAsPlayer/user1.

La prueba que yo he definido para estos mapeos es la siguiente:

void testQuestMappings() {
    assertUrlMapping("/quest", controller: "quest", action: "show") {
        idText = null
    }
    assertUrlMapping("/quest/test", controller: "quest", action: "show") {
        idText = "test"
    }
 
    // Testing strings that mustn't be idText, because they are actions
    CH.config.theq.urlMappingExceptions.quest.each {action->
        assertUrlMapping("/quest/${action}", controller: "quest", action:action) {
            idText = null
        }
        assertUrlMapping("/quest/${action}/test", controller: "quest", action:action) {
            idText = "test"
        }
    }
}

Los parámetros que recibe el método assertUrlMapping son:

• Una URL o un código HTTP (por ejemplo 500 para casos de error o 404 para recursos no encontrados)
• controller: nombre del controlador en minúsculas
• action: nombre de una acción
• view: nombre de una vista
• paramAssertions: una closure con parámetros que esperaríamos tener en la acción (proceso ForwardUrlMapping) o que proporcioamos a tags como <g:link> y <g:form> para obtener una URL válida (proceso ReverseUrlMapping)

Lo primero que pruebo (líneas 2-4) es que cuando el usuario solicite la URL /quest se ejecutará la acción show del controlador quest, y que el parámetro params.idText será null. Ese caso yo lo tengo contemplado en mi acción, de forma que cuando params.idText no tiene valor hago una redicción a una página por defecto e informo de la situación anormal al usuario.

Al mismo tiempo estoy probando el ReverseUrlMapping, es decir, supongamos que tengo alguno de estos dos tags:

<g:link action="quest" controller="show" params="[idText:null]" />
<g:link action="quest" controller="show" />

Con mi test me aseguro de que la URL generada es /quest. Otra cosa es que esto tenga sentido. En mi caso debo controlar que nunca se genere esta URL porque no tiene sentido, pero si por algún casual mis controles son superados siempre se generará una URL válida.

La siguiente comprobación (líneas 5-7) me asegura que cuando la URL solicitada sea del estilo /quest/XXX se ejecute la acción show del controlador quest y que params.idText tenga el valor XXX.

Igual que en el caso anterior, también se comprueba que el ReverseUrlMapping es correcto, lo cual implica que si tengo el siguiente tag:

<g:link action="quest" controller="show" params="[idText:'mi-quest']" />

La URL que se generará será /quest/mi-quest. Perfecto.

El siguiente fragmento (líneas 10-16) se encarga de comprobar el correcto funcioamiento del mapeo para las excepciones definidas en mi lista de configuración. Estas excepciones se corresponden con todas las acciones que están en el controlador quest y que por tanto tendrán unas URL’s asociadas del estilo /quest/action/parameters. Si no tuviera definidas estas restricciones para el primer mapeo, URL’s como /quest/listAsPlayer/user1 terminarían invocando la acción show del controlador quest, estableciendo en params.idText el valor listAsPlayer.

Algunos imprevistos

Estas cosas no te las encuentras hasta que te pegas con ellas, pero si te puedo quitar un par de horas de curro mejor que mejor.

Error al comprobar el mapeo a un vista

Unos ejemplos típicos serían los siguientes:

1
2

assertUrlMapping(500, view: "error")
assertUrlMapping(404, view: "404")

Lo que se pretende comprobar es que cuando se produce una respuesta HTTP con código 500 la vista que se muestra es grails-app/views/error.gsp. Lo mismo para el código 404 y su vista asociada.

En el momento de escribir este post existe un bug en Grails que impide el correcto funcionamiento: GRAILS-4244. La solución rápida está en el enlace anterior: son necesarios dos import e incluir en el método setUp el siguiente código:

1
2
3
4
5
6
7
8
9
10

import org.springframework.core.io.FileSystemResourceLoader
import org.springframework.core.io.support.PathMatchingResourcePatternResolver
class UrlMappingTests extends grails.test.GrailsUrlMappingsTestCase {
...
    void setUp() { 
        super.setUp() 
        patternResolver = new PathMatchingResourcePatternResolver(new FileSystemResourceLoader())
    }
...
}

Comprobar realmente los parametros esperados en params en el proceso ForwardUrlMapping

Debido a otro bug en Grails, el método assertForwardUrlMapping no comprueba realmente que que el proceso de mapeo deje en el objeto ímplicito params los valores esperados.

La solución pasaría por emplear nuestra propia implementación de la clase grails.test.GrailsUnitTestCase, heredar de ella y modificar el código tal como se recomienda en la página del propio bug.

Terminando

Bueno, me ha salido un poco largo, pero creo que está bien como complemento a la documentación que se puede encontrar por Internet. Espero que te sirva de inspiración para hacer las pruebas de tus mapeos, en realidad son las más sencillas de hacer y te puedes evitar muchas sorpresas.

Contextualizemos: yo no sé Python, él no sabe Groovy, y probablemente el conocimiento que tiene él sobre Python es mayor que el que tengo yo sobre Groovy. Lo de Prolog tiene que ver con la universidad, el ansia por terminar prácticas y espinitas clavadas :-). Lo cierto es que hoy por hoy él controla mucho más que yo en programación lógica.

Quizás a alguien le resulte interesante, y en cualquier caso servirá en el futuro para recordar lo que éramos capaces de hacer (en ocasiones las mierdas del pasaso parecen ahora inalcanzables, no me lo negarás).

Conseguir una lista de 100 número aleatorios, ordenarla e imprimirla

Python

import random
print sorted(random.randint(0,2**31)for i in range(100))

Prolog

r([]).
r([H|T]):-random(0,1000000,H),r(T).
f(L):-length(X,100),r(X),sort(X,L).

Groovy

a=[]
100.times{a<<(int)(Math.random()*(2**31))}
print a.sort()

Encontrar el indice de una sublista dentro de otra

Python

def f(a,b):
 l=[a[i:i+len(b)]for i in range(len(a))]
 return b in l and l.index(b)or-1

Prolog

s(X,[]).
s([H|T],[H|U]):-s(T,U).
f(X,Y,0):-s(X,Y).
f([_|T],Y,N):-f(T,Y,M),N is M+1.

Groovy

def f(a,b){return Collections.indexOfSubList(a,b)}

• Más tipos de respuestas
• Conexión con twitter
• Ranking de jugadores en cada quest
• Nuevo criterio de búsqueda de quests: recompensas
• Búsquedas de usuarios
• Búsquedas en los foros

Continúa leyendo el post para ver los detalles de cada punto.

Más tipos de respuestas

Hasta ahora, en cada checkpoint sólo era posible introducir varias cadenas de texto simples como posibles respuestas válidas. Si el jugador introducía cualquiera de esas cadenas pasaría el checkpoint. En esta versión se han incluído tres opciones más:

• Texto multilínea: la respuesta correcta es un texto de varias líneas.
• Una opción entre varias: al usuario se le presentan varias opciones y tiene que elegir la única que es correcta.
• Una combinación de opciones entre varias: al usuario se le presentan varias opciones y tiene que seleccionar un conjunto de ellas.

La imagen muestra la edición de la respuesta de un checkpoint. Al usuario se le presentarán las cuatro opciones y tendrá que seleccionar Linus Torvalds y RMS para superar el checkpoint.

Conexión con Twitter

Desde la página del perfil del usuario es posible configurar una cuenta de twitter a la que enviar avisos automáticos sobre nuestra actuación en Thuest. Además no será necesario que nos proporciones tu nombre de usuario y password en twitter; gracias a OAuth en ningún momento tus credenciales pasarán por nuestras manos. ¡Mejor para todos!

Ranking de jugadores en cada quest

Cualquier usuario, haya iniciado sesión o no, podrá acceder a la lista de jugadores de un quest. Podrá aplicar filtros para ver únicamente los jugadores que le interesen (jugando, quet abandonado o quest completado).

Nuevo criterio de búsqueda de quests: recompensas

Ahora, desde la página de búsquedas avanzadas, es posible indicar si se desea encontrar únicamente quests con recompensas pendientes de ser asignadas. Especial para los cazatesoros

Búsquedas de usuarios

Junto a los enlaces para buscar grupos de quests y clanes se ha añadido una nueva opción: la búsqueda de usuarios. Las búsquedas se realizarán en los emails, apodos y descripciones de los usuarios, aumentando las probabilidades de éxito.

Búsquedas en los foros

Desde la página de cada foro será posible buscar temas y respuestas, exclusivas del foro en cuestión, que coincidan con nuestra cadena de búsqueda. Desde la página de cada tema también será posible buscar respuestas, de nuevo exclusivas del foro en cuestión.

Para ti…

Internamente se han realizado algunos cambios que resultan indiferentes para la mayoría de los usuarios de la aplicación pero que te pueden resultar interesantes a ti, que has llegado hasta este punto del post.

• Se ha actualizado la versión de Grails, de la 1.0.4 a la 1.2-M2.
• Se utiliza JMS para lanzar tareas asíncronamente, como el envío de emails.
• Los quests, grupos de quests, usuarios y clanes ahora tienen una url de visualización más sencilla, en la que se utiliza un identificador generado a partir del nombre. Por ejemplo: http://thuest.com/user/chechu. Más intuitivo y fácil de recordar.

Y para terminar, el avance en la definición y resolución de los issues asociados a esta versión. Para los morbosos.

Me he fijado un ritmo de 15 días por versión, así es que espero cumplirlo y anunciaros Thuest 0.3 en un par de semanas.

Los cambios en la nueva versión a los que me refería son básicamente la actualización a Grail 1.2-M2, con su nueva gestión de dependencias transitivas con ivy (que te trae más mierda de la que necesitas) y el uso de JMS mediante el plugin de grails.

Los pasos que sigo para desplegar son:

1. chechu$> grails clean. Limpio.
2. chechu$> grails get-dependencies. Me traigo todas las dependencias configuradas con ivy.
3. chechu$> sudo cp lib/xercesImpl-2.9.1.jar /opt/glassfish/lib; sudo cp lib/postgresql-8.3-603.jdbc4.jar /opt/glassfish/lib. Estos JARS los necesita la aplicación, pero colocarlos en el PATH del servidor ha sido la mejor forma con la que he conseguido que todo funcione.
4. chechu$> rm lib/xercesImpl-2.9.1.jar. Dejar este JAR en la aplicación entraba en conflicto con el servidor y lo dejaba inestable totalmente.
5. Edito el fichero .grails/1.2-M2/projects/theq/plugins/jms-0.5-RC2/src/groovy/grails/jms/listener/ListenerConfig.groovy e indico que no quiero asociar a los listener JMS que se creen automáticamente un gestor de transacciones. Para ello eliminio la línea 125 (transactionManager = ref(”transactionManager”)).
6. chechu$> grails war. Empaquetar.

Por otro lado preparo el servidor glassfish:

1. Elimino el despliegue anterior desde la consola web de glassfish.
2. Paro el dominio y el agente que gestiona la instancia
3. root$> rm -rf /opt/glassfish/nodeagents/agent1/instance1/applications/j2ee-modules/thuest-*. Elimino los restos de despliegues anteriores.
4. root$> killall java. Mato los procesos java que queden (con cuidado de que no tenga otras cosas de Java corriendo)
5. root$> ps aux | grep java. Me aseguro de que no queda nada corriendo de java, ni el imqbrokerd.
6. root$> asadmin start-node-agent agent1. Arranco el agente que gestiona la instancia.
7. root$> asadmin start-domain thuest. Arranco el dominio.
8. Creo los recursos JDBC y JMS. Para la connectionFactory de JMS me aseguro de que la opción Transaction Support está a NoTransaction. También me aseguro de asignar el target correcto para todos los recursos.
9. Reinicio el clúster (lo paro y lo arranco), para que acceda a la nueva configuración. Para todo por completo si es necesario.
10. Despliego la aplicación

Ficheros de logs interesantes:

• /opt/glassfish/nodeagents/agent1/instance1/logs/server.log. El destino del log de la aplicación
• /opt/glassfish/nodeagents/agent1/instance1/config/stacktrace.log. Donde se vuelcan las excepciones de la instancia 1.
• /opt/glassfish/nodeagents/agent1/instance1/imq/instances/myclusterinstance1/log/log.txt. El log del broker de JMS arrancado por glassfish internamente.

Además se repasan los pasos básicos para definir un clúster en glassfish y se dan algunos consejos sobre aspectos a tener en cuenta y que pueden provocar errores dificilmente detectables.

Comencemos por las rectificaciones al post anterior:

• No es necesario añadir returns en el código del plugin, tal cual viene compila perfectamente.
• Deshabilitar el transactionManager se convierte en obligatorio al intentar desplegar la aplicación en un clúster de Glassfish. Al trabajar con un clúster de Glassfish las opciones para el broker JMS son tres: EMBEDDED, LOCAL y REMOTE.

  La opción EMBEDDED no tiene sentido (al menos yo no lo veo) si tenemos un clúster, ya que cada broker JMS se ejecutará en la JVM de cada instancia, perdiendo así la posibilidad de distribuir la carga que nos da JMS.

  La opción REMOTE nos obliga a gestionar por nuestra cuenta un broker JMS mientras que con la opción LOCAL el propio servidor gestiona (arranca y para) un broker, concretamente ejecuta el binario imqbrokerd que viene en la propia distribución de glassfish.

  Nuestra opción ha sido LOCAL, que es la opción por defecto al trabajar con clústers en glassfish. Este mensaje da la pista sobre un posible problema con las transacciones en la configuración LOCAL y recomienda deshabilitarlas. Así lo hice y funcionó perfectamente. Se deshabilita en la web de administración de Glassfish, al crear el JMS connection factory y también tenemos que eliminarlo en el plugin de JMS instalado en nuestra aplicación (fichero ~/.grails/1.2-M2/projects/[proyecto]/plugins/jms-0.5-RC2/src/groovy/grails/jms/listener/ListenerConfig.groovy, línea 125 en la versión 0.5-RC2)

• Sobre los receptores de mensajes, hay que asegurarse de que el valor devuelto sea serializable y tener en cuenta que en groovy si se declara el método como def metodo... se devolverá el valor de la última sentencia ejecutada en el método. Para evitar problemas, podemos fijar el método como void.

Sobre los pasos a seguir para montar el clúster, podrían ser los siguientes:

1. Crear el dominio: asadmin create-domain --profile cluster --portbase 5000 thuest.
2. Crear el node-agent que gestionará la instancia: asadmin create-node-agent --port 5048 agent1
3. Crear el clúster: ya en la consola Web, Clusters -> New. Indicamos un nombre y en la sección de instancias a ser creadas también seleccionamos New, asociando la nueva instancia al agente creado en el paso anterior. Al crear el clúster la instancia creada a la par será arrancada automáticamente. Cuando tengamos que aplicar nueva configuración es mejor parar y arrancar el clúster completo que cada instancia (de hecho al parar y arrancar una instancia individualemente te dará un error sobre operación no permitida).
4. Aplicar configuración: parar y arrancar clúster (desde la consola web). Si deseamos parar y arrancar todo podemos usar la línea de comandos:
   • $> asadmin stop-node-agent agent1: para el agente agent1
   • $> asadmin stop-domain thuest: para el dominio thuest
   • $> killall java: a las bravas, mata todos los procesos java. Mucho cuidado porque esto afecta a procesos que a lo mejor no tienen nada que ver con glassfish
5. Balanceo con mod_jk. Ver este enlace para hacerse una idea. Será necesario establecer una propiedad JVM, lo cual se hace a nivel de clúster: desde la consola Web ir a Configurations -> mycluster-config -> JVM Settings -> JVM Options y añadir esto: -Dcom.sun.enterprise.web.connector.enableJK=${WORKER_PORT}. Ahora, para cada instancia habrá que definir una propiedad WORKER_PORT que es el puerto configurado en el mod_jk para un worker. Eso se hace desde la consola Web: Clusters -> mycluster -> instance1 -> Properties. Una vez creada la propiedad reniciamos el clúster y comprobamos que podemos acceder a glassfish en el puerto 80 (que básicamente es lo que nos permite esto, además de poder conseguir un balanceo de carga si tienes varias instancias glassfish)
6. Definir los recursos JMS y JDBC, teniendo cuidado con los nombres JNDI que les demos. Yo aconsejo no usar más de una / de indirección. Por ejemplo, jms/connectionFactoryThuest es preferible a jms/connectionFactory/thuest. Supongo que debe dar igual pero yo he sufrido algunos problemas inexplicables y seguir este consejo los solucionó. Además, asegurate de indicar el target correcto para cada recurso.
7. Reinicia el clúster, el agente y el dominio todas las veces que hagan falta hasta asegurarte de que los recursos se ven por quien tienen que ser vistos. Mata procesos, elimina restos de despliegues anteriores y no te canses de empezar desde cero una y otra vez.

Son muchas pequeñas cosas, a lo mejor a ti no te afecta todo, pero nunca sobran cosas que repasar cuando algo va mal. Más adelante publicaré mi plan de despliegue de la aplicación, para que yo me acuerde y sirva de ayuda a quien la necesite.

En Thuest esta situación se repite bastantes veces. Por ejemplo, cuando un usuario se hace fan de otro se le envía un correo a este último informando. Un primer desarrollo de la acción convertirseEnFan podría ser:

1º Recuperar de la BBDD el nuevo ídolo
2º Crear y guardar una nueva instancia Fan, que relacione al usuario de sesión y al ídolo recuperado
3º Mandar un email al ídolo
4º Renderizar la respuesta al usuario

El paso que nos interesa es el tercero. Si ese envío se realiza de forma síncrona la acción completa sufrirá una penalización bastante grande respecto al tiempo necesario. La comunicación con el servidor SMTP puede retrasarse y si a esto le sumamos que podemos tener acciones que conlleven el envío de muchos emails, realizar esta operación de forma asíncrona resulta muy interesante.

Podríamos tirar por el camio de en medio y crearnos threads para que hicieran el trabajo, incluso podríamos usar un pool de threads si queremos ser más elegantes. Pero en Java tenemos JMS, que a mi es lo primero que se me viene a la cabeza en estos casos. Además, una vez configurado JMS verás como se te ocurren muchas aplicaciones (el tema los topics da mucho juego y puedes montar un sistema de notificaciones bastante chulo).

Plugin JMS para Grails

Vamos a centrarnos. Puesto que estamos trabajando con Grails, nuestro objetivo es hacer funcionar JMS en este framework y poder enviar emails de forma asíncrona. Para lo primero comenzamos por instalar el plugin correspondiente:

$> grails install-plugin jms

En la página del plugin hay información más detallada de lo que yo pueda explicar aquí, échale un ojo. Particularmente yo tuve que modificar el código del plugin (versión 0.5-RC2), incluyendo returns que el programador entendió opcionales pero que no lo eran tanto. Los ficheros afectados fueron JmsService.groovy, ListenerConfig.groovy y ServiceInspector.groovy.

Además, en el fichero ListenerConfig.groovy se definen los listener que realmente estarán esperando los nuevos mensajes. El método registerListenerContainer tiene el builder que construye estos objetos. En ese builder es posible que te interese deshabilitar el uso de un gestor de transacciones; para ello comenta la linea donde se asigna valor al transactionManager.

El último paso es proporcionar al contexto de ejecución de la aplicación un bean capaz de crear conexiones con nuestro broker de JMS. Este bean será usado por el plugin para establecer las conexiones. Podemos usar el fichero grails-app/conf/spring/resources.groovy para realizar la definición de este bean. Un ejemplo vale más que mil palabras, así es que aquí está el contenido de mi resources.groovy

import grails.util.GrailsUtil
if(GrailsUtil.environment == "production") {
  beans = {
    jmsConnectionFactory(org.springframework.jndi.JndiObjectFactoryBean) {
      jndiName = 'jms/connectionFactory/thuest'
    }
  }
} else if(GrailsUtil.environment == "development") {
  beans = {
    jmsConnectionFactory(com.sun.messaging.ConnectionFactory) {
      // Default values
    }
  }
}

Por defecto, el plugin de JMS espera un bean con nombre jmsConnectionFactory, y así vamos a dejarlo. En función del entorno de ejecución en el que estemos definiremos el bean jmsConnectionFactory de una forma o de otra. Si estamos en producción le indicamos que recupere el bean mediante jndi y la clase porporcionada por Spring JndiObjectFactoryBean (esto acarrea configuración en el servidor, más adelante la veremos). Si estamos en desarrollo indicamos que la clase del bean es com.sun.messaging.ConnectionFactory (para el caso particular de OpenMQ, para ActiveMQ ver la página del plugin JMS) y aceptamos los valores por defecto. Esto valores por defecto implican tener corriendo una instancia del imqbrokerd en el puerto 7676. imqbrokerd viene con Glassfish (mira en el directorio imq/bin de la instalación de Glassfish).

El plugin está listo, siguiente paso.

Receptores de mensajes

Vamos a aislar la funcionalidad que queremos ejecutar asícronamente en un servicio, en mi caso MessageService. En ese servicio hay que incluir el siguiente atributo:

class MessageService {
  ...
  static exposes = ['jms']
  …
}

Este atributo es el que busca el plugin internamente para saber si un servicio tiene métodos asíncronos.

Para definir los métodos asíncronos en estre caso creo que la forma más precisa es usar las anotaciones @Queue o @Topic, en función de lo que queramos. Yo por ejemplo tengo lo siguiente:

import grails.jms.Queue
class MessageService {
  ...
  static exposes = ['jms']
  @Queue
  def sendEmailMessage(EmailMessagePack msg) {…}
}

Serializando que es gerundio

El plugin de JMS inyecta en todos los servicios y controladores el método sendJMSMessage (entre otros), que en su forma más básica acepta un destinatario y un mensaje. El destinatario se expresa como un mapa, dos ejemplos:

  sendJMSMessage([queue:'thuest.message.sendEmailMessage'], mensaje)
  sendJMSMessage([service:'message', method:'sendEmailMessage'], mensaje)

Todo objeto que se envía como mensaje debe ser serializable y sus atributo también para que la recursividad que se aplica por defecto no dé errores. Si tienes que enviar varios contenidos créate una clase para la ocasión (recuerda que debe implementar Serializable) y define los distintos contenidos como atributos de la nueva clase. La alternativa podría ser crearte un converter de mensajes, pero yo he optado por la primera opción, lo veía más sencillo.

Si se envía como mensaje un mapa los valores sólo pueden ser tipos básicos de Java y String.

Configuración en glassfish

Lo primero es definir el objeto ConnectionFactory accesible por jndi. Para ello, empleando la interfaz web de administración de Glassfish, vamos a Resources->JMS Resources->Connection Factories->New. El nombre jndi será el mismo que especificamos en el resources.groovy (en nuestro caso jms/connectionFactory/thuest) y como tipo de recurso yo elegí javax.jms.QueueConnectionFactory al trabajar con queues, si trabajas con topics elige la otra opción.

Llega el turno de definir los destinos de los mensajes, en nuestro caso las queues. Por defecto para el plugin de JMS los nombres jndi de las colas asociadas a mensajes tienen el formato nombreAplicacion.nombreServicio.nombreMetodo, por ejemplo thuest.message.sendEmailMessage. Por lo tanto la configuración en Glassfish supondrá crear tantas colas como métodos asíncronos hayamos definido con el plugin de JMS, usando los nombres correspondientes. Esto lo podemos hacer desde la interfaz web de administración de Glassfish: Resources->JMS Resources->Destination Resources->New.

Los physical destinations solicitados para crear las queues se crean en distintos lugares en función de si estamos trabajando con clusters o no. Si estamos trabajando con clusters, en la interfaz web de administración de Glassfish, ve a Clusters->Mi Cluster->Physical Destinations->New. Si no trabajas con clusters ve a Stand-Alone instances->Mi server->Physical Destinations->New.

Envío de emails

El primer paso es instalar el plugin de mail de Grails:

  $> grails install-plugin mail

Me saltaré el paso de la configuación y uso porque en la página del plugin viene muy bien explicado. En relación al tema que estamos tratando, aconsejaría que el envío de emails se aisle en un método único, así se podría aislar y hacer asíncrono más fácilmente.

Si vas a usar templates gsp como cuerpos de los correos (algo bastante potente y recomendable) ten en cuenta que el envío se realizará fuera de un contexto request. ¿Y qué?. Pues que internamente el objeto implícito request (que no existirá en este caso) puede ser usado en distintos sitios, por ejemplo por el tag g:applyLayout, así es que si pretendes hacer layouts en tus emails vete olvidando.

Y fin

Creo haber hablado de lo más importante, si tienes alguna duda o piensas que hay algo erróneo en lo que he escrito, usa los comentarios, que aquí estamos para aprender.