Provide better facilities for third-party Spring Session implementations

[ghillert]

Currently, org.springframework.boot.autoconfigure.session.Storetype is a hard-coded enumeration of Spring Boot-supported session providers. It would be nice, if there was a way to make that more flexible in regards to third-party session providers. Maybe add a StoreType.OTHER property with an option to add a custom value to org.springframework.boot.autoconfigure.session.SessionStoreMappings?

Similarly, org.springframework.boot.autoconfigure.session.AbstractSessionCondition is presently not public. Even in present state this condition could still be useful for third-party providers as the condition would immediately back-off if any spring.session.store-type property is set.

[wilkinsona]

Hi, @ghillert!

Unfortunately, I'm not sure that it'll be possible to plugin in an unknown third-party Spring Session implementation, at least not without a fairly major overhaul of the auto-configuration. In addition to StoreType and SessionStoreMappings:

• ServletSessionRepositoryImplementationValidator and/or ReactiveSessionRepositoryImplementationValidator would also have to be aware of the new implementation
• SessionAutoConfiguration would have to be ordered after the auto-configuration for the third-party store. This could possibly be achieved by ordering the third-party store auto-configuration before SessionAutoConfiguration but the direction of the dependency would arguably be wrong in that case.

I'm not sure what, if anything, we can do to improve the situation here. I'll flag for team meeting so that we can discuss it.

[wilkinsona]

We spent quite a bit of time chatting about this today. During that discussion we realized that the current auto-configuration is more complicated than it now needs to be.

In Spring Boot 1.x, we auto-configured Spring Session 1.x which had a single spring-session module with multiple different SessionRepository implementations. This meant that the classpath could not provide a clear signal for which session store should be used. To overcome this the mandatory spring.session.store-type property was introduced.

In Spring Boot 2.0, we upgraded to Spring Session 2.x which has separate modules for each different SessionRepository implementation. At this time we improved things to make the store-type property optional when only a single session repository implementation is available. In situations where more than one is available, the property could still be used to determine which one to use.

We now think that we should have gone further in 2.0 and removed the store-type property entirely. In the unlikely event that multiple session repository implementations are available we should instead define and document which will be used, just as we do for JDBC connection pools today. If for some reason a user needs multiple session repository implementations on the classpath and our defined ordering doesn't meet their needs, they can define their own SessionRepository bean and cause the auto-configuration to back off. I've opened #27756 to track this change.

Given the intended direction, we don't want to do anything to make the current arrangement more extensible. Auto-configuration for a third-party session store should be ordered with @AutoConfigureBefore(SessionAutoConfiguration) and should define a SessionRepository bean that will cause Boot's auto-configuration of a SessionRepository to back off. With this arrangement, there should be no need for a user to set the store-type property when auto-configuration for a third-party session repository implementation is available. Its presence and auto-configuration ordering should be sufficient to give the user what they want.

[vpavic]

To add to what @wilkinsona wrote, I believe the current auto-configuration support is actually already quite friendly to third-party Spring Session integrations as some aspects of it, such as SessionRepositoryFilterConfiguration and SessionAutoConfiguration.ServletSessionConfiguration#cookieSerializer, will be auto-configured even with third-party session repository implementations that are configured outside of Spring Boot's auto-configuration.