CacheAutoConfiguration triggers early initialization of cache components #13038
Comments
snicoll
added a commit
to snicoll/spring-boot
that referenced
this issue
May 3, 2018
This commit restructures the Cache auto-configuration to avoid an early init on CacheManager (and potentially all its infrastructure). Rather than adding a dependency on the validator bean, this commit relies on the fact CacheAspectSupport checks if a CacheManager is available in the afterSingletonsInstantiated callback. In this case, a simple bean with a postconstruct callback is enough. Closes spring-projectsgh-13038
|
Hi, has this fix been merged to 2.0.2.RELEASE? thanks |
|
@jtktam if you click on the link above your comment, it states in which tags the fix is included. Yes, it's included (we always merge forward so whatever is in |
|
I think I am still running into the early initialization bug in 2.0.2.RELEASE, that's why i wanted to confirm it's merged forward |
|
@jtktam we don't use the tracker for questions (see the guidelines for contributing). Feel free to come chat with us on Gitter. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While working on a feature to demonstrate how to swap a
CacheManagerin a BPP, I found that the cache auto-configuration was triggering early initializations.This basically boil down to
CacheManagerValidatorwhose purpose is to throw an exception "early enough" if noCacheManagercould be auto-configured. Removing that locally was enough to fix the problemThe text was updated successfully, but these errors were encountered: