Consider restructuring Spring Session configuration properties

[vpavic]

This is a follow-up on #17278, which handled changes to flush mode related configuration properties. More changes in configuration support infrastructure are expected for Spring Session Corn-M3, and when that's in place it might be good idea to revisit the overall structure of Spring Session related configuration properties.

[wilkinsona]

One change that we've already identified is to introduce spring.session.servlet.<store>.* properties where there's a store-specific configuration setting that applies to the Servlet web stack and not to the reactive web stack.

[snicoll]

Unless I misunderstood your comment @wilkinsona, it feels inconsistent to me to introduce the servlet prefix only if necessary. Shouldn't we harmonize and have a servlet and reactive for everything, excluding reactive for store that may not work (yet?) with the reactive stack?

[wilkinsona]

I'd envisaged three "sets" of properties:

• spring.session.<store>.* for store-specific configuration that applies to both web stacks
• spring.session.servlet.<store>.* for store-specific configuration that only applies to the Servlet web stack
• spring.session.reactive.<store>.* for store-specific configuration that only applies to the reactive web stack

[snicoll]

Thanks for the feedback. Considering that we may add things in one stack or the other (or both) I think I prefer going with the consistency to not have the first case at all and just duplicate configuration options in servlet and reactive when both are available.

[vpavic]

I agree with what @snicoll outlined - that was also my original understanding from #17278 discussion.

Omitting stack prefix seems risky in terms of breaking users, as it's not always easy to know whether a SessionRepository implementation will adopt some feature, and if it does at what pace compared to other implementations.

[snicoll]

We've discussed this one this week and the plan is to go with a store specific configuration and keep the existing properties in 2.2 in a deprecated fashion. For stores that only support servlet, a replacement can be provided right away. However, for stores that support both, we need some logic and the user will have to choose explicitly.

Looking at the current package structure, introducing additional types do not spark joy so I am considering moving things in a servlet and reactive sub-packages.