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

Compare with Current View Page History

« Previous Version 5 Next »

ClassLoaderService

To be Reviewed By: August 20th, 2020

Authors: Udo Kohlmeyer

Status: Draft | Discussion | Active | Dropped | Superseded

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 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 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 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

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. This ModuleService is an interface that will expose the functional methods to the code, but it's implementation is provided / selected at startup / runtime. This ModuleService will be accessible in the Geode system and delegate to the relevant implementation to resolve service implementations, load classes or load resources.

ModuleService

In this proposal, the 

Use Cases

Scenario 1: 

Expected behavior: 

Changes and Additions to Public Interfaces



Performance Impact

No anticipated performance impact.

Backwards Compatibility and Upgrade Path

No backward compatibility impact.

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?


  • No labels