Hi, The following demonstrates the bug without the fix. Demonstrable configuration is Linux Centos5, Jboss-4.2.2.ga, running Tapestry 5.1.0.5 but am told by others on the list it affects later and most recent versions too.
It seems to only affect the case where requested assets are located within jar files, which are themselves within (w|e)ar deployed archives. (The Tapestry code does not deal with the case where the url is of type JARURL) GET /xxxx/xxxx/xxxx/css/foo.css HTTP/1.1 Host: xxxxxxx HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT Expires: Sun, 30 Dec 1979 00:00:00 GMT Content-Type: text/css Content-Length: 7713 Date: Thu, 08 Apr 2010 13:43:58 GMT (If an asset expires in 1979, nothing will cache it) Cheers Geoff On 8 Apr 2010, at 13:40, Christophe Cordenier wrote: Hi, I don't think this is bug, in production mode caching is needed Please refer to http://tapestry.apache.org/tapestry5.1/guide/conf.html tapestry.application-version The version of the application, which is incorporated into URLs for context and classpath assets. Assets may be compressed <http://tapestry.apache.org/tapestry5.1/guide/compress.html>, and will have far-future expiration headers; they will be aggresively cached by the client web browser. You should change the application version on each new deployment of the application (that is, any time assets in the context change), to force clients to re-download changed versions of files. If you do not specify an application version, a *random* one will be assigned on every deployment (which is good for development but very bad for production).Best Regards, Christophe Cordenier. 2010/4/8 Geoff Meakin <geo...@gamesys.co.uk<mailto:geo...@gamesys.co.uk>> Hi, I'm more of a sysadmin than a developer, but we experienced a problem whereby static assets wrapped up in jars within wars, requested by Tapestry and deployed on tomcat (or jboss) would return 0 for their lastmodified time (interpreted as the year 1970)- which would cause us caching-related problems. I tracked the problem to a call within org.apache.tapestry5.internal.util.URLChangeTracker.java (timestampForNonFileURL method). Whether it is a problem with Tapestry, or java.net.URLConnection I dont know, however I provide below an example code-snippet that seems to work in place of this method, by testing whether the non-file resource is a jarfile (with a url like jar:file:foo). It is inspired from resolution of a similar problem here: http://issues.apache.org/jira/browse/TRINIDAD-73 Feel free to use/ignore/amend/complain as this is my likely only post to the tapestry list :) Thanks Geoff I edited this file in tapestry-core: src/main/java/org/apache/tapestry5/internal/util/URLChangeTracker.java I put in some debug and worked out where the problem was. I implemented a similar solution to the one suggested in the bugfix coding the following replacement method for timestampForNonFileURL. This makes it jarfile aware. private long timestampForNonFileURL(URL url) { long timestamp; URLConnection urlConnection; try { urlConnection=url.openConnection(); } catch (IOException ex) { throw new RuntimeException(ex); } if (urlConnection instanceof JarURLConnection) { JarURLConnection jarUrlConnection = (JarURLConnection) urlConnection; URL jarFileUrl = jarUrlConnection.getJarFileURL(); URLConnection jarFileConnection; try { jarFileConnection = jarFileUrl.openConnection(); } catch (IOException ex) { throw new RuntimeException(ex); } timestamp = jarFileConnection.getLastModified(); try { jarFileConnection.getInputStream().close(); } catch (IOException ex) { throw new RuntimeException(ex); } } else { timestamp = urlConnection.getLastModified(); } return applyGranularity(timestamp); } Now when I do this: telnet xxxx.xxxx.xxxx.xxxx.xxxx 8080 Trying xx.xxx.xxx.xx... Connected to xxxx.xxxx.xxxx.xxxx.xxxx. Escape character is '^]'. GET /xxxx/xxxx/xxxx/xxxx/css/foo.css HTTP/1.1 Host: xxxx.xxxx.xxxx.xxxx.xxxx< http://www.jackpotjoy.cuties.dev.gamesys.corp/> I get this: HTTP/1.1 200 OK Server: Apache-Coyote/x.x X-Powered-By: Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5 Last-Modified: Wed, 31 Mar 2010 14:23:42 GMT Expires: Sat, 28 Mar 2020 14:23:42 GMT Content-Type: text/css Content-Length: 7713 Date: Wed, 07 Apr 2010 19:35:10 GMT As you can see the Expires and Last-Modified is now correct. Previous to this change , the exact same request returned 1970 and 1979 (the problem we were seeing). Geoff Meakin Development Build Architect, Gamesys Ltd, Follow me on yammer.com<http://yammer.com> This email (including any attachments) is confidential, protected by copyright and may be privileged. It is for the exclusive use of the intended recipient(s). If you have received it in error, please notify the sender immediately by emailing a response before deleting the email completely from your computer, and note that any storage, copying or dissemination is prohibited. Where the content of this email is personal or otherwise unconnected with business of the Group's Companies, we accept no responsibility or liability for such content. We accept no responsibility for viruses that we may have unintentionally transmitted to you within this email and you should check for viruses before opening any attachment. Those communicating with us by email will be deemed to have consented to us intercepting and monitoring those communications. Gamesys Ltd is registered in England & Wales, company registration number 04042931. The registered office is at 10 Piccadilly, London W1J 0DD. -- Regards, Christophe Cordenier. Developer of wooki @wookicentral.com Geoff Meakin Development Build Architect, Gamesys Ltd, Follow me on yammer.com<http://yammer.com> This email (including any attachments) is confidential, protected by copyright and may be privileged. It is for the exclusive use of the intended recipient(s). If you have received it in error, please notify the sender immediately by emailing a response before deleting the email completely from your computer, and note that any storage, copying or dissemination is prohibited. Where the content of this email is personal or otherwise unconnected with business of the Group's Companies, we accept no responsibility or liability for such content. We accept no responsibility for viruses that we may have unintentionally transmitted to you within this email and you should check for viruses before opening any attachment. Those communicating with us by email will be deemed to have consented to us intercepting and monitoring those communications. Gamesys Ltd is registered in England & Wales, company registration number 04042931. The registered office is at 10 Piccadilly, London W1J 0DD.
