(inferred) is used as a special method name within the core container. When AOT runs, it should handle that and not write that value.
Comment From: snicoll
Actually I am having some second thoughts on this one. @jhoeller what do you think?
Comment From: snicoll
We should "infer" the close method at build time rather than letting the container do this at runtime. As we're using reflection to invoke the method, that would miss a hint anyway.
Comment From: snicoll
We're going to try to lazily infer this when setTargetType is available in AOT use cases.
Comment From: snicoll
I am still seeing (inferred) in generated code so it looks like the fix above does not handle all cases.
Comment From: snicoll
OK the good news is that it was a local change I was working on that mutates the bean definition late. This has the effect of making the cache stale or something which brings back the default value for some reason. We should identify why that is and keep the resolution around.
Comment From: snicoll
https://github.com/spring-projects/spring-framework/commit/2e1538a20b585132dcc671ac0a2491e4d3b7ab5a now mutates the original bean definition.
Comment From: bclozel
Removing the workaround in ApplicationContextAotGeneratorRuntimeHintsTests still fails with the following:
Missing <"ReflectionHints"> for invocation <java.lang.Class#getMethods> on type <org.springframework.context.testfixture.context.generator.annotation.InitDestroyComponent>
with arguments [].
Stacktrace:
<"org.springframework.beans.BeanUtils#findMethodWithMinimalParameters, Line 350
org.springframework.beans.factory.support.DisposableBeanAdapter#findDestroyMethod, Line 261
org.springframework.beans.factory.support.DisposableBeanAdapter#determineDestroyMethod, Line 250
org.springframework.beans.factory.support.DisposableBeanAdapter#<init>, Line 120
org.springframework.beans.factory.support.AbstractBeanFactory#registerDisposableBeanIfNecessary, Line 1857
Is there another instance of this problem?
Comment From: snicoll
Thanks for sharing that. It's unrelated to this specific issue and affects any use of a destroy method. I've created #29077