AOP proxy creation breaks property initialisation [SPR-368]

[spring-projects-issues]

Erwin Vervaet opened SPR-368 and commented

Creation of a simple AOP proxy using the auto-proxy-creator breaks property initialisation for a bean where one constructor calls another constructor to set a member to a default value.

Check the attached source code for an example.

Erwin

---

Affects: 1.1 final, 1.1.1

Attachments:

• bug.zip (1.52 kB)

1 votes, 3 watchers

[spring-projects-issues]

Erwin Vervaet commented

This zip file contain a package called "bug" with sample code illustrating the issue. There are 4 files in this package:
bug.xml -> Spring bean definitions
LogInterceptor.java -> very simple method interceptor
SpringBug.java -> main class
TestBean.java -> bean used in sample

[spring-projects-issues]

Juergen Hoeller commented

This is caused by the way CGLIB works: It creates a runtime subclass of your target class for proxies, instantiating those subclasses via the respective default constructor.

So what you're experiencing is the following:

1. A instance of your target class (TestBean) is created.
2. The instance of your target class is populated (setA call).
3. A CGLIB proxy for your target class (using a runtime subclass of it) is created.
4. The constructor of that CGLIB proxy invokes the constructor of its superclass, which is the default constructor of your target class.
5. The constructor of your target class, invoked for the CGLIB proxy, calls setA with a default value.
6. The CGLIB proxy delegates setA to the target object, overwriting the value of A with the default value.
7. Result: Your target object has the default value again, rather than the populated one from step 2.

I'm aware that the above is highly untuitive. But unfortunately, I don't see a way to avoid this with CGLIB: It's a consequence of the way CGLIB works... Note that JDK dynamic proxies don't show such weird behavior, as they are plain interface-based proxies!

So I recommend to switch to JDK dynamic proxies, through letting your target classes implement interfaces: In that case, the AOP proxy factory will preferably create JDK dynamic proxies for your targets (as long as you don't explictly specify "proxyTargetClass=true").

Juergen

[spring-projects-issues]

Colin Sampaleanu commented

Ughhh, this is nasty if there's no workaround. We can't really expect people to know if classes they are proxying (for which they may not have source) do internal calls between constructors.

[spring-projects-issues]

Eugene Kuleshov commented

Actually in most cases it is possible to detect if constructor is changing some properties or calling other nondefault constructors.

[spring-projects-issues]

Erwin Vervaet commented

Would it be impossible to defer proxy->target delegation untill after the proxy is fully constructed using a state flag or something?
That way you could prevent the construction of the proxy messing with the state of the target, which seems logical.

Erwin

[spring-projects-issues]

Chris Nokleberg commented

There is a workaround, as suggested above. Have a state flag in your interceptor which is set once the object has been constructed. Until that time, dispatch all method calls to the base class via the MethodProxy "invokeSuper" method (instead of "invoke"). Hibernate does exactly this in their proxy implementation.

CGLIB used to ignore all methods invoked via the constructor, but it is useful to be able to capture them, sometimes. Just maybe not for Spring.

Let me know if you need help putting a patch together.

Chris

[spring-projects-issues]

Juergen Hoeller commented

Fixed by Rob Harrop, committed to CVS.

[spring-projects-issues]

Erwin Vervaet commented

I retested with 1.1.2 and the problem is still there...?
Should this be reopened?

Erwin

[spring-projects-issues]

Rob Harrop commented

Re-opened for investigation.

[spring-projects-issues]

Juergen Hoeller commented

Looks like this requires special support in CGLIB. As it is unlikely to get a stable CGLIB update in time for 1.1.3, we will target this for 1.2 RC1 instead.

Juergen

[spring-projects-issues]

Vasanth Loka commented

I have run into a similar situation.
I have a webapp with a SimpleController (MultiActionController) as an entry point. The method name resolver for this SimpleController is PropertiesMethodNameResolver. I am using "org.springframework.aop.framework.ProxyFactoryBean" to intercept methods on this controller.

When I run the webapp, the "enhanced" simple controller uses the default InternalPathMethodNameResolver instead of the configured PropertiesMethodNameResolver.

Are there any other known negative consequences to intercepting methods using springframework's ProxyFactoryBean ?

Thanks
Vasanth.

[spring-projects-issues]

Rob Harrop commented

Vasanth,

There are no real drawbacks to intercepting methods at all with Spring AOP, it is just in the case of the CGLIB proxy when proxying a class rather than an interface there is potential for state to be reset.

To avoid this you should use the standard, and recommended, mechanism of using interfaces rather than classes for your proxies. In general, I would also recommend that you use thr JDK Proxy based proxies unless performance is a real issue. The Proxy-based approach is substantially simpler than the CGLIB approach and is therefore easier to maintain and debug.

Regards,

Rob

[spring-projects-issues]

Rob Harrop commented

Fixed for both advised and unadvised methods called inside the constructor. Uses new features in CGLIB 2.1 to skip interception during construction for all methods. Tests to verify in CglibProxyTests are testMethodInvocationDuringConstructor and testUnadvisedProxyCreationWithCallDuringConstructor.