Page History

...

To be Reviewed By:

Authors: Udo Kohlmeyer

Status: Draft | Discussion | Active | Dropped | Superseded

...

Related: Geode Modularization - An approach

Problem

What is this proposal solving? Why does the problem matter? How does the problem affect the user?

Anti-Goals

, Proposal for Geode Modularization

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.

In order versions of Apache Geode, the bundled Spring Framework version was on v4.3.x. Which meant that any user that wanted to use Spring in their custom code would be restricted to using that version. Manually upgrading the a Spring Framework version higher, like v5.x, could result in version conflicts in either the custom deployed code, Apache Geode or in both. In all cases this is behavior that is unwarranted.

Without a solution that does not restrict users on framework and versions, it will be impossible for users to most effectively use Apache Geode to their advantage. It also adds an extra burden on the Apache Geode system to always be up-to-date with all the latest versions of libraries, but also have tested with many different combinations of library versions. This of course is an impossible feat, which would result in always being on the wrong version than what the custom code required. i.e Apache Geode has upgraded to the latest version of libraryA (v2.0) but the custom deployed code is reliant on (v1.0) OR vice versa. One cannot keep everybody happy!!! 

What is required is the ability to deploy custom code, that functions as expected (and tested externally) and that does not affect the Apache Geode core system or breaks in an unexpected manner due to version conflicts. The ability to deploy custom code with the freedom to use whatever libraries/frameworks and versions of those without any restriction. The expected behavior should be similar to a Web Container or Application Container. Where the web/application does not affect the container system that is runs or is affected by the libraries that the container system uses.

Anti-Goals

This proposal is aimed at ONLY solving/resolving problem 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.What is outside the scope of what the proposal is trying to solve?

Solution

Describe 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.

...