This page captures several efforts that have been conducted in order to fix problems and improve the classpath resource origin.

MAGNOLIA-6338 New resources on the classpath are not loaded

MAGNOLIA-6338 - Getting issue details... STATUS

  • ClasspathResourceOrigin does 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?

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
    • #getByPath creates ClasspathResource objects on the fly
  • YAML files

    • we need to reload configuration when they are modified
    • already handled by the ClasspathScanner (except deletions)
  • App

    • #listChildren should also create ClasspathResources on the fly
Challenges:
  • #traverseWith delegates recursively to #listChildren (from abstract impl)

  • we don't want to scan whole CP over and over again

  • change #traverseWith implementation, 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 ClasspathResourceOrigin is kept as a map

    • key is path as String
    • value is the ClasspathResource object
  • ClasspathResources are 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 jar
    • README/test.txt in 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
  • #getByPath should return file resources when both file and directory exist
  • LayeredResourceOrigin (#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.

 

 

 

 

 

 

  • No labels