[MAGNOLIA-6130] Revisit use case and approach for observing resource changes on classpath Created: 17/Mar/15  Updated: 07/Jun/15  Resolved: 05/Jun/15

Status: Closed
Project: Magnolia
Component/s: configuration, resource-loader
Affects Version/s: None
Fix Version/s: 5.4

Type: New Feature Priority: Blocker
Reporter: Michael Mühlebach Assignee: Mikaël Geljić
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-6244 Restore "relayer" function in Layered... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:
Epic Link: Config by file / code

 Description   

We need to restore classpath observation before going final. This was made a blocker in terms of priority. See comment from May 6 for the status on that.

– old description

We should revisit and simplify the ClasspathWatcher, in particular:

  • we are concerned about performance
  • we are not sure this is strictly necessary
  • we could try to find another library/util to do that better? e.g.
  • thread mgmt

Additionally, currently we spawn one thread per ClasspathOrigin instance we have, i.e. per YamlConfigurationSource.

We should extract ClasspathWatcher and add a ClasspathWatcherService to manage a single thread.



 Comments   
Comment by Mikaël Geljić [ 06/May/15 ]

Gave a shot to a so-called ClasspathScanner + service based on the reflections library (same as we use as one-shot in ClasspathOrigin.
As much as initial scan was fairly fast (few hundreds ms), iterating over all such classpath resources to find out which ones were modified took 2 plain seconds.
As a result we disabled watching the classpath for now—by the time we reevaluate the use case and how we want to address it.

a. Either we can dramatically reduce the time for checking last-modified date (filtering out the amount of resources to be iterated over)
b. Either we rely on hot-deployment of the IDE, and need to come up with lazy definition providers, that would re-resolve bean upon each get().

Rephrasing/moving to a standalone issue.

Comment by Mikaël Geljić [ 27/May/15 ]

Raised prio to blocker. Two options:

  • In worst case, we revive the old classpath observation, as "ugly" as it may be—it's only gonna be running in dev mode anyway.
  • In best case, we invest a bit in option b. mentioned in my comment above.
Comment by Magnolia International [ 27/May/15 ]

3rd option:

Option b. is imo a waste of energy, since it'll only add value for definitions we already know about (no add, no delete)

Time to check the last-modified dates might be reduced with MAGNOLIA-6219, and further by "caching" it in the CRP at scan time, rather than retrieving it every time.

Additionally, let's not forget there are other issues such as MAGNOLIA-6223 and MAGNOLIA-6215 which would impact this. If the focus of 5.4 is on front-end devs, java-free modules, etc, those 2 seem more relevant than the classpath observation.

Comment by Philipp Bärfuss [ 27/May/15 ]

The front-end focus lead to the decision to prioritise config by files and for the YAML format. But the new configuration will be used by existing magnolia developers as well. It was also the priority to make configuration easier for everybody. It needs to work and ideally without needing a jrebel license. This is really a blocker for me.

Comment by Mikaël Geljić [ 05/Jun/15 ]
  • Using ClasspathScanner component through service, similarily Reflections-based as ClasspathOrigin's initial collection
    • though using much stricter filtering (YAML files only), see ClasspathOrigin#observedResourcesPattern() to save time on costly last-modified checks
    • scheduled with a delay of 10s between every execution
    • naively checking if last-modified dates are greater than that of last-scan
  • Service is enabled only if magnolia.develop=true
  • LegacyClasspathOrigin does not implement such watching, in particular as it's not meant to contain any config file
  • have to disable shunting loggers in ClasspathOriginTests, not reliable at present
Generated at Mon Feb 12 04:11:35 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.