Description
Olaf Otto opened SPR-12626 and commented
During the resolution of AnnotationMetadata, the following issue arises if a class A with classloader Ca and a super class B with classloaderCb is processed in the ConfigurationClassParser (provided Cb is not the parent of Ca, for instance when using imported types in OSGi)
org.springframework.beans.factory.BeanDefinitionStoreException: Failed to load bean class: <A> nested exception is java.io.FileNotFoundException: class path resource path/to/B.class] cannot be opened because it does not exist
at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:291)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanFactory(ConfigurationClassPostProcessor.java:242)
Here, the parsing of the super class is unaware of the class loader of the extending class:
String superclass = metadata.getSuperClassName();
...
MetadataReader reader = this.metadataReaderFactory.getMetadataReader(superclass);
return reader.getAnnotationMetadata();However, this also is an architectural issue, as it is an explicit design goal of the ClassMetadata not to load the type (resulting in the defining class loader being ignored), as state in the ClassMetaData JavaDoc:
* in a form that does not require that class to be loaded yet.As there is no way to determine the defining class loader without loading the class, I do suggest to drop this design goal as it directly contradicts proper treatment of class loading semantics.
Affects: 3.2.13
Attachments:
- SPR-12626-testcase.patch (5.03 kB)