[
https://issues.apache.org/jira/browse/WICKET-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057523#comment-13057523
]
Peter Ertl commented on WICKET-3846:
------------------------------------
The final solution is as follows:
In development mode:
version-string = last-modified timestamp converted to milliseconds as a string
cache-scope = version-string will be cached for the lifetime of the current
request cycle
In deployment mode:
version-string = md5 hash value of the package resource data as a hexadecimal
string
cache-scope = version-string will be cached for the lifetime of the wicket
application
the resource filenames will be decorated like that:
decorated_resource_filename := base_filename + "-ver-" + version-string "." +
file_extension
all this behavior is just a default and can be changed to your needs.
> in environments without reliable timestamps (e.g. some clusters) resource
> caching is useless
> --------------------------------------------------------------------------------------------
>
> Key: WICKET-3846
> URL: https://issues.apache.org/jira/browse/WICKET-3846
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC5.1
> Reporter: Peter Ertl
> Assignee: Peter Ertl
> Fix For: 1.5-RC6
>
> Attachments: cache.patch
>
>
> As mentioned already in the wicket userlist *iirc* wicket's default resource
> caching strategy using resource file timestamps will not work in some cluster
> environments. Cluster deployers seem to be quite dumb and not preserve the
> 'lastModified' file attribute. So depending on the server instance the
> resource is delivered from it will contain multiple timestamps for the same
> resource. Apparently timestamps seem to be unsuitable for the purpose of
> caching in that environment.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
