Add support for mixed, fine-grained JDK- and CGLIB-based proxying [SPR-3665]

[spring-projects-issues]

Rick Evans opened SPR-3665 and commented

See #8142 for details.

Aye Juergen, I know you tagged that issue as 'expected behaviour', and it was turned into a documentation issue that I addressed, but I (and others evidently) think that the proxying 'feature' of all JDK-proxies or all CGLIB-proxies is too coarse. It should be more fine grained than that, hence my raising this as an enhancement request. I'll have a dig into the code later on today and see exactly what is going on :)

See also http://forum.springframework.org/showthread.php?t=41025

---

Affects: 2.1 M2

Issue Links:

• Doc: Using <aop:config> namespace with different 'proxy-target-class' settings for two different objects makes usage of CGLIB proxy only [SPR-3459] #8142 Doc: Using aop:config namespace with different 'proxy-target-class' settings for two different objects makes usage of CGLIB proxy only ("depends on")
• Consider target-class proxy mode by default [SPR-14515] #19084 Consider target-class proxy mode by default
• Bean's type is changed unexpectedly when Spring AOP is used [SPR-12190] #16804 Bean's type is changed unexpectedly when Spring AOP is used
• DefaultAopProxyFactory: Make configurable, which interfaces are not considered user supplied. To better support code instrumentation from tools like Cobertura. [SPR-8877] #13518 DefaultAopProxyFactory: Make configurable, which interfaces are not considered user supplied. To better support code instrumentation from tools like Cobertura.

10 votes, 14 watchers

[spring-projects-issues]

Jürgen Lukasczyk commented

Would it be possible to add some bean definition pre-processor that gets consulted by the proxy factory?

Basically a Strategy pattern, with a method
Boolean preserveTargetClass(BeanDefinition bd)
where a TRUE means use CGLib, FALSE means JDK proxy and null means "abstain, use default you have".

To avoid life cycle issues, perhaps you would only allow inner beans from within aop:auto-proxy element.

[spring-projects-issues]

Taras Tielkes commented

What exactly is the use case for "more fine grained" proxying? The current infrastructure is already confusing and brittle enough, imho.

[spring-projects-issues]

Jürgen Lukasczyk commented

I have the following use case, connected to JAX-WS and the fact it is relying on annotations (I suppose you can have similar UC w/ other Tiger based technologies):

1. I normally like JDK proxy (proxyTarget=false)
2. JAX-WS runtime examines Java POJO implementing WebService for annotations which are not inherited by JDK proxy (since it is interface based) => proxyTarget=true
3. JAX-WS WebService client classes are based on JDK proxies themselves. Since proxies are final classes, applying CGLib here makes app go boom => proxyTarget=false
4. I have nice interfaces for my stuff. Having CGLib on anywhere gives warnings about "unable to proxy final class setDataSource()" for my DAO classes which is at best annoying => proxyTarget=false

Confusing & brittle? Not at all, Spring shields you from the complexity of all the stuff it does. I found it quite easy to get the stuff I needed into Spring infrastructure by just overriding one little method in the AutoProxyCreator.

[spring-projects-issues]

Jun Yamog commented

This would be a good feature. In our case we are using Scala for newer code. This means it defaults to proxy objects as scala classes always implements scala object. If we set proxy target to true to makes the jersey resources register them properly. However old java code that is final classes will not work. Would be good if we can set only cglib for a particular config only.

This is kinda related to #13000 a controller or jersey resource that implements a single interface becomes a proxy object. So ClassUtils.getUserClass is unable to get the true object behind as it can only deal with cglib subclasses.

[spring-projects-issues]

Mukarram Baig commented

We ran into the same scenarios as Jurgen mentioned and wanted to know if there are any workarounds for it?

[spring-projects-issues]

Dave Syer commented

Spring Cloud and Spring Boot increasingly rub up against this because we provide aspects that are autoconfigured, and their behaviour alters the way user code works in unexpected and unintended ways, depending on whether proxy-target-class=true or false. E.g. with Spring Cloud Sleuth we intercept RestTemplate with an aspect, but we don't want to prevent users from declaring a bean of that type (which is what would happen if they didn't set proxy-target-class=true, but they might not want to do that if they have final classes anywhere, e.g. from legacy or third party libraries).

[spring-projects-issues]

Oliver Drotbohm commented

Just recently I ran into this when Boot 1.4 milestones activated proxyTargetClass true and all of a sudden @Transactional annotations applied on an interface stopped working.