Skip to content
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

AopUtils.getMostSpecificMethod does not return original method for proxy-derived method anymore #32365

Closed
chrismanning-elementsuite opened this issue Mar 4, 2024 · 1 comment
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) status: backported An issue that has been backported to maintenance branches type: regression A bug that is also a regression
Milestone

Comments

@chrismanning-elementsuite
Copy link

chrismanning-elementsuite commented Mar 4, 2024

Affects: 5.3.30, 5.3.31, 5.3.32


Since 5.3.30 AopUtils.getMostSpecificMethod is no longer giving the correct result in our code. The problem was introduced in recent changes to ClassUtils.getMostSpecificMethod in the check to determine if the method is overridable and to only continue the search if it is - if it is not overridable then it is assumed that it is already the most specific method and returns it. However, this is not the correct logic in some cases.

In our case the method passed in comes from a runtime-generated Proxy and we use this util to get the original method (with generic params intact). This generated method appears to have a final modifier - thus is not considered overridable by the new code. I don't think this is the correct logic as the original method is in fact overridable - it has been overriden by the generated method. Previously, the final modifier was not considered so the logic was effectively "this method could not have been overriden". Now, the logic is "this method cannot be overriden further".

Minimal test case (passes on 5.3.29, fails on 5.3.30+):

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;
import java.util.List;

import org.junit.Test;
import org.springframework.aop.framework.ProxyFactory;
import org.springframework.aop.support.AopUtils;

public class AopTest {

   interface I {
      void f(List<String> a);
   }
   static class C implements I {
      public void f(List<String> a) {
      }
   }

   @Test
   public void aopMostSpecificMethod() throws Exception {
      final C c = new C();
      final ProxyFactory proxyFactory = new ProxyFactory(c);
      final I proxy = (I) proxyFactory.getProxy();
      final Type paramType = AopUtils.getMostSpecificMethod(
            proxy.getClass().getMethod("f", List.class),
            AopUtils.getTargetClass(proxy)).getParameters()[0].getParameterizedType();
      assertTrue(paramType instanceof ParameterizedType);
      assertEquals(String.class, ((ParameterizedType) paramType).getActualTypeArguments()[0]);
   }

}
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 4, 2024
@jhoeller jhoeller self-assigned this Mar 4, 2024
@jhoeller jhoeller added type: regression A bug that is also a regression in: core Issues in core modules (aop, beans, core, context, expression) and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Mar 4, 2024
@jhoeller jhoeller added this to the 6.1.5 milestone Mar 4, 2024
@jhoeller
Copy link
Contributor

jhoeller commented Mar 4, 2024

While we usually call getMostSpecificMethod for a method in a single class hierarchy and not across different subhierachies of the same base interface, I can see that the method did work in such scenarios before. We'll try to restore this while preserving the optimization that we meant to accomplish for our common use cases in #30272.

@jhoeller jhoeller changed the title AopUtils.getMostSpecificMethod does not return base method for Proxied class AopUtils.getMostSpecificMethod does not return original method for proxy-derived method anymore Mar 4, 2024
@jhoeller jhoeller added the for: backport-to-6.0.x Marks an issue as a candidate for backport to 6.0.x label Mar 4, 2024
@github-actions github-actions bot added status: backported An issue that has been backported to maintenance branches and removed for: backport-to-6.0.x Marks an issue as a candidate for backport to 6.0.x labels Mar 4, 2024
@jhoeller jhoeller added the for: backport-to-5.3.x Marks an issue as a candidate for backport to 5.3.x label Mar 4, 2024
@github-actions github-actions bot removed the for: backport-to-5.3.x Marks an issue as a candidate for backport to 5.3.x label Mar 4, 2024
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: backported An issue that has been backported to maintenance branches type: regression A bug that is also a regression
Projects
None yet
Development

No branches or pull requests

3 participants