[MAGNOLIA-6218] Expose resource's last modification date Created: 19/May/15 Updated: 02/Jun/15 Resolved: 25/May/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | resource-loader |
| Affects Version/s: | None |
| Fix Version/s: | 5.4 |
| Type: | New Feature | Priority: | Neutral |
| Reporter: | Michael Mühlebach | Assignee: | Michael Mühlebach |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | platform-cell | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Date of First Response: | |||||||||
| Comments |
| Comment by Magnolia International [ 23/May/15 ] |
|
This issue actually needs to move to the main project, since that's where the API is. The servlet as implemented in |
| Comment by Magnolia International [ 24/May/15 ] |
|
Rebased and slightly rearranged Michael's work from the feature/ I'm not 100% convinced by what we do in the ClasspathOrigin, nor by exception handling for this in all 4 origins. |
| Comment by Mikaël Geljić [ 26/May/15 ] |
|
Reviewed, Side note, I know we've covered that already but I'll go anyway: the spec considers *not knowing* a valid case, thus returning -1. |
| Comment by Magnolia International [ 26/May/15 ] |
|
The IOException}}s that are caught by {{FileSystemOrigin#getLastModified and ClasspathOrigin#getLastModified both signify something's broken with the underlying system*; ignoring them there is IMO akin to ignoring a RepositoryException when we get the value of a JCR property that we know exists (or should exist): there's nothing relevant you can do to treat it, and ignoring it (returning -1 in this case) will just delay the problem until later.
Removed redundant log messages, merged on master. |