Page tree
Skip to end of metadata
Go to start of metadata
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