[
https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903825#action_12903825
]
Peter Ertl commented on WICKET-3021:
------------------------------------
I would consider this an alternate approach. Using MAC's sounds like a good
idea either. It is not that hard to add some kind of IResourceVersionProvider
once we get an basic version running errors-free.
However keep in mind that creating hashes is more expensive then getting the
last modified date of a file. So some kind of caching would be appropriate.
Even for the timestamps caching would eventually make sense. I consider this a
second step.
The timestamp that gets delivered from wicket resources comes straight out off
the jar file *afaik*. It should be the time of the file in the file system when
it was packaged. So the timestamp should be the equal when running the same jar
file on multiple cluster nodes.
Even in case the timestamps were different it would not matter. The whole
purpose of timestamps is not to be unique. They just have to change when the
files contents change. This will cause your browser to not look up the cache
for the resource.In fact it looks like a different resource as the file name is
different. The web application does not care about the timestamp but always
deliver the most current one (which is included in the jar).
Not hitting the cache when touching resources is all we want.
Conceptionally things will be the same when running an exploded jar. In that
case the timestamps are taken from the files in the file system.
> Add timestamp part to resource filenames for better caching
> -----------------------------------------------------------
>
> Key: WICKET-3021
> URL: https://issues.apache.org/jira/browse/WICKET-3021
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.5-M1
> Reporter: Peter Ertl
> Attachments: timestamp-for-resources.patch
>
>
> Even though we have
> getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl() this
> still is far from perfect. It will add a query parameter to resource
> filenames so caches should invalidate when the parameter changes. However if
> caching is very aggressive altering the query param might not be enough. Then
> there will be stale resources left in the cache of the browser or some
> intermediate proxy. Users will complain and you have to tell them to press
> F5, clear the cache, or whatever :-(
> So I decided to implement support for adding the timestamp of the resource as
> part of the filename.
> When you have a resource link like
> <link rel="stylesheet" type="text/css"
> href="wicket/resource/my.great.app.HomePage/css/style.css"/>
> a timestamp (the last modified timestamp of the file) will be injected into
> the base name of the file
> <link rel="stylesheet" type="text/css"
> href="wicket/resource/my.great.app.HomePage/css/style-ts1282376261000.css"/>
> the format is
> [path-component]* / [base-filename] "-ts" [timestamp-in-milliseconds]
> (.extension)
> The prefix "-ts" (TS = timestamp) is to avoid naming conflicts with filenames
> that already got with a numeric part before the extension.
> Locales, style and variations are taken into consideration (e.g. style.css,
> style_de.css, style_en.css)
> When running your test cases the MockApplication which WicketTester provides
> in the default case has timestamps disabled so you can check you rendered
> markup against some predictable url.
> You can control and check timestamp behavior with
> getResourceSettings().setUseTimestampOnResources()
> and
> getResourceSettings().getUseTimestampOnResources()
> Default behavior is 'enabled'
> You are now able to configure your resource caching for a very large lifetime
> (say 'infinite' :-) and get the best possible network performance and
> utilization of proxies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
