We are using GuavaCacheManagers with explicit cache names configured, since we combine them using the CompositeCacheManager and require different cache specifications for each cache. When injection both a cache builder specification and cache names, the order of calling the appropriate setters is important, since setCacheNames() eagerly initializes the internal cache map, while setCacheSpecification() then tries to modify the CacheBuilder. Thus, the specification is effectively ignored without any errors.
I strongly suggest storing the configured cache names as list of strings and initializing them in an afterPropertiesSet() method.
So far, our work-around is to switch the order of the property XML tags in our XML configuration file, but this seems odd, since the order usually shouldn't matter.
#16642 ConcurrentMapCacheManager has interdependent setters
Thanks for the report. GuavaCacheManager has been updated in the same spirit as what we did for #16642. It is now possible to change the way the caches have to be created and that will effectively recreate the known caches.
This should land in 4.1.0.BUILD-SNAPSHOT in a couple of hours, please give it a try.
Juergen Hoeller, could you please add this one to your backport list? Thanks!
Thanks for the proper fixing. However, I do not understand, why we aren't simply using InitializingBean.afterPropertiesSet() instead of refreshing the caches. In fact, the caches are being initialized twice the ways it looks to me from the current code, aren't they?