Probando JRebel con Maven, Spring, Netbeans y Glassfish

La combinación de Maven, Spring, Netbeans y Glassfish nos permite crear aplicaciones potentes en cuanto a buenas prácticas, gestión y construcción del proyecto, con un IDE ampliamente utilizado y conocido, sobre un servidor de aplicaciones decente... hasta aquí todo esta muy bien.

Lo malo, son los cambios que se experimentan durante la fase de desarrollo.

Lo normal en la construcción de una aplicación JEE es que este compuesta por distintos componentes, como por ejemplo:

• 1 jar con los componentes comunes
• 1 jar con los objetos del dominio
• 1 jar con los DAO
• 1 jar con el negocio de pepito :-)
• 1 jar con el negocio de juanito ;-)
• 1 jar con los clientes de WS de ...
• 1 jar con ....
• y finalmente un WAR/EAR

Cualquier cambio que se realize en cualquiera de esos componentes requiere que se compile y despliegue la aplicación al completo en el servidor de aplicaciones, esto incluye el famoso undeploy/deploy de nuestro WAR/EAR, algo que suele ser muy ... pero que muy lento.

JRebel permite evitarnos todo este proceso "traumático", pasando de actualizar el servidor de unos minutos eternos a unos pocos segundos.

El proceso de implantación es el siguiente:

1. Descargar e instalar JRebel ( 2.2.1 (21st December 2009) )
2. Configurar Glassfish
3. Que la aplicacion principal(WAR/EAR) tenga un fichero denominado
   rebel.xml
4. Probar que funciona

1.- Descargar e instalar JRebel
Obviamente el título lo dice todo : Descarga

2.- Configurar Glassfish v2.1
Se deben añadir dos opciones de arranque a la máquina virtual del servidor de aplicaciones.

"Cuidado con la documentación por que utilizar la barra (\) os puede originar que vuestro Glassfish no arranque (en windows), por ello es mejor utilizar la contra barra (/)"

3.- Configuracion de la aplicacion principal (WAR)
Supiendo que nuestra aplicacion esta ubicada en la carpeta "c:/application", que la aplicacion web se llama "webapp" y que sus compomentes se llamanan "un-componente-jar" y "otro-componente-jar" el fichero de configuración rebel.xml tendría que estar en el directorio classes(en su defecto la raiz del código fuente) de la "webapp"; y quedaría de la siguiente forma:

<?xml version="1.0" encoding="UTF-8"?> 
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">

<classpath>
   <dir name="C:/application/webapp/src/main/java">
      <include name="**/*.*">
   </dir>
   <dir name="C:/application/webapp/target/classes">
      <include name="**/*.*">
   </dir>

   <dir name="C:/application/webapp/target/classes"></dir>

   <dir name="C:/application/un-componente-jar/target/classes">
      <include name="**/*.*">
   </dir>

   <dir name="C:/application/otro-componente-jar/target/classes">
      <include name="**/*.*">
   </dir>
</classpath>

<web>
   <link target="/">
      <dir name="C:/application/webapp/src/main/webapp"></dir>
   </link>
</web>
</application>

4.- Probar que funciona
Si arrancamos Glassfish en modo debug, podemos cambiar el código de cualquier clase de los jars y simplemente guardandola, JRebel se encarga de actualizarla en el servidor de aplicaciones sin tener que volver a desplegar la webapp.

Enlaces relacionados:

• Configuración del plugin de Maven
• Buenas prácticas con Maven y Netbeans
• Reloading Java Classes 401: HotSwap and JRebel — Behind the Scenes

Solo decir que desarrollar asi ya es una delicia por la cantidad de tiempo que uno puede llegar a ahorrar, ahora me queda paciencia para mas cosas :-)

- FIN -