-
Task
-
Resolution: Fixed
-
Major
-
None
-
None
-
None
-
-
Empty show more show less
-
Empty show more show less
-
Basel 39
-
8
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.
- is causing
-
MAGNOLIA-6643 Editing translation files doesn't trigger reload
- Closed
- is depended upon by
-
MAGNOLIA-6215 YAML configuration not removed or de-registered after physical removal
- Closed
-
MAGNOLIA-6451 YAML configuration: changes in included files don't trigger a reload of the registered item
- Closed
- is related to
-
MAGNOLIA-6278 Files added at the same time as their parent directory are not loaded
- Closed
- relates to
-
MAGNOLIA-6220 Resources: clarify pathPattern usage and Predicates in Origin methods
- Closed
-
MAGNOLIA-6338 New template scripts on the classpath are not loaded
- Closed
-
MGNLRES-261 Resources app: AdminCentral UI interface crashes upon attempt to expand/collapse a deleted folder
- Closed
-
MAGNOLIA-6627 Improve the #equals() result reliability for DefinitionDecorator when CachingDefinitionDecorator is involved
- Closed
- supersedes
-
MAGNOLIA-6611 Relativize paths for deleted resources in FileSystemResourceOrigin
- Closed