Page History

...

Currently, Geode components , like the Cache, can be created and shutdown directly using things like the CacheFactory classCacheFactory, in the case of Cache or RegionFactory in the case of Region. After the completion of the work proposed by the  ClassLoader Isolation RFC, the sub-projects containing Cache, Region, and other Geode components will be loaded as separate modules with their own ClassLoaders, rendering these components inaccessible from outside of the module framework. The below graphic shows the division between the system and the module ClassLoaders.

The modules can access classes from the system ClassLoader, but code outside cannot directly reference classes defined in the modules and must use service loading (like ClassLoader.loadService(...)) to access them.

Let's use 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 is loaded as a module, as shown above, and is inaccessible from the system ClassLoader. In order to access classes from ith in the module systemmodules, they must implement an interface that exists outside of the module system, is accessible from the system ClassLoader and that doesn't depend on anything reference any classes from inside the module system, and is accessible from the system ClassLoader so it can be used for performing a service lookupso they can be services loaded. While Cache is an interface, it requires several other classes from geode-core making it difficult to decouple and move out of geode-coreto a separate sub-project. 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 proposed solution is the creation of a ComponentManagementService interface. The interface will live in a sub-project outside of accessible from the module system ClassLoader, allowing it to be used for service loading. There will be an implementation of ComponentManagementService for each type of component (Cache, Region, LuceneIndex, etc.), that will reside in the same module as the component. 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

implementation will be able to access classes from inside the module system, such as CacheFactory and Cache, allowing it to create, manage, and destroy its associated component. Different types of components will be identified using a ComponentIdentifier class, which will largely consist of a name. The ComponentManagementService interface will have the following methods:

• A method to create the component.
• A method to destroy the component.
• A method that returns the created component.
• A method that takes a ComponentIdentifier and determines whether or not the ComponentManagementService can create a specific type of component.

The basic flow for creating a component will be as follows:

1. Start with a ComponentIdentifier representing the type of component to be created.
2. Load all implementation of ComponentManagementService from the module system.
3. Ask each implementation if it can create the type represented by the ComponentIdentifier until you find one that can.
4. Ask the found ComponentManagementService to create the component.
5. Store the ComponentManagementService so it can be used later to destroy the created component. (Or a ComponentInstance?)

ComponentInstance: Parameterized, holds the component and the associated ComponentManagementService. When asked to destroy, it passes the instance back to the ComponentManagementService to be destroyed.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

...