Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Aug 26, 2014 · 3 comments
Assignees
Labels
in: core status: backported type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 26, 2014

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:

  • #16642 ConcurrentMapCacheManager has interdependent setters

Referenced from: commits d47c543, e1a01d4

Backported to: 4.0.7

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 27, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 27, 2014

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 28, 2014

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.

@spring-projects-issues spring-projects-issues added type: bug status: backported in: core labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 4.1 GA milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: backported type: bug
Projects
None yet
Development

No branches or pull requests

2 participants