GuavaCacheManager ignores cache specification due to eager initialization of internal cache map with static cache names [SPR-12120]

[spring-projects-issues]

Frank Scheffler opened SPR-12120 and commented

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.

---

Affects: 4.0.6

Issue Links:

• ConcurrentMapCacheManager has interdependent setters [SPR-12026] #16642 ConcurrentMapCacheManager has interdependent setters

Referenced from: commits d47c543, e1a01d4

Backported to: 4.0.7

[spring-projects-issues]

Stéphane Nicoll commented

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!

[spring-projects-issues]

Frank Scheffler commented

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?

[spring-projects-issues]

Stéphane Nicoll commented

Because relying on afterPropertiesSet prevents you to use the object as a simple pojo. Moving that logic there would break existing users.