THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
In order to have Apache Geode bootstrap correctly, Apache Geode's current bootstrapping cycle needs to be altered to accommodate for this modular loading system. In order to bootstrap the "JBoss Modules" modular environment correctly, the initiating class needs to change from org.apache.geode.distributed.ServerLauncher or org.apache.geode.distributed.LocatorLauncher to using org.jboss.modules.Main. The ServerLauncher or LocatorLauncher will still be invoked, as the JBoss Modules Main is a passthrough for the command. e.g The new bootstrapping mechanism will bootstrap Apache Geode components using a ModuleServiceJBoss Modules modular system, which will load the Apache Geode system into its own ClassLoader. Determining what strategy is used, will be determined by the implementation of the ModuleService. Initially the JBossModuleService will be opt-in only. This way users can migrate their implementation to match the requirements of the new ModuleService.
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The initial bootstrapping implementation is "simple". There will be a new ServerLauncher process that will know how to bootstrap Apache Geode system.
There will be two bootstrapping options:
...
The determination of the bootstrapping type will be done in GFSH using an "--experimentalenable-classloader-isolation" flag. This flag will instruct instruct GFSH to either use the current class loading mechanism or use the class loading isolated ServerLaunchermechanism.
The Bootstrap module will use the ModuleService to load modules/components or load service implementations. There are currently two ModuleService implementations:
- JBossModuleService (using JBossModules for ClassLoading and Service lookups)
- ServiceLoaderModuleService (using the current Java ClassLoading and Service lookup mechanics)
The biggest change that will be visible will be when opting into using the JBoss Modules class loading. The initial targeted implementation would be the `gfsh deploy jar' .
...
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The deploy jar function initiated by running `deploy jar` from gfsh will trigger the ManagementService to JarDeploymentService to register the module with the ModuleService using DeploymentService using the uploaded JAR-file. This is done by the jar file being placed in a known location on disk. Then, the ManagementService will request the BootstrappingService to load a component of type CustomDeployedJar. The BootstrappingService will determine the location of the jar file and request from the ModuleService that the module is loaded using the jar file location.
The DeploymentService The ModuleService registration service will create a JBoss Module module construct, with the jar as a resource and a dependency on the Apache Geode system. The DeploymentService will then interact with the GeodeModuleLoader load the jar into its own module and Classloader.
The deployment of custom code, like gfsh deploy jar, will be handled by the ModuleService. The ModuleService will the JarDeploymentService and DeploymentService. The DeploymentService will load the deployed jar into its own ClassLoader with a dependency on the Apache Geode system. That way the deployed custom code will still have access to the Apache Geode's public API's, but without being exposed to its libraries.
...
Gliffy Diagram macroId 47113394-4357-4196-b05e-18686ebe5381 displayName ClassDiagram - ModuleService name ClassDiagram - ModuleService pagePin 68
Performance Impact
No anticipated performance impact.
...