Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • ClassLoader Isolation
  • Module Code visibility
  • Library and Framework usage freedom
  • Usage of different versions of code and libraries in the JVM at the same time
  • Simplified modular experience w.r.t modular code deployment maintenance

  draw.io DiagrambordertruediagramNameClassLoader ComponentssimpleViewerfalsewidthlinksautotbstyletoplboxtruediagramWidth1061revision1 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. The new bootstrapping mechanism will bootstrap Apache Geode components using a ModularService, 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
bordertrue
diagramNameClassLoader Components
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1061
revision1
 


The bootstrapping implementation is "simple". At this time, all that the LifecycleService will do is

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.

...