Fix decorator abstract methods validation to match CDI specification #51439
+389
−12
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Ladicek
reviewed
Dec 8, 2025
| * Checks if a method belongs to any of the decorated types. | ||
| * A method belongs to a decorated type if it has the same name and parameter types. | ||
| */ | ||
| private static boolean belongsToDecoratedType(MethodInfo method, Set<Type> decoratedTypes, |
Member
There was a problem hiding this comment.
This method is incorrect, because it ignores methods inherited from superinterfaces of decorated types.
Member
There was a problem hiding this comment.
This should be relatively easy to fix.
Ladicek
reviewed
Dec 8, 2025
| /** | ||
| * Checks if two methods have matching parameter types. | ||
| */ | ||
| private static boolean methodParametersMatch(MethodInfo method1, MethodInfo method2) { |
Member
There was a problem hiding this comment.
This method is incorrect, because it ignores generic interfaces and decorators implementing instantiations of them.
Member
There was a problem hiding this comment.
This can actually be fairly hard to fix. I know we have utilities in ArC to do type parameter substitutions, but I'm not sure how easily they apply here.
Member
|
Also, this is completely lacking tests. |
The check for abstract methods in decorators was too restrictive. According to the CDI specification, decorators may declare abstract methods that belong to decorated types. The check should only reject abstract methods that do not belong to any decorated type. Changes: - Modified Decorators.createDecorator() to check if abstract methods belong to decorated types before rejecting them - Added methodExistsInHierarchy() to verify if a method exists in the decorated type hierarchy (including superinterfaces) - Added allParamsMatch() helper to compare method signatures - Now checks abstract methods from decorator class and inherited from superclasses (as mentioned in the TODO comment) - Added comprehensive test cases for the fix This fixes the issue where decorators with abstract methods that belong to the decorated interface were incorrectly rejected. Note: This fix does not handle generic interfaces with type parameters (e.g., GenericInterface<T> with T resolved to String). This is a known limitation that could be addressed in a follow-up PR. Fixes: quarkusio#51196
fabriciolima
force-pushed
the
fix/decorator-abstract-methods-check
branch
from
a7ec8d6 to
6c58e91
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current check for abstract methods in decorators was too restrictive. According to the CDI specification, decorators may declare abstract methods that belong to decorated types. The check should only reject abstract methods that do not belong to any decorated type.
Changes:
This fixes the issue where decorators with abstract methods that belong to the decorated interface were incorrectly rejected.