Follow-up of #28980 since it should not be useful anymore now that related proxies are inferred.
Comment From: sdeleuze
@snicoll Maybe we should keep it (potentially with an updated Javadoc) for the manual proxy creation that can't be inferred?
Comment From: snicoll
We could. I still don't like the current method arrangement. It's consistent with similar methods in this class but the consumers of the new method could use something a bit more explicit.
I'd like to see something like hints.proxies.registerJdkProxy(MyProxy.class, asSpringJdkProxy()) or something like that where asSpringJdkProxy is a consumer of the builder, adding the 3 interfaces.
Comment From: snicoll
I think you misunderstood it, indeed. I am not talking about adding something to the core hint API (that would be a conceptual cycle). I am rather advocating that spring-aop provides a first-class, idiomatic method that allows to register a JDK proxy as an AOP proxy. I believe that the method above achieves this scenario, something like:
public static Consumer<Builder> asAopProxy() {
return builder -> builder.proxiedInterfaces(SpringProxy.class, Advised.class, DecoratingProxy.class);
}
Comment From: sdeleuze
Thanks for the additional details. I don't think AopProxyUtils should import hints APIs and creating a dedicated class in spring-aop for it seems too much for me as well. I would be for your proposal if there was a way to make it available directly in the hints API in spring-core. Since that's not the case, I think what we have currently is reasonable and I would be for closing this issue and keep what we have.