To be Reviewed By: August 20thSeptember 27, 2020
Authors: Udo Kohlmeyer
Status: Draft Draft | Discussion | Active | Dropped | Superseded | Implemented
Superseded by: N/A
Related: ClassLoader Isolation
Problem
With the introduction of ClassLoader isolation into Geode a new problem is created. In many areas of the Geode codebase standard Java concepts are using used to load resources that are on the Classpath or load services. In the a ClassLoader isolated world the standard Java functions of `ServiceLoader.load` and `Class.getResourceAsStream` won't work anymore. Thus This is due to the fact that we don't have a flat Classpath any more, where everything is on the same ClassLoader and easily accessible. There will now be multiple ClassLoaders and each is responsible for the files / classes / resources within it. In oder for order for this functionality to work, the modular system described in the ClassLoader Isolation RFC now becomes responsible for the delegation of these commands to the underlying modular system to be fulfilled. Yet, we don't want to make the user / developer need to know HOW to complete this work, thus a level of abstraction is required. Another feature to consider is the ability to delegate to the existing standard JAVA concepts, like `ServiceLoader` and `getResourceAsStream`.
Anti-Goals
This proposal is not to create YA-ClassLoader abstraction, but merely provide an abstraction that would keep the current usage of ClassLoader features inside of the Geode codebase but at the same time enabling the capability to keep the same functionality in the ClassLoader Isolation world.
Solution
In order to have a more extendible architecture, a mechanism is required to extend the system's functionality by adding new implementations. The approach proposed is to introduce a ModuleService ClassLoaderService. This ModuleService ClassLoaderService is an interface that will expose the functional methods to the code, but it's implementation is provided / selected at startup / runtime. This ModuleService The ClassLoaderService will be accessible in the Geode system and delegate to the relevant implementation to resolve service implementations, load classes or load resources.
In this proposal, all ClassLoader specific functionality, within the Apache Geode system with be replaced with an equivalent ClassLoaderService function.
To keep the current non-modular ClassLoader functionality, a DefaultClassLoaderService will be provided to provide a seamless transition between Modular ClassLoading and single ClassLoader functionality.
Gliffy Diagram | |||||
---|---|---|---|---|---|
|
The biggest problem to this solution will be there locations where this ClassLoaderService will have to be added to. In a prototype, this work was completed and over 200 classes (majority of them tests) were touched. In this proposal, the
Use Cases
Scenario 1: : Apache Geode starts with no ClassLoaderService Implementation explicitly defined
Expected behavior: Apache Geode will use the DefaultClassLoaderService as the ClassLoaderService
Scenario 2: Apache Geode starts with custom ClassLoaderService implementation
Expected behavior: Apache Geode will use custom ClassLoaderService implementation for all ClassLoader service functionality
Changes and Additions to Public Interfaces
This addition requires that in some cases new public constructors and new public methods for various components / modules within Geode to be added. The existing constructors and methods will be kept and delegated to the configured or defaulted ClassLoaderService implementation.
In many cases, component will be constructed with the ClassLoaderService as a field in order to avoid having to unnecessarily add it to existing function / service calls.
Performance Impact
No anticipated performance impact.
Backwards Compatibility and Upgrade Path
No expected backward compatibility impact. As this is an addition to the code base, all existing public constructors, interfaces and service methods will be kept and delegated to the correct constructor and service call.
Prior Art
What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?
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?
...