[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:
dependency
is depended upon by MGNLRES-144 Implement new origin-based ResourcesS... Closed
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 MGNLRES-144 will use the added method, and won't specifically implement its getLastModified, since the use-case is well covered by the DefaultServlet impl.

Comment by Magnolia International [ 24/May/15 ]

Rebased and slightly rearranged Michael's work from the feature/MGNLRES-150-last-modified, now pushed to feature/MAGNOLIA-6218-resource-lastmod.

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,
Would just consider not logging and re-throwing in ClasspathOrigin, rather keep only the exception here I guess.

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.
—And I also know we acknowledged something's gonna be badly broken anyway whenever we can't resolve that date— but then is this the place where we want to treat that/point other guys by following the trace? e.g. as opposed to #doGet?
I don't really mind, imo it would also clarify what we do regarding exception handling.

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.

  • at least that's the current empirical observation. Until we know better (ie. until we know there are cases where we get these exceptions but the resource is actually usable anyway), i'd rather not sweep the dust under the carpet by returning -1.

Removed redundant log messages, merged on master.

Generated at Mon Feb 12 04:12:25 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.