FieldandClassshould be avoided in elements that participate in the context cache key, but currentlyBeanOverrideContextCustomizeruses aSet<Class>OverrideMetadatawould be a candidate to represent logically equal override points, but it does store theFieldfor now- As a consequence of removing the
FieldfromOverrideMetadata, we'd have to figure a way to accommodate for qualifiers.BeanFactory.isAutowireCandidateisn't such a good option anymore unless we can get away with storing these mappings in theBeanOverrideRegistrarsomehow.
For context caching purposes, a good litmus test is to copy a test class that has the @SpringJUnitConfig annotation and run both test classes with the logging level of org.springframework.test.context.cache set to debug. The last logging statement about the number of cached contexts should then be 1, not 2.
Comment From: snicoll
It turns out that the only sensible way to restore a correct use of the TCF cache is by passing the identified metadata to the object that needs it, and that make it fail with AOT.
The current status on main was changed to attempt to make the feature work with AOT. This confirms what was suggested in https://github.com/spring-projects/spring-framework/issues/32925#issuecomment-2143454959.