sábado, 4 de febrero de 2012

Recarga de clases (class reloading) en Apache Tapestry

Apache Tapestry
En el mundo Java de desarrollo de aplicaciones web hace no tanto tiempo un cambio en una clase implicaba reiniciar el servidor para ver los cambios. Dado que desarrollando una aplicación los cambios son pequeños, incrementales y numerosos esto implicaba tener que reiniciar constantemente el servidor que dependiendo de la aplicación esto podría llevar no mucho tiempo, desde 10-30, que ya es un tiempo considerable, pero podría llegar a llevar incluso algunos minutos. El tiempo de espera para cada reinicio normalmente es tiempo no productivo que acumulándolo a lo largo del día puede llegar a ser considerable y por ello los frameworks web están evolucionando a no tener que requerir reiniciar el servidor para detectar las modificaciones, esto es, cogiendo los cambios en caliente. Ello nos permite ser más productivos.

Apache Tapestry evlucionó y no se quedó atras. La recarga de clases o «class reloading» es una característica añadida en Tapestry en la versión 5 para las clases de las páginas y componentes al igual que los archivos .tml de las plantillas y los los archivos de catálogos de mensajes. En la versión 5.2 la recarga de clases se extendió a los servicios definidos en los módulos de Tapestry. El proceso de recarga que hace Tapestry cuando se detecta un cambio en una clase no afecta a los datos persistentes ya que estos se guardan aparte, normalmente en la sesión, con lo que el desarrollo nos será muy cómodo.

Si nuestra aplicación tiene como paquete base com.blogspot.elblogdepicodev.tapestry Tapestry recargará las clases de los siguientes paquetes cuando detecte algún cambio:
  • com.blogspot.elblogdepicodev.tapestry.pages
  • com.blogspot.elblogdepicodev.tapestry.components
  • com.blogspot.elblogdepicodev.tapestry.mixins
  • com.blogspot.elblogdepicodev.tapestry.base
Sim embargo, el proceso tiene algunas limitaciones. La recarga solo se aplica a clases y archivos que están en el sistema de archivos y no obtenidos desde archivos JAR. Aunque esta limitación no es importante en desarrollo ya que podemos desplegar la aplicación en nuestro servidor de desarrollo de forma expandida.

El coger los cambios en caliente es una característica deseable de todo framework actual pero también hay que tener en cuenta el tiempo de inicio del servidor ya que en algún momento tarde o temprano nos tocará hacerlo, si queremos ser ágiles en el desarrollo no es recomendable esperar varios minutos a que el servidor termine de iniciarse y en producción es necesario que el tiempo de interrupción sea mínimo.

Un Tomcat sin ninguna aplicación tarda en iniciarse unos 4 segundos, con una aplicación Tapestry desplegada de forma expandida con Hibernate, EhCache y Quartz de tamaño medio tarda unos 10 segundos y en servir la primera página unos 15-20 segundos.

Referencia:
Documentación sobre Apache Tapestry