Update Geode from Spring 4 to Spring 5
To be Reviewed By: 2019/11/08
Authors: John Martin, Udo Kohlmeyer
Status: Draft | Discussion | Active | Dropped | Superseded
Superseded by: N/A
Related: N/A
Problem
What is this proposal solving? Why does the problem matter? How does the problem affect the user?
Spring Framework 4 is end of life. Extended maintenance will be ending Q1 2020, with security patches continuing, however the intention is that applications should be moving to Spring 5. (https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions)
Additionally, as Spring 5 was released in July of 2016, users that utilize server-side code are not able to write modern day applications using the new features available in Spring 5. For users starting an application, using the prescribed approach of using Spring Initializer (which generates roughly 17 million projects a year), will use Spring 5 libraries by default. This means, the prescribed recommended usage approach already conflicts with our underlying libraries.
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.
Our proposal is to replace the existing Spring 4 libraries with Spring 5.x libraries. The scope of this work includes the investigation of the usage of the Spring libraries within Apache Geode, specifically the usages of Spring within geode-core. The goal of this proposal is to restrict the usage of Spring libraries to only Geode modules that require them.
The final outcome is to have a Spring version agnostic system, which will allow for upgrading of the project without affecting the core.
Changes and Additions to Public Interfaces
If you are proposing to add or modify public interfaces, those changes should be outlined here in detail.
None. As this is a library update, no public interface changes are envisioned. There might be some changes to code/module structure within the project, but nothing that is user/publicly facing.
Performance Impact
Do you anticipate the proposed changes to impact performance in any way? Are there plans to measure and/or mitigate the impact?
None. Current plans to mitigate impact are to run the existing performance test suite before and after upgrade to verify “no impact”.
Backwards Compatibility and Upgrade Path
Will the regular rolling upgrade process work with these changes?
How do the proposed changes impact backwards-compatibility? Are message or file formats changing?
Is there a need for a deprecation process to provide an upgrade path to users who will need to adjust their applications?
There are no changes that affect backwards compatibility. All changes are going to be local to the node instance only.
Prior Art
What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?
- The project will be using EOL libraries without support if something were to fail.
- Without upgrading Spring libraries will severely impede the project from supporting the users wanting to use current Spring libraries and projects.
- The deployment of Spring enabled features on the server-side will not be possible, as users will experience Spring version compatibility issues. This will deter users from using the project and seek alternative products to support their use case.
- Future work to use newer technology approaches and architectures (Reactive, k8s, etc.) could possibly be simplified using the Spring abstractions.
FAQ
Answers to questions you’ve commonly been asked after requesting comments for this proposal.
Errata
What are minor adjustments that had to be made to the proposal since it was approved?