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.: 
<extend-configuration-property name="html5manifestlinker_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?

THX
Marian

Am Sonntag, 4. Januar 2015 11:14:12 UTC+1 schrieb Peter Donald:
>
> On Sun, Jan 4, 2015 at 7:27 PM, James Nelson <[email protected] 
> <javascript:>> 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 <[email protected] 
> <javascript:>> 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.
>
> [1] https://github.com/realityforge/gwt-appcache
> [2] https://github.com/realityforge/gwt-cache-filter
> -- 
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to