@EnableTransactionManagement proxyTargetClass not control by spring.aop.proxyTargetClass

[Dreampie]

if use @Transactional,and set spring.aop.proxyTargetClass=false, this class also create by cglib not jdk proxy,you must config @EnableTransactionManagement(proxyTargetClass=false) to use jdk proxy with @Transactional

@Service
public class DemoServiceImpl implements DemoService {

    @Transactional
    public void test() {
        System.out.println("Test");
    }
}

And @EnableTransactionManagement proxyTargetClass default value is false, why spring boot change to true?

[philwebb]

This was changed in 1.4 (see #5423). We've generally found cglib proxies less likely to cause unexpected cast exceptions.

[philwebb]

Sorry, I misunderstood your initial comment. You're saying you add spring.aop.proxyTargetClass=false to application.properties but we ignore that and use cglib regardless?

[Dreampie]

yes，@snicoll know this question，https://github.com/Dreampie/spring-boot-demo

[mdeinum]

the spring.aop.proxy-target-class is only used to toggle the configuration in AopAutoConfiguration for other proxy creation it is being ignored, like for @EnableTransactionManagement and the configuration of the PersistenceExceptionTranslationPostProcessor.

I noticed this during introducing Spring Boot into a project which used quite a lot of final classes (or classes with final methods). I ran into it in those areas but maybe there are a few more (like JMX for instance).

[snicoll]

While we're working on it, we may want to share that thing in its own auto-configuration and order that in a sensible manner, see #8587

[snicoll]

@philwebb I've worked on a solution in b20dff1 that is a bit larger than what is foreseen here. I am not sure if that belongs to 1.4 but a couple of thoughts:

1. Our default for this is CGLIB which basically upgrade the whole context to go CGLIB. IMO we should change the default of spring.aop.proxy-target-class to true
2. So far we only enabled transaction management when a DataSource is present. That led to the Neo4j problem (Auto-configure @EnableTransactionManagement with Neo4J #8587) but any data tech that supports PlatformTransactionManager is also affected. IMO it makes more sense to enable it once such a bean is found in the context

I think that 1. is pretty bad because we won't be able to change it in 1.4 or 1.5 and currently we're doing that effectively as soon as you use @Transactional in your app.