[MAGNOLIA-6523] Refactor ClasspathResourceOrigin and stabilise its hot resource modification support Created: 01/Feb/16  Updated: 04/Apr/16  Resolved: 16/Feb/16

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 5.4.5

Type: Task Priority: Neutral
Reporter: Michael Mühlebach Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 6.5d
Original Estimate: Not Specified

Issue Links:
causality
is causing MAGNOLIA-6612 DevelopmentModeClasspathFile should u... Accepted
is causing MAGNOLIA-6575 ClasspathResourceOrigin doesn't relia... Closed
is causing MAGNOLIA-6581 Classpath service won't serve resourc... Closed
dependency
is depended upon by MAGNOLIA-6440 Duplicated resources on classpath may... Closed
is depended upon by MAGNOLIA-6527 Deletion of a hot fix configuration i... Closed
is depended upon by MAGNOLIA-6524 Origins should log events around Reso... Closed
is depended upon by MAGNOLIA-6525 JRebel works with the current configu... Closed
is depended upon by MAGNOLIA-6376 ClasspathResourceOrigin should warn u... Open
supersession
supersedes MAGNOLIA-6338 New template scripts on the classpath... Closed
supersedes MAGNOLIA-6514 High usage of file descriptors caused... Closed
supersedes MAGNOLIA-6469 Deleted folders are not detected in C... Closed
supersedes MAGNOLIA-6501 Expose event type from ClasspathScanner Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Release notes required:
Yes
Date of First Response:
Epic Link: Resource reloading without restart
Sprint: Basel 31
Story Points: 13

 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

Generated at Mon Feb 12 04:15:19 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.