Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ConfigurationClassUtils fails to introspect inner classes with dot name syntax (and silently ignores it) [SPR-12390] #16998

Closed
spring-projects-issues opened this issue Oct 29, 2014 · 1 comment
Assignees
Labels
in: core status: backported type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 29, 2014

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:

  • #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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 29, 2014

Juergen Hoeller commented

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.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: backported type: bug
Projects
None yet
Development

No branches or pull requests

2 participants