...
draw.io Diagram | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The initial bootstrapping implementation is "simple". At this time, all that the LifecycleService will do isThe implementation will bootstrap the Apache Geode system using the current bootstrapping mechanism of `LocatorLauncher` or `ServerLauncher`.
There will be two bootstrapping options:
- Using the current class loading mechanism
- Using the new JBoss module loading system to achieve class loading isolation
The Bootstrap module will use the ModuleService to load modules/components or load service implementations using the standard ServiceLoader functionality. Other than the bootstrapping change the "normal" behavior of the system should not change.
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 Geode-Management register the module with the ModuleService using the uploaded JAR-file.
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 deployment of custom code, like gfsh deploy jar, will be handled by the ModuleService. The ModuleService 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.
...