Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-6523

Refactor ClasspathResourceOrigin and stabilise its hot resource modification support

    XMLWordPrintable

Details

    • Task
    • Resolution: Fixed
    • Neutral
    • 5.4.5
    • None
    • None
    • None

    Description

      ClasspathResourceOrigin suffers from several problems which are very hard to overcome without significant modifications of current implementation. The list of topics which needs attention includes:

      • development time resource reloading,
      • retrieval of classpath resource contents,
      • classpath configuration flexibility,
      • classpath file/folder hierarchy maintenance
      • etc.

      Main issue as it appears is related to how classpath resources are retrieved at the moment. We heavily rely on the context ClassLoader to provide resource URLs, last modified dates and InputStreams. While such an approach works well for the case of production mode (i.e. classloader doesn't do and never needs to do any reloading), in dev mode when we can deliberately update, remove or add a resource - class loader may or may not be able to resolve it (similar how IDE's support class reloading - a new/deleted/modified class support is there, but limited and somewhat unreliable => such tools as JRebel exist and bloom).

      Attempt to obtain via classloader a URL or contents of the resource which e.g. has been detected as a new by Reflections library (which looks into re-deployed jar files and doesn't rely on classloader itself) may lead to all sorts of IO/Runtime exceptions. The idea which could help in such case is to obviously stop unconditionally relying on the classloader but rather maintain the ability to point the classpath resources directly into the deployed jars and should file stream be needed - refer to jar file itself.

      Hereby it is proposed to take the following actions to improve the situation with the classpath resources support:

      • use dedicated ClasspathEntry objects for resource identification instead of mere Strings - encapsulate path operations, provide simple hierarchy-related interface, distinguish between folder and file, provide transparent stream API.
      • aggregate all related classpath-related parameters in a simple component (jar URLs, resource predicates, monitored resource pattern, default charset etc)
      • revise the purpose, naming and role of ClasspathScannerService - each time after scanning it has info about current resources and yet we have to maintain a copy of resource cache in ClasspathResourceOrigin manually. It is proposed to introduce ClasspathService which would be a centralised access point of classpath entry hierarchy, origin itself would be just a consumer of such service.
      • introduce a alternative (light!) version of such service for production mode - essentially no monitoring, less overhead, ful relying on context classloader.
      • the solution has to be tested against cases of excessive data served via classpath (hundreds/thousands of resources)
      • solution has to be tested against most common app servers and at least in IntelliJ and Eclipse

      Checklists

        Acceptance criteria

        Attachments

          Issue Links

            Activity

              People

                apchelintcev Aleksandr Pchelintcev
                mmuehlebach Michael Mühlebach
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  Checklists

                    Task DoR

                    Time Tracking

                      Estimated:
                      Original Estimate - Not Specified
                      Not Specified
                      Remaining:
                      Remaining Estimate - 0d
                      0d
                      Logged:
                      Time Spent - 6.5d
                      6.5d