DefaultAdvisorAutoProxyCreator doesn't get the target class of existing proxy [SPR-13990]

[spring-projects-issues]

Yoni Amir opened SPR-13990 and commented

I have a spring context setup like this:

<bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor" />

<bean id="defaultAdvisorAutoProxyCreator" class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator" />

I have a custom advisor, not shown in the XML snippet above, that searches for some annotations at the class level of the beans that Spring creates.
The problem is that the PersistenceExceptionTranslationPostProcessor runs first and creates a proxy around the bean. When the DefaultAdvisorAutoProxyCreator runs, it calls getClass() on the proxied bean and passes that class (something like com.sun.proxy.$Proxy) to the advisor to test for a match. The advisor is then unable to detect the annotations.
The flawed call to getClass() is in AbstractAutoProxyCreater.wrapIfNecessary() method, just before calling getAdvicesAndAdvisorsForBean().

There is a workaround, though. Adding an order attribute and ensuring that the DefaultAdvisorAutoProxyCreator runs first works. This is because the PersistenceExceptionTranslationPostProcessor can handle beans that are already proxied - it extract the target class of the proxy. This happens in AbstractAdvisingBeanPostProcessor.postProcessAfterInitialization() method. The relevant code looks more or less like this:

if (bean instanceof Advised) {
Advised advised = (Advised) bean;
if (!advised.isFrozen() && isEligible(AopUtils.getTargetClass(bean))) {

This workaround has a limitation, though. It forces a certain order in which the interceptors run, which may not be the order that I want.

Bottom line is, I think AbstractAutoProxyCreater.wrapIfNecessary() (which is called from AbstractAutoProxyCreater.postProcessAfterInitialization() needs to use the code snippet above and act similarly to AbstractAdvisingBeanPostProcessor.postProcessAfterInitialization()

---

Issue Links:

• AnnotationAwareOrderComparator getPriority does not work if bean is a proxy [SPR-13884] #18457 AnnotationAwareOrderComparator getPriority does not work if bean is a proxy

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid this is by design: Spring's AutoProxyCreators actually always create a new proxy (potentially decorating an existing proxy), whereas PersistenceExceptionTranslationPostProcessor can also add advisors to existing proxies (which it introspects the target class for). So the exposed class is actually consistent with the level of adding the advisor there.

Now, you could argue that the AutoProxyCreators should also be capable of adding advisors to existing proxies. This is internationally not part of their design though; just specific post-processors do this, making assumptions about the applicability of their particular advisors.

With respect to custom ordering, you could apply the underlying PersistenceExceptionTranslationAdvisor (or a variant thereof) directly at any level within your custom AOP setup. Alternatively, you could also configure PersistenceExceptionTranslationPostProcessor with beforeExistingAdvisors=true if that's what you'd like to enforce.

Juergen

[spring-projects-issues]

Yoni Amir commented

I understand your explanation from a technical perspective, but I don't see how you can justify it as "as designed". I think this is a serious limitation of the framework.
I recently discovered that the problem also happens when enabling caching with <cache:annotation-driven />. When the caching post processor runs first, the defaultAdvisorAutoProxyCreator fails to work properly.
Your answer makes many Spring feature problematic. I can integrate each of those features into my configuration by using their respective advisor directly, but I think it is a shame. It requires advanced understanding and is prone to errors.

Also, I didn't ask for the AutoProxyCreaters to be capable of adding advisors to existing proxies. Truly, I don't understand the difference between having one proxy or many, as long as all the advisors run at the end.
What I did ask for, is that they expose to the advisors the real target object. I write advisors that inspecting annotations on the target object to make decisions about advising. Is it not a common and legitimate way to write the advisors?

[spring-projects-issues]

Yoni Amir commented

Hi,
Just to add a bit of additional information on top of the last comment. I checked and saw that when using
<cache:annotation-driven />, Spring uses internally InfrastructureAdvisorAutoProxyCreator.
I imagine it is the same for <tx:annotation-driven>.
This effectively makes my usage of DefaultAdvisorAutoProxyCreator useless. I will have no choice but to inherit from
DefaultAdvisorAutoProxyCreator and change its behavior to expose the target bean to its advisors.