Field
andClass
should be avoided in elements that participate in the context cache key, but currentlyBeanOverrideContextCustomizer
uses aSet<Class>
OverrideMetadata
would be a candidate to represent logically equal override points, but it does store theField
for now- As a consequence of removing the
Field
fromOverrideMetadata
, we'd have to figure a way to accommodate for qualifiers.BeanFactory.isAutowireCandidate
isn't such a good option anymore unless we can get away with storing these mappings in theBeanOverrideRegistrar
somehow.
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.