MAGNOLIA-6338 New resources on the classpath are not loaded
MAGNOLIA-6338 - Getting issue details... STATUS
ClasspathResourceOrigindoes an initial scan and builds/caches a tree structure of classpath resourcesThis results in fast listing/expanding of directories in the app
But when to update the cached structure?
Ideal solution:
Most resources (template scripts, web resources)
- accessed/served "upon request"; we don't need to cache anything
- rely on IDE's hot deployment
#getByPathcreatesClasspathResourceobjects on the fly
YAML files
- we need to reload configuration when they are modified
- already handled by the
ClasspathScanner(except deletions)
App
#listChildrenshould also createClasspathResourceson the fly
Challenges:
#traverseWithdelegates recursively to#listChildren(from abstract impl)we don't want to scan whole CP over and over again
change
#traverseWithimplementation, and/or that of layered origin- scan each origin first with predicate
- layer results
- call visitor function
Assumptions
Getting the full list of classpath resources is rather cheep
- (be it via classloader, guava or reflections)
- Comparing last-modified dates is costly
MAGNOLIA-6440 duplicate resources on classpath prevent magnolia from start with a NPE
MAGNOLIA-6440 - Getting issue details... STATUS
Tree structure cache in
ClasspathResourceOriginis kept as a map- key is path as
String - value is the
ClasspathResourceobject
- key is path as
ClasspathResourcesare double-linked as well to parent resource and to list of child resources
Problem:
2 Jars may contain resources with same name (one as file, one as directory), e.g.
README(file) in a jarREADME/test.txtin another jar
Solution:
Remove assumption that path is unique identifier
- use path and type instead
Change map of cache into a list
- access entries via guava finding/filtering
#getByPathshould return file resources when both file and directory existLayeredResourceOrigin(#aggregateSet) also has to be adapted to reflect change of unicity
MAGNOLIA-6501 Expose event type from ClasspathScanner
MAGNOLIA-6501 - Getting issue details... STATUS
- ClasspathScanner does fix timed scan and finds the modification of ClasspathResource s.
- Upon detection of these resources, ClasspathResourceOrigin is called back from ClasspathScanner.
Problem:
- ClasspathResourceOrigin does not know, if thats a resource addition, deletion or modification.
- Hence, it ends up trying to get the resources itself as well for checking if the resource is present or not.
- There are multiple callbacks in ClasspathScanner and each modification is attempted to update the ClasspathResourceOrigin with the amount of callbacks.
Solution:
- We can get modification type information such as deletion, addition and modification, beforehand in ClasspathScanner and pass this so called Events in the callback function.
- And then, ClasspathResourceOrigin do not need to verify if given modified resource is present or not.
- Create a wrapper class around these callbacks and pass just one callback to ClasspathScanner, therefore, we will end up updating the resource once in ClasspathResourceOrigin and applying all callbacks right after.