Regression: Early instantiation of a bean prevents proxying for @Async in 4.2.x but works in 4.1.x [SPR-14030]

[spring-projects-issues]

Andy Wilkinson opened SPR-14030 and commented

There's a behaviour difference between 4.2.x and 4.1.x around proxy creation for beans with @Async methods. When using 4.2.x, early instantiation of the bean makes it ineligible for proxying. It works fine with 4.1.x.

I'll submit a spring-framework-issues PR with a test that illustrates the problem once I've got the issue number.

---

Affects: 4.2.5

Reference URL: spring-projects/spring-boot#5366

Issue Links:

• Regression: AsyncAnnotationBeanPostProcessor fails on startup when encountering ambiguous TaskExecutor beans [SPR-13720] #18293 Regression: AsyncAnnotationBeanPostProcessor fails on startup when encountering ambiguous TaskExecutor beans
• AsyncAnnotationBeanPostProcessor could find TaskExecutor by type/name [SPR-13248] #17839 AsyncAnnotationBeanPostProcessor could find TaskExecutor by type/name
• Nested @Async annotations can block indefinitely [SPR-14490] #19059 Nested @Async annotations can block indefinitely
• Consistently accept "taskExecutor" bean of type Executor (as stated in @EnableAsync's javadoc) [SPR-15566] #20125 Consistently accept "taskExecutor" bean of type Executor (as stated in @EnableAsync's javadoc)

[spring-projects-issues]

Andy Wilkinson commented

Reproduction: spring-attic/spring-framework-issues#121

[spring-projects-issues]

Stéphane Nicoll commented

That is a side effect of the change in #17839

[spring-projects-issues]

Juergen Hoeller commented

I've addressed this through moving that lookup logic into AsyncExecutionAspectSupport, performed on demand when we actually execute a given @Async method. We already had resolution logic for qualifier-based executors there, so now we simply have our resolution logic for the default executor there as well.

As a consequence, the intermediate AsyncAnnotationAdvisor class doesn't initialize a local default SimpleAsyncTaskExecutor anymore. This is now also left to AsyncExecutionAspectSupport since it would otherwise prevent the logic there from kicking in.

As a side effect of the above, our AspectJ async aspect will receive a default executor now if it has been configured with a BeanFactory. Previously, it skipped execution completely if no explicit executor was given - even if it had a BeanFactory. However, the mismatch with its own qualifier-based resolution and with proxy-based setup was questionable before, so we consistently apply default resolution in case of a given BeanFactory in any scenario now. The only way to make the AspectJ async aspect skip async execution completely is to not populate the aspect at all, in particular neither with an Executor nor with a BeanFactory.

Juergen

[spring-projects-issues]

Sam Brannen commented

Reopening this issue since it has caused tests in EnableSchedulingTests to fail.

See failing performance builds starting with https://build.spring.io/browse/SPR-PERF-724.

Note that the following tests have been temporarily disabled via @Ignore until this is resolved.

• withExplicitSchedulerAmbiguity_andSchedulingEnabled()
• withAmbiguousTaskSchedulers_andSingleTask()

[spring-projects-issues]

Juergen Hoeller commented

Andy Wilkinson, this is also available in 4.2.6.BUILD-SNAPSHOT as of last night... Let me know whether it restores lazy initialization behavior along the lines of 4.1.x for you.

[spring-projects-issues]

Andy Wilkinson commented

Looks good – the project supplied with the original Boot issue is proxied correctly with the latest 4.2.6 snapshot and the async method runs on a separate thread.