Este es el cuarto en una serie de posts donde hablo de ZTT en mi proceso de desarrollo.1) Desarrollador ágil JAVA. ¿Oxímoron?
2) ZTT y Tapestry5
3) Matt Raible acerca de ZTT
Live Template Reloading
Tapestry4 tiene un muy promocionado
"modo desarrollador" en el cual los cambios en los templates html se reflejan en la aplicación sin necesidad de reiniciar el servidor de aplicaciones.
Basta con agregar
-Dorg.apache.tapestry.disable-caching=true al comando de ejecución del servidor de apps.
Si bien esta simple configuración es muy útil, tiene sus inconvenientes. El primero es que recarga
todos los templates por cada request, hayan o no sido modificados. Cuando la cantidad de componentes en una página es muy grande (como suele ser mi caso) y cuando la cantidad de requests es mucha (como cuando se utiliza AJAX) la velocidad de respuesta de la aplicación se vuelve intolerable y después de la 5 o 6 recargas de la página suele dar algún que otro
problema de memoria.
Una mejor alternativa es habilitar el servicio de reset usando
-Dorg.apache.tapestry.enable-reset-service=true. Con este servicio habilitado es posible resetear la caché de templates y el pool de componentes simplemente accediendo a la URL
/app?service=reset&page=Home o
/reset.svc?page=HomeExisten varias propuestas de mecanismos para facilitarle al programador el acceso al servicio de reset. La opción tradicional es dejar abierto un tab del firefox en esa URL y hacer F5 cada vez que se quiera hacer reset.
Andreas Andreu (uno de los commiters de tapestry)
propone hacerlo desde un script de
greasemonkey. Yo, en cambio, prefiero usar una tarea de
ant:
<telnet port="8080" server="localhost" timeout="20">
<read>
<write>GET /reset.svc?page=Home HTTP/1.0</write>
<write></write>
</read>
</telnet>
El servicio de reset está desabilitado por defecto porque en producción podría ser muy fácilmente explotado para obtener una denegación de servicio.
Para habilitar reloading de templates en producción fui un paso más allá de lo documentado y expuse el servicio de reset via JMX (gracias a
HiveMind) de tal manera de poder automatizar el reset de la cache tomando las mayores precauciones de seguridad (y así evitar un posible DoS).
hivemodule.xml
<contribution configuration-id="hivemind.EagerLoad">
<load service-id="hivemind.management.MBeanRegistry"/>
</contribution>
<contribution configuration-id="hivemind.management.MBeans">
<mbean service-id="TapestryMBean"/>
</contribution>
<service-point id="TapestryMBean" interface="org.amneris.tapiz4.jmx.TapestryMBean">
<invoke-factory>
<construct class="org.amneris.tapiz4.jmx.TapestryMBeanImpl">
<set-object property="resetEventHub" value="infrastructure:resetEventHub"/>
</construct>
</invoke-factory>
</service-point>
<contribution style="font-weight: bold; font-style: italic;" id="hivemind.EagerLoad"><load id="hivemind.management.MBeanRegistry"></load></contribution><contribution style="font-weight: bold; font-style: italic;" id="hivemind.management.MBeans"><mbean id="TapestryMBean"></mbean></contribution><service-point style="font-weight: bold; font-style: italic;" id="TapestryMBean" interface="com.amneris.muba.jmx.TapestryMBean"><invoke-factory><construct class="com.amneris.muba.jmx.TapestryMBeanImpl"><set-object property="resetEventHub" value="infrastructure:resetEventHub"></set-object></construct></invoke-factory></service-point>java
import org.apache.tapestry.services.ResetEventHub;
public class TapestryMBeanImpl implements TapestryMBean
{
ResetEventHub resetEventHub;
public void resetTapestryCache()
{
resetEventHub.fireResetEvent();
}
public void setResetEventHub(ResetEventHub resetEventHub)
{
this.resetEventHub = resetEventHub;
}
}
Live Class Reloading
En cuanto a class reloading en Tapestry4, ya comenté en el
post anterior que solo conozco 2 alternativas (si alguien de alguna más por favor que me lo comente).
1)
Sysdeo tomcat launcher plugin (open source)
2)
JavaRebel de
ZeroTurnaround (software de pago, altamente recomendado)
