Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 3.0
-
Fix Version/s: EE-3.2.0.BETA, EE-3.2.0.GA, 3.3
-
Component/s: Framework
-
Labels:None
-
Environment:ICEfaces 3.x
-
Assignee Priority:P1
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Compatibility/Configuration
Description
JSF 2 provides a resource versioning scheme that can be used to indicate to browsers when a previously cached resource needs to be updated/reloaded.
ICEfaces 3.0, 3.1 provide partial support for this feature, but lacks comprehensive support that would cover the ICE components, some ACE component resources, and .CSS.
An improvement would be to provide comprehensive support for the JSF 2 resource versioning scheme for all ICEfaces resources.
Activity
Migration
created issue -
Migration
made changes -
Field | Original Value | New Value |
---|---|---|
Reporter | Migration [ remote ] | Ken Fyten [ ken.fyten ] |
Migration
made changes -
Assignee | Deryk Sinotte [ deryk.sinotte ] | |
Affects | Documentation (User Guide, Ref. Guide, etc.),Compatibility/Configuration [ 10003, 10002 ] | |
Assignee Priority | P1 [ 10010 ] |
Ken Fyten
made changes -
Fix Version/s | EE-3.2.0.GA [ 10332 ] | |
Fix Version/s | 3.3 [ 10370 ] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #32861 | Tue Dec 18 16:35:20 MST 2012 | deryk.sinotte | |
Files Changed | ||||
MODIFY
/icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/VersioningResourceHandler.java
|
Deryk Sinotte
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #32871 | Wed Dec 19 11:23:32 MST 2012 | deryk.sinotte | |
Files Changed | ||||
MODIFY
/icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/VersioningResourceHandler.java
|
Ken Fyten
made changes -
Fix Version/s | EE-3.2.0.BETA [ 10573 ] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #32922 | Fri Dec 21 17:10:55 MST 2012 | deryk.sinotte | |
Files Changed | ||||
MODIFY
/icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/util/EnvUtils.java
MODIFY /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/application/VersioningResourceHandler.java |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #32963 | Fri Jan 04 16:03:28 MST 2013 | mircea.toma | |
Files Changed | ||||
MODIFY
/icefaces3/trunk/icefaces/compat/core/src/main/resources/META-INF/resource-dependency.xml
MODIFY /icefaces3/trunk/icefaces/ace/component/resources/icefaces.ace/META-INCLUDE/resource-dependency.xml MODIFY /icefaces3/trunk/icefaces/core/src/main/resources/META-INF/resource-dependency.xml MODIFY /icefaces3/trunk/icefaces/ace/component/resources/icefaces.ace/datetimeentry/datetimeentry.js |
Ken Fyten
made changes -
Summary | Support JSF resource versioning comprehensively | Add new resource versioning scheme for improved caching behaviour |
Issue Type | Improvement [ 4 ] | New Feature [ 2 ] |
Ken Fyten
made changes -
Summary | Add new resource versioning scheme for improved caching behaviour | New resource versioning scheme for improved caching behaviour |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Deryk:
{ externalContext.setResponseHeader("Expires", Util.HTTP_DATE.format(options.expiresBy)); }There is both a "library" version and "resource" version for resources. An example of using both is provided in the JSF spec and shows the final rendered resource to look like:
basic/2_3/script.js/1_3_4.js
Using the versions feature of JSF could help. At least with regards to resource changes between releases but I'm not sure we bundle any of our resources with a version number. For example, when I look at the ACE resources, no versioning is provided that I can see.
The spec also states that:
"An implementation (of a Resource Handler) may perform caching of the resource metadata to improve performance if the ProjectStage is ProjectStage.Production."
This implies that setting ProjectStage to Development could/should prevent caching. Looking at some of our resource handling code (for example DynamicResourceDispatcher), I do see that we are setting some heading related to caching:
externalContext.setResponseHeader("ETag", encode(resource));
externalContext.setResponseHeader("Cache-Control", "public");
externalContext.setResponseHeader("Content-Type", options.mimeType);
externalContext.setResponseHeader("Last-Modified",
Util.HTTP_DATE.format(options.lastModified));
if (options.expiresBy != null)
But I don't see any mechanism that might allow it to be configurable in any way or whether we honour the Development setting (at least yet, it would take me some more time to dig through it). I would have thought that if the date changed on the file then the "Last-Modified" header would have changed. Unless you go backwards with the releases - that might not trigger a reload of the cached resource if the date was actually older.