Okay! I don't think the filter fixed my problem. I did another test without adding the line:
Am Sonntag, 4. Januar 2015 14:29:15 UTC+1 schrieb marian lux:
-- <inherits name="com.google.gwt.precompress.Precompress"/>in my gwt.xml and the problem still exists.
So, only if there is a zipped version (of the gwt generated file "nocache.js"), the update will be executed.
To enable the filter
I added in my pom.xml:
<dependency> <groupId>org.realityforge.gwt.cache-filter</groupId> <artifactId>gwt-cache-filter</artifactId> <version>0.6</version> </dependency>
and in my web.xml:
<filter> <filter-name>GWTCacheControlFilter</filter-name> <filter-class>org.realityforge.gwt.cache_filter.GWTCacheControlFilter</filter-class> </filter> <filter> <filter-name>GWTGzipFilter</filter-name> <filter-class>org.realityforge.gwt.cache_filter.GWTGzipFilter</filter-class> </filter> <filter-mapping> <filter-name>GWTCacheControlFilter</filter-name> <url-pattern>/zzz/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>GWTGzipFilter</filter-name> <url-pattern>/zzz/*</url-pattern> </filter-mapping>
Is there something else to do? As mentioned before, I don't really know how this works.
THX
Marian
Am Sonntag, 4. Januar 2015 14:29:15 UTC+1 schrieb marian lux:
Thank you Peter.After adding gwt-cache-filter it works now. I am wondering why this was never a part of the mgwt appcache solution. The gwt-cache-filter project page had the nice side-effect for me that I got the hint to use/inherit com.google.gwt.precompress.Precompress. My application is now 2/3 smaller than before. But I have an other problem which is from the same type but I don't have the deep understanding how gwt-cache-filter works:As mentioned before, I have the same issue with an other file, a html-file.Background: I have a html-file which is loaded on runtime inside a iframe-view in my application. The html-file changes from time to time if a customer opens it in tomcat folder with an html-editor and changes something. The html-file is defined in the manifest file in gwt.xml with mgwt. e.g.:files" value="./ClientData/Infos_de.html" />
I have the same behavior with this file as with the nocache.js file:After compilation I must change everything in the content of this file (e.g. adding a carriage return at the begin of the file) to get the update on client if the html-file was loaded on client and is changed later by the hand of customer.How can I fix this, without manually (or writing a deploy mechanism) changing the content of the file before deploying it?Should I go away from the mgwt linker and use the gwt-appcache instead?THXMarian
Am Sonntag, 4. Januar 2015 11:14:12 UTC+1 schrieb Peter Donald:On Sun, Jan 4, 2015 at 7:27 PM, James Nelson <ja...@wetheinter.net> wrote:You are expected to tell your web server to set non-caching headers for that file, so if your browser is caching it at all, I would say you need to modify your webserver cache policy.On Sun, Jan 4, 2015 at 7:28 PM, James Nelson <ja...@wetheinter.net>wrote: Oh, wait, sorry, I see you're dealing w/ offline support.
I will politely bow out and wish you luck in diagnosing the problem.Nope you are right. You still need to set the cache control headers, even when dealing with offline support. We use gwt-appcache [1] but still use gwt-cache-filter [2] to set the headers. My guess is that it it is the fact that the gwt compiler is not updating the timestamp and something in the chain (tomcat?) is not noticing the file is changed and serving the cached version.--Cheers,
Peter Donald
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment