Detener el almacenamiento en caché de los scripts del navegador en la aplicación GWT

Question

Tengo una aplicación GWT desplegada en las máquinas de nuestro cliente. Como un desarrollo en curso junto, tenemos que lanzar nuevas versiones mejoradas de la aplicación de vez en cuando. Cada vez que lanzamos una nueva versión, nos encontramos con el problema donde el navegador del cliente ha almacenado en caché las secuencias de comandos antiguas y por un tiempo se comporta de manera estrangulada porque los datos con los que están tratando de trabajar no son del todo compatibles. ¿Cuál es la mejor manera de superar este problema? Actualmente tengo que decirle a los usuarios que borren la memoria caché de su navegador para una nueva versión, pero sería bueno que no tienen que hacer esto.

Answer 1

De forma predeterminada, el grueso de la aplicación debe almacenarse en la memoria caché del navegador hasta que el proceso de compilación genere una nueva versión de la misma.

Puede ser útil comprender el modelo de arranque GWT para comprender cómo funciona esto.

El primer script que solicita su cliente, your-app-name.nocache.js, no se almacena en caché, y no hace nada excepto consultar las capacidades y el agente de usuario del navegador y realizar una segunda solicitud para la aplicación correspondiente JS.

En este punto, la secuencia de comandos que solicita debe ser almacenada en la memoria caché por el navegador si se ha solicitado antes. Este es un archivo {indistinguisable-numbers-and-letters}.cache.html.

Cuando vuelve a implementar su aplicación, el archivo nocache.js se ejecutará y pedir una cache.html archivo diferente del servidor, lo que no será ya presente en la memoria caché, pero que obtendrá en caché por el navegador una vez que se haya descargado.

¿Está haciendo algo inusual con el enlace diferido, o con los encabezados de almacenamiento en caché en su servidor? Esto podría causar que su archivo nocache.js se guarde en caché después de todo, lo que haría que solicite el viejo cache.html s de la memoria caché del navegador.

Answer 2

La solución posible depende de la forma en que esté alojando su aplicación. Si usted está recibiendo directamente del contenedor de servlets, a continuación, puede utilizar el filtro servlet como el que se describe a continuación:

http://seewah.blogspot.com/2009/02/gwt-tips-2-nocachejs-getting-cached-in.html

Éstos son filtros apropiados de la biblioteca tadedon:

http://code.google.com/p/tadedon/source/browse/tadedon-servlet/src/main/java/com/xemantic/tadedon/servlet/CacheDisablingFilter.java

http://code.google.com/p/tadedon/source/browse/tadedon-servlet/src/main/java/com/xemantic/tadedon/servlet/CacheForcingFilter.java

Y aquí está Guice ServletModule que les permite la aplicación web entera guice:

http://code.google.com/p/tadedon/source/browse/tadedon-gwt/src/main/java/com/xemantic/tadedon/gwt/http/GwtHttpCachingModule.java

Si está utilizando algún proxy inverso delante de tomcat, sería incluso más simple. En el caso de Apache (por ejemplo, mod_proxy, mod_jk), y suponiendo que todos los recursos de la aplicación (html, gráficos, scripts de Java, CSS, etc.) Se ponen en Apache, acaba de establecer estas opciones en la configuración de Apache:

<Files *.nocache.*> 
    ExpiresDefault "access" 
</Files> 

<Files *.cache.*> 
    ExpiresDefault "now plus 1 year" 
</Files> 

Se describe aquí:

http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html

en la sección "perfecto almacenamiento en caché". Tal escenario de implementación supone que solo las solicitudes de rpc deben pasar por proxy inverso a tomcat. Si por alguna razón todo el contexto de la aplicación se envía a tomcat, puede seguir utilizando la directiva LocationMatch de apache en lugar de la directiva Files.