At the core of the issue are AliasFor type annotations which are synthesized into a proxy with SynthesizedAnnotationInvocationHandler which delegates to AbstractAliasAwareAnnotationAttributeExtractor.getAttributeValue(..) to get the actual annotation value. When it sees that this annotation is synthesized and has alias value mismatch it results in InvocationtargetException which is trapped inside of AnnotationUtils.getValue() operation which simply return null. This can and most likely will result in subsequent error downstream, but the error message may be misleading (see https://jira.spring.io/browse/INT-4263)
IMHO, while I do believe that the initial intention of returning null for non existing attributes should stay, I also believe that we should trap InvocationTargetException and re-throw. While that may result in breaking change, it's one of those where it's for the good cause.
Affects: 4.3.8
Issue Links:
INT-4263 Misleading error message during misconfigured components.
Basically the idea is to catch InvocationTargetException see if its target is AnnotationConfigurationException and if so re-throw it. I actually noticed that we're already doing that in several other related operations, which made it a bit easier by delegating to already existing rethrowAnnotationConfigurationException(..);
Oleg Zhurakousky opened SPR-15481 and commented
At the core of the issue are AliasFor type annotations which are synthesized into a proxy with SynthesizedAnnotationInvocationHandler which delegates to AbstractAliasAwareAnnotationAttributeExtractor.getAttributeValue(..) to get the actual annotation value. When it sees that this annotation is synthesized and has alias value mismatch it results in InvocationtargetException which is trapped inside of AnnotationUtils.getValue() operation which simply return null. This can and most likely will result in subsequent error downstream, but the error message may be misleading (see https://jira.spring.io/browse/INT-4263)
IMHO, while I do believe that the initial intention of returning null for non existing attributes should stay, I also believe that we should trap InvocationTargetException and re-throw. While that may result in breaking change, it's one of those where it's for the good cause.
Affects: 4.3.8
Issue Links:
Referenced from: pull request #1401, and commits 299b9d6, 17f274f, 16fdda0
The text was updated successfully, but these errors were encountered: