org.springframework.beans.factory.BeanDefinitionStoreException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • Spring STS - unable to resolve properties
    via Stack Overflow by user871199
    ,
  • 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) {code} 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) {code} Here, the parsing of the super class is unaware of the class loader of the extending class: {code:java} String superclass = metadata.getSuperClassName(); ... MetadataReader reader = this.metadataReaderFactory.getMetadataReader(superclass); return reader.getAnnotationMetadata(); {code} 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: {code:java} * in a form that does not require that class to be loaded yet. {code} 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.
    via by Olaf Otto,
  • 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) {code} 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) {code} Here, the parsing of the super class is unaware of the class loader of the extending class: {code:java} String superclass = metadata.getSuperClassName(); ... MetadataReader reader = this.metadataReaderFactory.getMetadataReader(superclass); return reader.getAnnotationMetadata(); {code} 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: {code:java} * in a form that does not require that class to be loaded yet. {code} 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.
    via by Olaf Otto,
    • org.springframework.beans.factory.BeanDefinitionStoreException: Failed to load bean class: com.myPackage.myProject.calendar.bpo.BusinessDirectoryBPOImpl; nested exception is java.io.FileNotFoundException: class path resource [com/myPackage/framework/bpo/BaseBPOImpl.class] cannot be opened because it does not exist at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:180)

    Users with the same issue

    Unknown visitor1 times, last one,