Description
Olaf Otto opened SPR-10343 and commented
A change from 3.1.3.RELEASE to 3.1.4.RELEASE in org.springframework.context.annotation.ConfigurationClassParser causes the getImport method to recursively load all annotations of a class(looking for @Import
), using a metadataReaderFactory solely relying on the classloader of the annotated type. Resulting, the method fails in environments with classloader isolation (i.e. OSGi):
// the package containing @MyAnnotation is explicitly
// imported in the bundle containing AnnotatedType
@MyAnnotation
public class AnnotatedType {
}
// This meta annotation stems from the spring bundle, i.e. is a transitive
// import from @MyAnnotation and not explicitly imported into the bundle containing "AnnotatedType"
@Scope("prototype")
public @interface MyAnnotation {
}
Resulting exception as the SimpleMetadataReader tries to obtain @Scope
from the classloader containing AnnotatedType:
-- snipp --
Caused by: java.io.FileNotFoundException: class path resource [org/springframework/context/annotation/Scope.class] cannot be opened because it does not exist
at org.springframework.core.io.ClassPathResource.getInputStream(ClassPathResource.java:157)
at org.springframework.core.type.classreading.SimpleMetadataReader.<init>(SimpleMetadataReader.java:49)
at org.springframework.core.type.classreading.SimpleMetadataReaderFactory.getMetadataReader(SimpleMetadataReaderFactory.java:80)
at org.springframework.core.type.classreading.CachingMetadataReaderFactory.getMetadataReader(CachingMetadataReaderFactory.java:101)
at org.springframework.core.type.classreading.SimpleMetadataReaderFactory.getMetadataReader(SimpleMetadataReaderFactory.java:76)
at org.springframework.context.annotation.ConfigurationClassParser.getImports(ConfigurationClassParser.java:291)
at org.springframework.context.annotation.ConfigurationClassParser.getImports(ConfigurationClassParser.java:293)
at org.springframework.context.annotation.ConfigurationClassParser.getImports(ConfigurationClassParser.java:293)
at org.springframework.context.annotation.ConfigurationClassParser.doProcessConfigurationClass(ConfigurationClassParser.java:223)
at org.springframework.context.annotation.ConfigurationClassParser.processConfigurationClass(ConfigurationClassParser.java:147)
at org.springframework.context.annotation.ConfigurationClassParser.parse(ConfigurationClassParser.java:124)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:289)
... 12 more
The 3.1.3 implementation relied on the annotation metadata of the annotation directly applied to the processed type - perhaps it is possible to reintroduce such an approach in favor of the recursion in getImports.
Affects: 3.1.4, 4.2.5, 4.3.1
Attachments:
- spr-10343-consuming.zip (3.13 kB)
- spr-10343-declaring.zip (2.37 kB)
Issue Links:
- Prevent duplicate @Import processing and ImportBeanDefinitionRegistrar invocation [SPR-9925] #14558 Prevent duplicate
@Import
processing and ImportBeanDefinitionRegistrar invocation - Do not fail with a circular @Import error caused by an @ComponentScan [SPR-14517] #19086 Do not fail with a circular
@Import
error caused by an@ComponentScan
- ConfigurationClassParser does not work with scanner-provided ClassLoader [SPR-15245] #19810 ConfigurationClassParser does not work with scanner-provided ClassLoader
Backported to: 4.2.8
0 votes, 6 watchers