Rework @Configuration classes to be compatible with @Configuration(proxyBeanMethods=false)

[wilkinsona]

Juergen has just merged support for @Configuration(proxyBeanMethods=false) into Framework 5.2 snapshots. We’re going to make as much use of that as possible in Boot 2.2.0.M2 (spring-projects/spring-boot#9068). There’s a configuration class in Boot where we need @Bean methods to be proxied because they subclass a Spring Session configuration class that requires it. The class in question is o.s.b.a.s.RedisSessionConfiguration$SpringBootRedisHttpSessionConfiguration which is a subclass of o.s.s.d.r.c.a.w.h.RedisHttpSessionConfiguration. Could you please consider reworking things in Spring Session so that the proxy isn’t needed?

[wilkinsona]

Beyond reworking RedisHttpSessionConfiguration, it would be beneficial if all of Spring Session's @Configuration classes that are intended to be sub-classed by users could be annotated with @Configuration(proxyBeanMethods=false) to indicate that they do not require proxying. I believe those classes are (at least) the following:

• HazelcastHttpSessionConfiguration
• JdbcHttpSessionConfiguration
• RedisHttpSessionConfiguration
• RedisWebSessionConfiguration

[vpavic]

I was about to ask whether only RedisHttpSessionConfiguration is affected by this. If we are to change patterns used in our @Configuration classes, we'd probably like to apply it consistently throughout the codebase.

[wilkinsona]

Doing it consistently across all @Configuration classes, and not just those that users may sub-class, is worthwhile if you have the time to do it. You should see faster startup times and reduced memory usage (both heap and non-heap memory).

[vpavic]

After taking a closer look at the problem, the originally reported problem will be fairly simple to address in RedisHttpSessionConfiguration and we're going to do it in #1362.

Reworking our @Configuration classes to be able to marked as proxyBeanMethods = false is something that will require more substantial changes, mostly due to those classes implementing ImportAware. We'll leave this issue open to track that effort.

[vpavic]

This is now resolved thanks to Framework's changes in ImportAware handling made in spring-projects/spring-framework#22920 (thanks for the ping @eleftherias).