New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate Spring Session Data Store implementations #768

Closed
rwinch opened this Issue Apr 27, 2017 · 0 comments

Comments

Projects
None yet
1 participant
@rwinch
Member

rwinch commented Apr 27, 2017

Spring Session 1.x provides all Spring Session Data Store implementations in the same jar. This is convenient, but it makes for a number of disadvantages:

  • The jar becomes larger the more data store implementations that are added
  • Due to being centralized within Spring Session it puts a strain on Spring Session committers who do not know every data store implementation. This strain slows development of new data stores and prevents additional features from being implemented
  • It makes the documentation complicated. Right now there is a division between XML, Java Config, & Boot. Each of those is divided by data store and each of those is divided by features (i.e. Servlet integration, Spring Security integration, find by username support, etc). This makes it very difficult to document and read. Breaking up by data store simplifies the document structure which makes reading and writing easier.

The plan going forward is to externalize each of the Data Store implementations. Modules that have an owner that is a Spring Team committer will be maintained within spring-projects. Modules that do not have an official commiter will be maintained externally. We will provide links to each implementation to make it easier for users to find.

Modules that wish to participate should follow the same version of the core Spring Session module. Any version that shares the same major and minor version (i.e. only varies by the patch version) should work with one another. This means that if Spring Session is on 2.1.x and a new project wants to participate it should start with version 2.1.0.RELEASE.

@rwinch rwinch added the passivity label Apr 27, 2017

@rwinch rwinch added this to the 2.0.0 M1 milestone Apr 27, 2017

@rwinch rwinch self-assigned this Apr 27, 2017

@rwinch rwinch added the build label Apr 27, 2017

rwinch added a commit that referenced this issue Apr 27, 2017

Remove Mongo
Fixes gh-768

@rwinch rwinch closed this in 02da23a Apr 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment