Page History

...

Related: Geode Modularization - An approach, Proposal for Geode Modularization, How to stop dependency leakage in 10 steps.pdf

Problem

Apache Geode uses many libraries and frameworks to complete features. These libraries will be on the classpath for global access within the JVM using a global Java ClassLoader (default behavior). Apache Geode has the ability to run custom code deployed onto the server side. This means that logic that requires data can be run where the data is located, which results into potentially faster response times, as there are less network hop and serialization steps required to complete a single operation. Writing custom code allows users to tailor make their logic to solve their problem. This code can use either the libraries that Apache Geode has available on its classpath OR deploy the libraries that the code requires to complete the functionality. In the latter scenario, it is possible that the custom deployed code requires/uses libraries that are conflicting in version or implementation with the libraries that Apache Geode uses. A prime example of this is Apache Geode Management use of the Spring Framework.

...

This proposal is aimed at ONLY solving/resolving problem problems that one is faced when deploying custom code, into Apache Geode, and use any library/framework or version that one chooses without affecting the core Apache Geode system or without being affected by the libraries/framework that Apache Geode uses.

This proposal is not there to help define how to modularize one's code (as per the related reading) or any other approaches (like API/SPI) to simplifying code and implementation.

Solution

As per the "related" content How to stop dependency leakage in 10 steps.pdf, the proposal hinges on the JBoss Modules library. This library will enable the capability to deploy modular code into Apache Geode and not affect or be affected by the libraries used by Apache Geode.

With JBoss Modules the following features are possible:

• 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

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. 

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 librariesDescribe your solution and how it’s going to solve the problem. This is likely the largest section of your proposal and might even include some high-level diagrams if you are proposing code changes. While all important aspects need to be covered, also keep in mind that shorter documents are more likely to be read.

Changes and Additions to Public Interfaces

...