Auto-configure a bootstrapExecutor bean to be used by Framework's background bean initialization

[wilkinsona]

See spring-projects/spring-framework#13410 (comment)

[ballista01]

Hi @wilkinsona I'd like to contribute to the issue. However, I'm facing some issues.
Right now, the spring-boot master branch has a dependency springFrameworkVersion=6.1.5

spring-boot/gradle.properties

Line 17 in af0353d

springFrameworkVersion=6.1.5

, according to the comment you referred to, the @Bean(bootstrap=BACKGROUND) feature is introduced in spring framework 6.2.0. I tried to change the springboot's dependency to the spring framework to springFrameworkVersion=6.2.0-SNAPSHOT but got the following errors:

(base) wiz@wiz-ubuntu:~/Projects/uni/hands_on_refactor/spring-boot$ ./gradlew build -x test --refresh-dependencies

> Task :spring-boot-project:spring-boot-test:compileJava FAILED
/home/wiz/Projects/uni/hands_on_refactor/spring-boot/spring-boot-project/spring-boot-test/src/main/java/org/springframework/boot/test/web/htmlunit/webdriver/LocalHostWebConnectionHtmlUnitDriver.java:43: error: cannot access BrowserVersion
                super(enableJavascript);
                     ^
  class file for org.htmlunit.BrowserVersion not found
/home/wiz/Projects/uni/hands_on_refactor/spring-boot/spring-boot-project/spring-boot-test/src/main/java/org/springframework/boot/test/web/htmlunit/webdriver/LocalHostWebConnectionHtmlUnitDriver.java:49: error: no suitable constructor found for WebConnectionHtmlUnitDriver(com.gargoylesoftware.htmlunit.BrowserVersion)
                super(browserVersion);
                ^
    constructor WebConnectionHtmlUnitDriver.WebConnectionHtmlUnitDriver(org.htmlunit.BrowserVersion) is not applicable
      (argument mismatch; com.gargoylesoftware.htmlunit.BrowserVersion cannot be converted to org.htmlunit.BrowserVersion)
    constructor WebConnectionHtmlUnitDriver.WebConnectionHtmlUnitDriver(boolean) is not applicable
      (argument mismatch; com.gargoylesoftware.htmlunit.BrowserVersion cannot be converted to boolean)
    constructor WebConnectionHtmlUnitDriver.WebConnectionHtmlUnitDriver(Capabilities) is not applicable
      (argument mismatch; com.gargoylesoftware.htmlunit.BrowserVersion cannot be converted to Capabilities)
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
2 errors

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':spring-boot-project:spring-boot-test:compileJava'.
> Compilation failed; see the compiler error output for details.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.6.4/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 13s
1225 actionable tasks: 154 executed, 1071 up-to-date

Is the current springboot version not ready for spring framework 6.2.0 yet? If so, should I develop this enhancement in spring framework?

[wilkinsona]

Thanks for taking a look, @ballista01. We won't be able to work on this issue until we've started developing Spring Boot 3.4 and have upgraded to a Spring Framework 6.2 milestone or snapshot. This won't happen until some time after Spring Boot 3.3's release in May.

[YongGoose]

@wilkinsona

I’m interested in this issue. May I ask if I can contribute to it?

[wilkinsona]

Thanks for the offer, @YongGoose, but I'm not sure we know exactly how to implement this yet. Reading spring-projects/spring-framework#13410 (comment) again, there's the possibility of aliasing the application task executor to bootstrapExecutor but also perhaps a need to allow a boostrap-specific executor to be configured. We'll have to sync up with the Framework team to see if both of these options still make sense and then figure out how we might implement them in Boot.

[YongGoose]

@wilkinsona

I understand.
I would be grateful if you could let me know once the implementation direction is determined after discussing with the Spring team. 😁

---

ps. Additionally, there is another issue I am interested in. Would it be possible for me to contribute to this issue?

• Configurable Health Indicator to observe HTTP Endpoints #36953

[wilkinsona]

I think that one probably needs some design work too, unfortunately. Reading through the comments there still seems to be quite a bit that's undecided.

[mhalbritter]

To tackle this, we could add a BeanFactoryPostProcessor to register an alias:

@Configuration(proxyBeanMethods = false)
static class BootstrapExecutorConfiguration {

	private static final String BOOTSTRAP_EXECUTOR_NAME = "bootstrapExecutor";

	@Bean
	static BeanFactoryPostProcessor bootstrapExecutorAliasPostProcessor() {
		return (beanFactory) -> {
			boolean hasBootstrapExecutor = beanFactory.containsBeanDefinition(BOOTSTRAP_EXECUTOR_NAME);
			boolean hasApplicationTaskExecutor = beanFactory.containsBeanDefinition(TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME);
			if (!hasBootstrapExecutor && hasApplicationTaskExecutor) {
				beanFactory.registerAlias(TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME, BOOTSTRAP_EXECUTOR_NAME);
			}
		};
	}
}

this would alias applicationTaskExecutor to bootstrapExecutor, but only if there is an applicationTaskExecutor and the user hasn't defined their own bootstrapExecutor.

WDYT?

[mhalbritter]

Or, without an alias but better for our configuration report:

@Configuration(proxyBeanMethods = false)
@ConditionalOnMissingBean(name = "bootstrapExecutor")
@ConditionalOnBean(name = TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME)
static class BootstrapExecutorConfiguration {

	@Bean("bootstrapExecutor")
	Executor bootstrapExecutor(@Qualifier(TaskExecutionAutoConfiguration.APPLICATION_TASK_EXECUTOR_BEAN_NAME) Executor applicationTaskExecutor) {
		return applicationTaskExecutor;
	}

}

[YongGoose]

@wilkinsona @mhalbritter
I think the second approach is better.

Defining it as a Bean seems more flexible, especially if we need to modify the behavior of bootstrapExecutor or apply additional configurations later on.

If there are no strong objections, I’d like to go ahead and try implementing it. What do you think?