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

Compare with Current View Page History

« Previous Version 3 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

Geode component = any class/feature that, when created/started, adds to or changes the behavior of Geode, like Cache, Region, or LuceneIndex. 

Currently, Geode components, like the Cache, can be created and shutdown directly using things like the CacheFactory class. After the completion of the work proposed by the  ClassLoader Isolation RFC, Cache and other Geode components will be inaccessible outside of the module framework because they will be loaded using a different ClassLoader, not the default system ClassLoader. Let's continue using Cache as an example; Cache is located in geode-core, which will be on the inside of the system and therefore be inaccessible from the system ClassLoader. In order to access classes from ith in the module system, they must implement an interface that exists outside of the module system, doesn't depend on anything inside the module system, and is accessible from the system ClassLoader so it can be used for performing a service lookup. While Cache is an interface, it requires several other classes from geode-core making it difficult to decouple and move out of geode-core. This is the case for more components than just Cache and impacts more modules that just geode-core. Without an external interface to use to load the implementation from the relevant module, we have no way of creating or managing components like Cache or Region.

Anti-Goals

this document is intended to solve the problem of creating, managing, and destroying Geode components within the module framework and is not concerned with...

  • The implementation of modules within Geode
  • Adding, removing, or modifying the behavior of any Geode components

Solution

The proposed solution is the creation of a ComponentManagementService interface. The interface will live in a sub-project outside of the module system, allowing it to be used for service loading. The interface will look something like the following:

  • init(args...) - create a component given some arguments
  • close(args...) - destroy the previously created component given some arguments
  • getInitializedComponent() - returns the created component if it has been created
  • canCreateComponent() - determines whether the specific implementation can create a certain type of component given a Componentidentifier

The above mentions another class, ComponentIdentifier, which is new per this proposal. ComponentIdentifier will consist of a name and path, signifying which component it represents and which module that component lives in. There will be an implementation of ComponentManagementService for each Geode component that will liv in the same sub-project as the component. 

Changes and Additions to Public Interfaces

Addition of ComponentManagementService and ComponentIdentifier. No changes to existing pubic interfaces.

Performance Impact

No anticipated performance impact.

Backwards Compatibility and Upgrade Path

No backward compatibility impact.

Prior Art

An alternative to this solution is to refactor every component to have an interface that doesn't depend on anything besides other interfaces and pulling all of the interfaces out of their current sub-projects into a new one specifically for interfaces to be used for service loading.

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