ConfigurationClassUtils.checkConfigurationClassCandidate(…) tries to create a MetadataReader for the class name of the BeanDefinition to be checked. If that lookup fails (e.g. because one misspelled the classname in an XML configuration file), the resulting IOException will only appear in the debug logs.
As we're inspecting a BeanDefinition about to be used, not being able to create a MetadataReader indicates a more fundamental problem with the configuration and should probably be at least logged at a more severe log level.
Another option would be to fix the inconsistency in ClassUtils (ultimately used by the MetadataReader implementations) which currently has some methods (e.g. forName(…)) that mitigate different styles of demarcating an inner class (.-separated VS. $-separated) while some other methods (e.g. (convertClassNameToResourcePath(…)) don't seem to apply this mitigation.
Affects: 3.2.11, 4.1.1
#17002 Configuration class parsing should reuse metadata from AnnotatedBeanDefinition as far as possible
Since we're introspecting all bean definitions there, unresolvable class names aren't so unusual, e.g. for optional modules... If those beans are actually required, they are going to fail later on. Our introspection algorithm shouldn't really be the driver for a failure here, or even raise such cases too prominently.
As noted, that problem largely goes away anyway when SimpleMetadataReaderFactory is capable of resolving the dot name syntax for inner classes, bringing it in sync with ClassUtils.forName. I've addressed that part for 4.1.2 now, to be backported to 4.0.8 and 3.2.12 as well.