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> > 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
