Change in bean lifecycle due to DefaultBinderFactory causes unexpected startup of LifeCycle beans

[francisco-bru]

After the change introduced in f259c55, we have detected a change in behavior during the startup of Spring Boot applications.

Prior to this change, when refreshContext was executed in SpringApplication, it eventually called the onRefresh method in DefaultLifecycleProcessor. This method only forces the startup of SmartLifeCycle beans where isAutoStartup() returns true, ignoring the rest.
LifeCycle beans that are not SmartLifeCycle were not started at this point.

As of the mentioned commit, DefaultBinderFactory becomes a SmartLifeCycle bean, triggering the startup of other ConfigurationApplicationContext instances, and in this second call, the start() method is invoked instead of onRefresh(). This results in startBeans(false) being called in DefaultLifecycleProcessor, which also forces the startup of LifeCycle beans that are not SmartLifeCycle.

A concrete example: the integrationHeaderChannelRegistry bean (spring-integration-core), which previously was instantiated but never started and did not schedule its 'reaper' task. Now it does start, launches its 'reaper' task, and causes issues such as the one reported in spring-projects/spring-integration#10547.

Describe the problem
This change in behavior may cause unexpected side effects in LifeCycle beans that are not SmartLifeCycle, such as undesired scheduled tasks.

References

• Commit with the change: f259c55
• Related implementations:
  • refreshContext in SpringApplication (https://github.com/spring-projects/spring-boot/blob/ff4889217c7f1229564a6e94560c05f43ab10b13/core/spring-boot/src/main/java/org/springframework/boot/SpringApplication.java#L321)
  • onRefresh and start in DefaultLifecycleProcessor (https://github.com/spring-projects/spring-framework/blob/9a54fac9982c427746f150d5a9cf11b5a6eeff8e/spring-context/src/main/java/org/springframework/context/support/DefaultLifecycleProcessor.java#L295)
  • integrationHeaderChannelRegistry in spring-integration-core
• Related issue: Race condition in DefaultHeaderChannelRegistry during application shutdown causes error log spring-projects/spring-integration#10547

Steps to reproduce

1. Start a Spring Boot application with spring-cloud-stream version (4.3.X).
2. Verify that integrationHeaderChannelRegistry starts and launches its "reaper" task.
   • This can be verified by enabling TRACE log for org.springframework.integration.channel.DefaultHeaderChannelRegistry.
3. Start the same Spring Boot application with spring-cloud-stream version (4.2.X).
4. Verify that integrationHeaderChannelRegistry does not start and does not launch its "reaper" task.
   • No traces will be shown for the log org.springframework.integration.channel.DefaultHeaderChannelRegistry: TRACE

[artembilan]

Correct me if I'm wrong or just confirm that we are on the same page.

Your concern that DefaultBinderFactory starts all the beans even if they are not SmartLifecycle implementations.
And this concerns has nothing to do what we did recently with you in the DefaultHeaderChannelRegistry.
You just got that error about TaskScheduler on the shutdown as an evidence of this undesired all Lifecycle beans start.

[francisco-bru]

Yes, that is my concern.
The reproduction steps use DefaultHeaderChannelRegistry logs to demonstrate the problem, and the DefaultHeaderChannelRegistry issue is an effect of this cause, but not the reason; the reason is a race condition.

[artembilan]

Thanks for confirmation.
One more minor clarification I'm still seeking.
I guess with a race condition you mean that scheduler problem we have fixed in the DefaultHeaderChannelRegistry.

The problem here we want to fix is to not start those non-SmartLifecycle from the DefaultBinderFactory.
Correct?
We may fully forget about DefaultHeaderChannelRegistry in context of fixing this problem because it is not only one who is just a Lifecycle bean.

[francisco-bru]

I believe this change should be reviewed, analysing the reason why it was made and what side effects it produces (restarting all beans, forcing non-SmartLifeCycle ones).

Regarding the other issue, no, I do not believe the race condition has been resolved, because the condition is between the task scheduler and the DefaultHeaderChannelRegistry scheduled task but I agree that it should be discussed in the other issue, not here