In latest Spring 6 milestones there's a warning logged now any time a default-destroy-method is set and the method is missing from any beans (one logged per bean):
e.g.:
11:13:42.928 - WARN [org.springframework.beans.factory.support.DefaultListableBeanFactory:591] - Destruction of bean with name 'net.shibboleth.idp.saml.attribute.transcoding.AbstractSAML2AttributeTranscoder.NamingFunction#71a3a190' threw an exception
java.lang.NullPointerException: Cannot invoke "java.lang.reflect.Method.getParameterCount()" because "destroyMethod" is null
I don't think Spring 5 or earlier has been logging this, and before we rototilled a lot of bean files I wanted to make sure this change was intentional and going to stay. It's certainly not wrong, just somewhat inconvenient for a lot of existing files.
I did note an old (like 2009) issue filed and fixed that mentions a similar NPE and perhaps had been "fixed", suggesting maybe this is not intentional.
Comment From: scantor
I think this may have been fixed, but I have not actually found the commit that changed the behavior. In any case, I don't see any logging even on TRACE with this message in it.
Comment From: snicoll
In latest Spring 6 milestones
Can you please try with 6.0.9 and let us know if you can reproduce? I think this has been fixed indeed.
Comment From: scantor
We're not seeing it with any recent versions, I was just hoping to track down the actual change for "confidence". The line number should correlate to one of the MILESTONE releases so I'm still going to try and find it, but I think this can be closed.
Comment From: snicoll
OK cool. I think this is (now) a duplicate of #30301. Sorry for the lack of follow-up here!
Comment From: scantor
I do see the particular log message in the code base in a different class, and it's still logged on warn, so it's possible it's still there in certain cases but just not the one we originally reported.
Comment From: snicoll
The warning must be logged if something legit failed. The problem here is that it was logged for the wrong reason.
Comment From: scantor
I believe the logger must be inherited, the actual class I guess was DefaultSingletonBeanRegistry and it does appear to get logged there. It's possible there was a guard added that prevents it from attempting the destroy that caused it to throw and then get logged.
Comment From: scantor
Ah, I missed the duplicate there, thank you, yes that's it. So fixed recently. Thanks again.