You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Peter Ertl (JIRA)" <ji...@apache.org> on 2010/08/27 19:27:54 UTC
[jira] Created: (WICKET-3021) Add timestamp part to resource
filenames for better caching
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 url
<link rel="stylesheet" type="text/css" href="wicket/resource/my.great.app.HomePage/css/style.css-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 should now be able to configure your resources caching to 'infinity' which will give you best 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.
[jira] Updated: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-3021:
-------------------------------
Description:
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.
was:
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 should now be able to configure your resources caching to 'infinity' which will give you best network performance and utilization of proxies.
> 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.
[jira] Updated: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-3021:
-------------------------------
Description:
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 should now be able to configure your resources caching to 'infinity' which will give you best network performance and utilization of proxies.
was:
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 url
<link rel="stylesheet" type="text/css" href="wicket/resource/my.great.app.HomePage/css/style.css-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 should now be able to configure your resources caching to 'infinity' which will give you best network performance and utilization of proxies.
> 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 should now be able to configure your resources caching to 'infinity' which will give you best 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.
[jira] Commented: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903852#action_12903852 ]
Igor Vaynberg commented on WICKET-3021:
---------------------------------------
this should replace getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl()
> 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.
[jira] Commented: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903853#action_12903853 ]
Peter Ertl commented on WICKET-3021:
------------------------------------
@igor: yes, and we should mention that in the migration notes (whoever maintains them).
> 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.
[jira] Updated: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-3021:
-------------------------------
Attachment: timestamp-for-resources.patch
> 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 url
> <link rel="stylesheet" type="text/css" href="wicket/resource/my.great.app.HomePage/css/style.css-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 should now be able to configure your resources caching to 'infinity' which will give you best 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.
[jira] Resolved: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-3021.
-----------------------------------
Assignee: Igor Vaynberg
Fix Version/s: 1.5-M2
Resolution: Fixed
> 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
> Assignee: Igor Vaynberg
> Fix For: 1.5-M2
>
> 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.
[jira] Commented: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12904793#action_12904793 ]
Hudson commented on WICKET-3021:
--------------------------------
Integrated in Apache Wicket 1.5.x #282 (See [https://hudson.apache.org/hudson/job/Apache%20Wicket%201.5.x/282/])
applied 3021 patch
Issue: WICKET-3021
> 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
> Assignee: Igor Vaynberg
> Fix For: 1.5-M2
>
> 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.
[jira] Updated: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-3021:
-------------------------------
Attachment: (was: timestamp-for-resources.patch)
> 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
>
> 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.
[jira] Commented: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Alexandru Objelean (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903820#action_12903820 ]
Alexandru Objelean commented on WICKET-3021:
--------------------------------------------
Maybe a better approach would be to use a digest value (using MD5, CRC32 or anything else) instead of timestamp. This would ensure that the resources are not cached even when the application is deployed on multiple machines.
> 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.
[jira] Updated: (WICKET-3021) Add timestamp part to resource
filenames for better caching
Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Ertl updated WICKET-3021:
-------------------------------
Attachment: timestamp-for-resources.patch
updated patch for current trunk
> 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.