@EnableCaching provokes early initialization of any config class declaring a CacheManager [SPR-12336]

[spring-projects-issues]

Stéphane Nicoll opened SPR-12336 and commented

See spring-projects/spring-boot#1711

Interesting analysis: https://gist.github.com/dsyer/ebeb25d5afbdd9242cd5.

---

Affects: 4.1.1

Issue Links:

• Programmatic creation of caching proxies using CacheProxyFactoryBean does not work [SPR-16295] #20842 Programmatic creation of caching proxies using CacheProxyFactoryBean does not work

Referenced from: commits 0e36402, 5aefcc8, e2518e0

[spring-projects-issues]

Stéphane Nicoll commented

Actually @EnableCaching is not really different from @EnableTransactionManagement. The difference really is that the caching use case has more dependencies.

If we add a TransactionManagementConfigurer to that Application, we get the same issue. The solution would be to move the reconciliation in the interceptor instead of doing it through configuration.

The problem is that we really need to defer that after the full initialization of the bean. So the context may start just fine and the first method requiring caching would lead to an exception. This makes the code of the interceptor overcomplicated so I am wondering if that's worth it.

[spring-projects-issues]

Stéphane Nicoll commented

Well in fact, @EnableTransactionManagement is different because it delays the resolution of the default transaction manager as late as possible. This is something we could do for caching as well and it has positive effects on the project referenced in the boot issue.

[spring-projects-issues]

Stéphane Nicoll commented

This is now fixed and will be available in the next 4.1.2.BUILD-SNAPSHOT