Improve behavior in accidental error cases for AOP, JavaConfig and too broad pointcuts [SPR-10561]

[spring-projects-issues]

Oliver Drotbohm opened SPR-10561 and commented

JavaConfig configuration classes are treated just like every other Spring bean to support autowiring etc. This results in them being candidates to be advised by AOP aspects. Assume some user (accidentally) defined a pointcut that the configuration class' methods match. When looing up bean configured in that configuration class, an instance of the configuration class is created.

The AOP infrastructure now detects the config instance being target for advices and creates a JDK proxy for it. It will be a JDK proxy by default as the CGlib generated subclass exposes interfaces. As a consequence, that proxy won't expose the original @Bean methods anymore which leads to weird exceptions saying something like: "Factory method myBeanMethod() not found on ConfigurationClass" although the method is in fact declared. This effect can be worked around by activating proxyTargetClass for the AOP subsystem - but this requires deep knowledge of how the container works in the first place.

Even if you took that hurdle, you'll still run into a cyclic dependency as the configuration class instance would then be attempted to be advised by an aspect that is most likely to be produced by that configuration. Again you can solve this by explicitly excluding the configuration classes from the pointcuts but it's probably not really obvious why you have to do this in the first place.

1. Would it make sense to exclude configuration classes from being advised at all? There's hardly a scenario I can think of this is really usefull in, especially as you're close to guaranteed to run into the cyclic dependency issue.
2. Can we at least trigger an INFO log in case a configuration class get's adviced? This would at least make the user aware of the very edge case she ran into.
3. If 1. is out of scope for backwards comptibility (although I doubt anyone is deliberately using this effect) the DI container should inspect the proxy target for the factory methods if it sees and instance of Advised.

---

Affects: 3.2.2

1 votes, 3 watchers

[spring-projects-issues]

Juergen Hoeller commented

I tend to agree that there are hardly good reasons to advise a configuration class... However, it turns out to be way simpler to go with your option 3 and simply always preserve the target class in case of auto-proxying: This is an existing BeanDefinition attribute that we simply need to set in our ConfigurationClassPostProcessor.

Juergen

[spring-projects-issues]

Oliver Drotbohm commented

While this might be easier to implement, doesn't this mean you'd run into a cyclic dependency by accident? Excluding configuration classes from being advised would prevent that, wouldn't it?

[spring-projects-issues]

Juergen Hoeller commented

Well, I should have said that it is easier to implement and preserves the ability for people to do anything they did before. I don't see particularly good reasons to advise @Bean methods, but well, for auditing or instance tracking or whatever, people might be doing it. I'd prefer not to make strong assumptions there.

Juergen