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). An example of this is logging; geode-log4j explicitly depends on geode-logging, and geode-logging, while it doesn't state it, requires geode-log4j to be on the classpath. There is also a similar relationship between geode-core and geode-http-service. Normally, this is fine because everything is on the classpath, but when modularized, geode-logging won't be able to access geode-log4j unless it explicitly depends on it, but if that were the case, there would be a cyclical dependency, which is not allowed.
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.
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 will have a similar effect to having everything on the classpath, but differs in that modules will look inside themselves first before getting classes from other modules. This allows modules to access whatever they need, without allowing version conflicts, like we would get with everything on the classpath.
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.
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?