ConfigurationClassPostProcessor's MetaData resolution ignores the defining class loader, failing to load classes from transitive class loaders [SPR-12626] #17227
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
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)
Here, the parsing of the super class is unaware of the class loader of the extending class:
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:
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:
The text was updated successfully, but these errors were encountered: