Oliver Drotbohm opened SPR-12390 and commented

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

Issue Links:

• Configuration class parsing should reuse metadata from AnnotatedBeanDefinition as far as possible [SPR-12394] #17002 Configuration class parsing should reuse metadata from AnnotatedBeanDefinition as far as possible

Referenced from: commits 725ad0d, bb6349f, 2d874d7

Backported to: 4.0.8, 3.2.12