Page History

...

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

...