ZTT y Tapestry5
Al comenzar a hablar de ZTT en java hay que hacer la siguiente aclaración: es prácticamente imposible asegurar que cualquier estrategia para ZTT para java funcionará en el 100% de los casos.
La principal razón para esto es que no hay una manera estándar establecida de hacer manipulación de bytecode de clases (weaving), y entonces cada framework o librería implementa su manera: algunos usan AspectJ, otros Javassist, otros Jakarta Commons JCI y otros como Tapestry5 implementan su propio ClassLoader.
Esto lleva a que varios esfuerzos para aproximarse a ZTT resulten incompatibles entre si y con determinados frameworks. El caso más típico es Hibernate. En esta serie de post veremos diferentes estrategias para acelerar el desarrollo al utilizar frameworks como Trails, Tapestry4, Tapestry5, Spring. Pero cuando se trata de Hibernate siempre hay que hacer consideraciones aparte, porque al realizar una modificación sobre una clase del modelo Hibernate, no todas las estrategias para ZTT funcionan correctamente. Hibernate tiene su propio weaving de classes (weaving estático con Javassist) que no permite hacer el cambio "on the fly" de una clase sin notificarle a Hibernate y recargar toda la configuración. En otro post mostraré de que manera se puede disminuir el impacto de esta limitación de Hibernate recargando el contexto de Spring.
Una de las nuevas características de Tapesty5 es la recarga automática ("on the fly") de clases o templates que hayan sido modificados (Live Class and Template Reloading).
Lo mejor de la implementación de Tapestry5 es que funciona exactamente igual en desarrollo que en producción y no necesita (prácticamente) ninguna configuración o consideración extra.
Para verlo en funcionamiento se pueden consultar los excelentes screencasts de Tapestry5 que Howard ha preparado como introducción a las diferentes características del framework.
Incluso es realmente fácil de probar para aquellos familiarizados con Maven. Existe un archetype que permite probar estás caracteristicas de Tapesty5 en 10 minutos.
Las limitaciones: Tapestry5 implementa su propio ClassLoader y debido a la ambigüedades en las especificaciones de "class loading" (lo que ha generado varias discuciones) para servidores de aplicaciones, hay que tener ciertas precauciones al usar otros servidores de aplicaciones que no sean Jetty.
Otra limitación es que el class reloading se limita a clases controladas por Tapestry5 IoC, por lo que si el cambio ha sido en clases del modelo Hibernate o alguna clase que se inyecta via Spring, estos cambios no serán detectados.Tapestry5 "Live Class and Template Reloading" es LO MEJOR (dentro del open source) que he visto para facilitar la vida del desarrollador web java y reducir el tiempo del ciclo de deployment al mínimo posible. Gracias a esta característica creo se convertirá en "él" framework web java del 2008 y seguramente volverá a ganar el premio que otorga Sun a la innovación en Java.
La principal razón para esto es que no hay una manera estándar establecida de hacer manipulación de bytecode de clases (weaving), y entonces cada framework o librería implementa su manera: algunos usan AspectJ, otros Javassist, otros Jakarta Commons JCI y otros como Tapestry5 implementan su propio ClassLoader.
Esto lleva a que varios esfuerzos para aproximarse a ZTT resulten incompatibles entre si y con determinados frameworks. El caso más típico es Hibernate. En esta serie de post veremos diferentes estrategias para acelerar el desarrollo al utilizar frameworks como Trails, Tapestry4, Tapestry5, Spring. Pero cuando se trata de Hibernate siempre hay que hacer consideraciones aparte, porque al realizar una modificación sobre una clase del modelo Hibernate, no todas las estrategias para ZTT funcionan correctamente. Hibernate tiene su propio weaving de classes (weaving estático con Javassist) que no permite hacer el cambio "on the fly" de una clase sin notificarle a Hibernate y recargar toda la configuración. En otro post mostraré de que manera se puede disminuir el impacto de esta limitación de Hibernate recargando el contexto de Spring.
Tapestry5 seamless ZTT
Una de las nuevas características de Tapesty5 es la recarga automática ("on the fly") de clases o templates que hayan sido modificados (Live Class and Template Reloading).
Lo mejor de la implementación de Tapestry5 es que funciona exactamente igual en desarrollo que en producción y no necesita (prácticamente) ninguna configuración o consideración extra.
Para verlo en funcionamiento se pueden consultar los excelentes screencasts de Tapestry5 que Howard ha preparado como introducción a las diferentes características del framework.
Incluso es realmente fácil de probar para aquellos familiarizados con Maven. Existe un archetype que permite probar estás caracteristicas de Tapesty5 en 10 minutos.
Las limitaciones: Tapestry5 implementa su propio ClassLoader y debido a la ambigüedades en las especificaciones de "class loading" (lo que ha generado varias discuciones) para servidores de aplicaciones, hay que tener ciertas precauciones al usar otros servidores de aplicaciones que no sean Jetty.
Otra limitación es que el class reloading se limita a clases controladas por Tapestry5 IoC, por lo que si el cambio ha sido en clases del modelo Hibernate o alguna clase que se inyecta via Spring, estos cambios no serán detectados.Tapestry5 "Live Class and Template Reloading" es LO MEJOR (dentro del open source) que he visto para facilitar la vida del desarrollador web java y reducir el tiempo del ciclo de deployment al mínimo posible. Gracias a esta característica creo se convertirá en "él" framework web java del 2008 y seguramente volverá a ganar el premio que otorga Sun a la innovación en Java.
