[MAGNOLIA-6223] Provide proper API for resource change communication Created: 26/May/15  Updated: 25/Jan/18  Resolved: 14/Apr/16

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 5.4.6

Type: Task Priority: Major
Reporter: Magnolia International Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MAGNOLIA-6220 Resources: clarify pathPattern usage ... Closed
relates to MAGNOLIA-6338 New template scripts on the classpath... Closed
relates to MGNLRES-261 Resources app: AdminCentral UI interf... Closed
relates to MAGNOLIA-6627 Improve the #equals() result reliabil... Closed
causality
is causing MAGNOLIA-6643 Editing translation files doesn't tri... Closed
dependency
is depended upon by MAGNOLIA-6215 YAML configuration not removed or de-... Closed
is depended upon by MAGNOLIA-6451 YAML configuration: changes in includ... Closed
relation
is related to MAGNOLIA-6278 Files added at the same time as their... Closed
supersession
supersedes MAGNOLIA-6611 Relativize paths for deleted resource... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: Resource reloading without restart
Sprint: Basel 39
Story Points: 8

 Description   

The current interface and implementation of Origin.watchForChanges() is flawed in a several aspects:

  • The origins don't necessarily trigger callbacks for all files (e.g if a directory is modified, its children won't necessarily be called back)
  • Thus, we end up having to traverse the modified directory anyway. And this obviously doesn't tell us that a file in a that directory was removed.
  • Current Origin implementations mandate that the underlying resource (file, node, ...) actually exist
  • The above thus makes it difficult to callback with a ResourcePath that was deleted, regardless of whether we pass an event type in the visitor or not.
  • At least for the case of registries and configuration, we'll probably end up calling back the registry and have it reload everything. In turn, that means that passing a ResourceVisitor (or Predicate and Function like we had previously) just won't cut it.


 Comments   
Comment by Ilgun Ilgun [ 31/Dec/15 ]

Still valid remarks on the issue are;

  • The origins don't necessarily trigger callbacks for all files (e.g if a directory is modified, its children won't necessarily be called back)
  • Thus, we end up having to traverse the modified directory anyway. And this obviously doesn't tell us that a file in a that directory was removed.

An investigation should be made for every origin except ClasspathResourceOrigin.

Comment by Christopher Zimmermann [ 12/Jan/16 ]

I closed the subtasks because in my tests on the filesystem the registries are properly updated when:

  • A directory with files in it are added.
  • A directory with files is removed.
  • An include file is changed.
Comment by Christopher Zimmermann [ 12/Jan/16 ]

TODO: When 6451 is complete, review to see if this ticket is complete. Test and determine if there are additional follow-up tickets to create.

Comment by Ondrej Chytil [ 04/Mar/16 ]

There's 1 specific use case not working and since this ticket covers more issues I just mention it here rather than creating a new ticket.
Adding new light modules into running instance is not working under Windows 10. We saw it just once in remote session with one prospect due to lack of Win 10 machines but here's what happened:

  • register some folder as resources file in magnolia.properties and start instance
  • create new sub-folder (aka light module) with templates/pages structure
  • add page definition and its template script
  • you can see those files loaded to resources app
  • but the page template cannot be used in pages app, template configuration is not loaded properly until instance is restarted
  • strangely if hotfix in resources app is created the definition works
Generated at Mon Feb 12 04:12:28 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.