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 resources
This results in fast listing/expanding of directories in the app
But when to update the cached structure?
Most resources (template scripts, web resources)
- accessed/served "upon request"; we don't need to cache anything
- rely on IDE's hot deployment
ClasspathResourceobjects on the fly
- we need to reload configuration when they are modified
- already handled by the
#listChildrenshould also create
ClasspathResourceson the fly
#traverseWithdelegates recursively to
#listChildren(from abstract impl)
we don't want to scan whole CP over and over again
#traverseWithimplementation, and/or that of layered origin
- scan each origin first with predicate
- layer results
- call visitor function
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
- value is the
- key is path as
ClasspathResourcesare double-linked as well to parent resource and to list of child resources
2 Jars may contain resources with same name (one as file, one as directory), e.g.
README(file) in a jar
README/test.txtin another jar
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 exist
#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.
- 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.
- 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.