Description
Currently, Spring Boot auto-configuration applies customization to the JCache CacheManager
after the creation of (any) configured, "named" caches declared with the spring.cache.cache-names
property in Spring Boot application.properties.
If the Spring Boot CacheManagerCustomizer(s)
for the JCache CacheManager
were to wrap ("decorate") the underlying JCache caching provider's CacheManager
implementation (for example: Hazelcast) so that instances of JCache Caches
created with the custom wrapped/decorated CacheManager
using CacheManager.createCache(..)
could also be wrapped and decorated as well, and most likely the case, then the current order for customization vs. cache creation in Spring Boot does not currently allow this to happen.
This order of customization is in contrast to the inverse behavior of Spring Boot's auto-configuration that applies customization to Spring's own CacheManager
(Adapter) implementation for the underlying JCache CacheManager
created/customized in the dependent bean definition as seen in the Spring CacheManager
bean definition.
By applying customization to the Spring JCacheCacheManager
immediately after creation, this ensures that the Spring CacheManager
will be customized before any Spring Caches
are created.
I'd also argue that there do exist cases where wrapping the JCache CacheManager
implementation (rather than Spring's CacheManager
implementation) is advantageous and even necessary, since other libraries or frameworks (e.g. Hibernate) also depend on caching, and do so using the JCache API.