Regarding disabling AopAutoConfiguration when using @EnableAspectJAutoProxy

[hongji3354]

While testing Spring proxy, an incomprehensible problem appeared.

To test JDK Dynamic proxy, we used @EnableAspectJAutoProxy's proxyTargetClass as false, but we still used CGLIB.

When I looked up the data, I found out that the following properties should be added to the application.yml for normal operation.

spring:
  aop:
    auto: false
    proxy-target-class: false

I used @EnableAspectJAutoProxy, but I think it should be disabled when using @EnableAspectJAutoProxy because it can be confusing to manually turn off auto settings.

[bigdata-page]

I think if you want to use AOP, you just need to import spring-boot-starter-aop dependency。If you want to used JDK Dynamic proxy，add the properties spring.aop.proxy-target-class: true and not need to use @EnableAspectJAutoProxy。

The following reasons: if you not add the properties spring.aop.auto: false，the annotation EnableAspectJAutoProxy of AopAutoConfiguration#CglibAutoProxyConfiguration class will cover the annotations(EnableAspectJAutoProxy) you define。

[wilkinsona]

There are lots of different way that proxying is enabled, some of which are more of an implementation detail than something that the user is really aware of. @EnableGlobalMethodSecurity is an example of this. Unfortunately, this means that it isn't possible for us to back off when @EnableAspectJAutoProxy is used in application code as we can't tell if the configuration that it puts in place is a side-effect of something else or a specific intent being declared by the user.

The fact that the auto-configuration can't easily back off is why we have the spring.aop.auto property. Setting it to false should be sufficient to allow you to take complete control over proxy configuration.

[kriegaex]

The fact that the auto-configuration can't easily back off is why we have the spring.aop.auto property. Setting it to false should be sufficient to allow you to take complete control over proxy configuration.

FWIW, using spring.aop.auto=false did in fact disable AOP proxy auto-creation. But when enabling it by @EnableAspectJAutoProxy(proxyTargetClass = false), the proxy target class mode was still active despite setting it to false (which should not even be necessary, because false is the default), so this is not really helping. @liulianjun explained, why: My own definition of the property is somehow shadowed by another one, possibly the one by AopAutoConfiguration.CglibAutoProxyConfiguration, like he said.

The only thing in Spring Boot which really helped me to activate JDK proxy mode, was

spring.aop.proxy-target-class=false

There are lots of different way that proxying is enabled, (...) Unfortunately, this means that it isn't possible for us to back off when @EnableAspectJAutoProxy is used in application code (...)

Can you at least log a clear warning that some user configuration is in the process of being ignored?

[wilkinsona]

Unfortunately not. As I said above we can't tell if the configuration is a side-effect of something else or a specific intent being declared by the user. That means that we can’t accurately determine when a warning should be logged just as we can’t determine if the auto-configuration should back off.

[kriegaex]

I dare to disagree, even though I do not know how exactly Spring determines its configuration. But it should be possible to generically determine if the same configuration annotation or equivalent configuration key is used multiple times with conflicting parameter values. In that case, a warning could be logged, exactly naming the keys, values, sources (config file, config class). It could also log the effective configuration in that case, so the user knows which one "won". Logging this information would been be useful even when there is no conflict. Of course, it could be made optional or depend on the log level.

I think this should be done in Spring Core, but Boot could utilise it or indirectly profit from it, being the Spring project with the most behind the scenes config "magic". I am actually surprised that this mechanism does not exist yet, because for a framework that complex it is unnatural not to have it. Complex tools need adequate diagnostics.

[wilkinsona]

As I said before, we have no way of determining if configuration is an intentional override or if there is an accidental conflict.

Let’s take configuration properties as an example. It is quite common to configure a property in one application.properties file and then override it in another profile-specific file. We could push this information out via logging but for many cases it would be irrelevant. For cases where a user feels it is relevant, the information can be pulled from the Actuator’s env endpoint.

Proxy configuration is similar. We cannot infer the user’s intent and logging everything would be irrelevant noise in many cases. As such, I don’t think logging would provide useful diagnostics. Unlike configuration properties, there’s nowhere to pull this information from if a user wishes to do so. If you’d like to see an improvement in this area, please open a Spring Framework issue. It may be possible for them to track all the sources of proxy configuration and make that information available somehow.

[kriegaex]

Like I said:

• I consider this to be a Spring Core issue, not a Boot one.
• The log output can be made on debug level, i.e. not all users need to see it, only ones activating debug in order to figure out why the heck their configuration is not behaving as expected. Having no means of logging is simply unacceptable. Spring Core permits itself to apply whatever internal rules determine the effective configuration (similar to an effective Maven POM, which indeed I can dump on demand), but it simply does not deign to inform users about it in an opt-in way. That is just careless. Again, I am talking about Core, not Boot.
• I am talking about configuration in general, not just proxy config.