Polish Spring Session auto-configuration

[vpavic]

This PR replaces random @Autowired methods in Boot's subclasses of Session's configuration classes with constructor injection, therefore removing the need for @Autowired. In addition, configuration classes have been made protected to be consistent with most other equivalent inner @Configuration classes.

[snicoll]

Thanks for the PR but I don't like that. Such business shouldn't go in the constructor and @Autowired is not banned :) We just removed it when it wasn't needed, it's no reason to start moving stuff to the constructor that shouldn't go there in the first place.

[vpavic]

OK, maybe property mapping shouldn't go in the constructor.

But for the sake of reference, shouldn't constructor injection be used to reflect the class's dependencies? Effectively SessionProperties is a dependency of Boot specific subclasses of Session's configuration.

Perhaps constructor + @PostConstruct would be the best approach for the situation?

[snicoll]

method injection is not a bad thing either. If you had a single bean that uses SessionProperties you'd have a @Bean method that use method parameter injection rather than a constructor. This case isn't different and your proposal adds more lines with no benefit IMO.

[vpavic]

I respect your opinion but I don't quite agree with it.

@Bean gives a method completely different semantics so it's IMO not the best comparison here.

SpringBootRedisHttpSessionConfiguration is already using @PostConstruct to perform additional logic that relies on SessionProperties (that is injected using a method named customize, which is inappropriate). If #6649 gets merged SpringBootJdbcHttpSessionConfiguration will also use the same approach.

Benefit is IMO a cleaner design that's more consistent with the rest of the code base (meaning I didn't find a similar usage of @Autowired in the entire spring-boot-autoconfigure module). A few more lines won't harm anyone :)

[snicoll]

I think you're stuck on the "customize" part (an @Autowired method that does not start with "set") and there's really nothing wrong with that IMO. @Bean was just an example of a configuration class that has a single method: you're not going to inject the dependency in a constructor if only one method needs it and can get it from a method parameter.

SpringBootRedisHttpSessionConfiguration is doing the right thing: I need a callback to customize the configuration class I am extending from (that's not very typical in Spring Boot and I wouldn't have done that at all if I had the choice). The postconstruct is applying some validation once all the customizations on the configuration class haven been applied and that's IMO the right way to do that.