You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

To be Reviewed By: August 20th, 2020

Authors: Patrick Johnson

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: ClassLoader Isolation

Problem

Many of Geode's sub-projects depend on one another. In the world of the ClassLoader Isolation work, those dependencies are explicitly defined when modules are loaded and linked to one another. For the most part, this is fine as JBoss is designed to handle dependencies between modules. However, some modules have bidirectional dependencies (A dependents on B and B depends on A).


We want to be able to enable and disable features at runtime. This means loading and unloading modules. We could unload, reload, and relink every module whenever a new module is added or removed, but that is potentially costly. We need a way to update the linkages between modules without having to refresh every module.

Anti-Goals

This proposal is only intended to solve the problems of allowing bidirectional dependencies between modules and the loading/unloading of modules without having to reload all modules and is unconcerned with...

  • Breaking existing bidirectional dependencies
  • Changing any dependencies between modules

Solution

The proposed solution is to introduce a linking module, which will contain no code and instead consist only of dependencies. This linking module will depend on every other module and every other module will depend on it. This creates a path between all modules so bidirectional relationships can be resolved. This solution also solves the problem of having to refresh all modules when adding or removing a module. Since all modules are linked to the linking module, it can refresh itself with the new set of loaded modules and the other modules don't have to change–they just keep their link tot he linking module.

Changes and Additions to Public Interfaces

No changes to public interfaces.

Performance Impact

No anticipated performance impact.

Backwards Compatibility and Upgrade Path

No backward compatibility impact.

Prior Art

Break all bidirectional dependencies between sub-projects and incur the cost of updating all effected modules when loading/unloading.

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?


  • No labels