Skip to content

Revise ClassUtils.getMostSpecificMethod to check that provided method really belongs to the provided class hierarchy #23824

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.

Sign up for GitHub

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

Jump to bottom
Closed
artembilan opened this issue Oct 16, 2019 · 1 comment
Closed

Revise ClassUtils.getMostSpecificMethod to check that provided method really belongs to the provided class hierarchy #23824

artembilan opened this issue Oct 16, 2019 · 1 comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply

Comments

@artembilan
Copy link
Member

artembilan commented Oct 16, 2019 •
edited
Loading

The ClassUtils.getMostSpecificMethod() doesn't check any correlations between a targetClass and method.getDeclaringClass() causing unexpected behavior when a maybe method requested from fully different hierarchy.

See discussion here: https://github.com/spring-projects/spring-integration/pull/3082/files#r335614474
@artembilan artembilan mentioned this issue Oct 16, 2019
Merged
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Oct 16, 2019
@rstoyanchev rstoyanchev added the in: core Issues in core modules (aop, beans, core, context, expression) label Nov 11, 2021
@snicoll
Copy link
Member

snicoll commented Nov 29, 2023

I believe this is the expected behavior.

The Javadoc for getMostSpecificMethod for the targetClass states:

the target class for the current invocation (may be null or may not even implement the method)

The method description also states:

Given a method, which may come from an interface, and a target class used in the current reflective invocation, find the corresponding target method if there is one

@snicoll snicoll closed this as not planned Won't fix, can't repro, duplicate, stale Nov 29, 2023
@snicoll snicoll added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rstoyanchev @snicoll @artembilan @spring-projects-issues