Update proxyTargetClass-related Javadoc; add tests
There was some question about whether enabling subclass proxies via proxyTargetClass / proxy-target-class settings would break annotation- based demarcation of joinpoints due to inability to discover those annotations in various scenarios. The provided tests prove that in any conceivable case, these annotations (@Transactional, at least) are discovered in a consistent fashion, meaning that switching proxy strategies should be transparent to the application and honor intended annotation semantics.
This commit is contained in:
@@ -125,9 +125,12 @@ public @interface EnableAsync {
|
||||
* to standard Java interface-based proxies. The default is {@code false}. <strong>
|
||||
* Applicable only if {@link #mode()} is set to {@link AdviceMode#PROXY}</strong>.
|
||||
*
|
||||
* <p>Note that subclass-based proxies require the async {@link #annotation()}
|
||||
* to be defined on the concrete class. Annotations in interfaces will
|
||||
* not work in that case (they will rather only work with interface-based proxies)!
|
||||
* <p>Note that setting this attribute to {@code true} will affect <em>all</em>
|
||||
* Spring-managed beans requiring proxying, not just those marked with {@code @Async}.
|
||||
* For example, other beans marked with Spring's {@code @Transactional} annotation
|
||||
* will be upgraded to subclass proxying at the same time. This approach has no
|
||||
* negative impact in practice unless one is explicitly expecting one type of proxy
|
||||
* vs another, e.g. in tests.
|
||||
*/
|
||||
boolean proxyTargetClass() default false;
|
||||
|
||||
|
||||
Reference in New Issue
Block a user