Skip to content

ConfigurationClassPostProcessor's MetaData resolution ignores the defining class loader, failing to load classes from transitive class loaders [SPR-12626] #17227

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

Closed
spring-projects-issues opened this issue Jan 14, 2015 · 3 comments
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

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:

@spring-projects-issues
Copy link
Collaborator Author

Olaf Otto commented

Added a patch containing a testcase reproducing the issue

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Jan 14, 2015

Olaf Otto commented

Related: #14977

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement in: core Issues in core modules (aop, beans, core, context, expression) and removed type: enhancement A general enhancement labels Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: ideal-for-contribution An issue that a contributor can help us with status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants