Remove spring.session.store-type in favor of a defined order for which implementation will win when multiple are available

[wilkinsona]

Looking at #27738 caused us to realize that the auto-configuration for Spring Session is more complex than it needs to be. To simplify it, we'd like to remove spring.session.store-type. In the unlikely event that multiple session repository implementations are available we should 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.

[wilkinsona]

We've decided to reorder things a bit. We'd like the order to be:

1. Redis
2. JDBC
3. Hazelcast
4. Mongo

[ae-govau]

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.

We stumbled across this today, when adding a optional support for a Redis session store to an app we look after which is deployed with different session stores by different users. Previously we thought we had been using spring.session.store-type to toggle between jdbc and hazelcast, but since support for the property was removed a while back, we must have just gotten lucky until now.

I tried implemented the suggestion above, e.g. the following looked to be a simple low-impact change to have the desired effect:

import org.springframework.boot.autoconfigure.condition.ConditionalOnProperty;
import org.springframework.boot.autoconfigure.session.HazelcastSessionConfiguration;
import org.springframework.boot.autoconfigure.session.JdbcSessionConfiguration;
import org.springframework.boot.autoconfigure.session.RedisSessionConfiguration;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;

@Configuration
public class SessionStore {
    @ConditionalOnProperty(value = "myapp.session.store-type", havingValue = "hazelcast")
    @Import({HazelcastSessionConfiguration.class})
    static class HazelcastSession {}

    @ConditionalOnProperty(value = "myapp.web.session.store-type", havingValue = "jdbc")
    @Import({JdbcSessionConfiguration.class})
    static class JdbcSession {}

    @ConditionalOnProperty(value = "myapp.web.session.store-type", havingValue = "redis")
    @Import({RedisSessionConfiguration.class})
    static class RedisSession {}
}

The intention being that this would have the side effect of putting SessionRepository bean in, and thus sidestep the ordering issue. However this above won't compile because:

org.springframework.boot.autoconfigure.session.HazelcastSessionConfiguration is not public in org.springframework.boot.autoconfigure.session; cannot be accessed from outside package

Can anyone suggest a straight forward alternative approach?

[ae-govau]

I found these 3 classes which preliminary testing seems to work for our use-case using the pattern above:

import org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration;
import org.springframework.session.hazelcast.config.annotation.web.http.HazelcastHttpSessionConfiguration;
import org.springframework.session.jdbc.config.annotation.web.http.JdbcHttpSessionConfiguration;