Publication of DataSourceSchemaCreatedEvent is more prone to creating a cycle than it was in 2.0

[cppwfs]

Spring Boot 2.1.M3
Issue
We found a BeanCreationException using Spring Boot 2.1 while creating a Spring Cloud Task application that uses JPA. In our example a user has marked a method (which executes a JPARepository.save) with the @BeforeTask annotation that allows Spring Cloud Task to call this method prior to ApplicationRunner. Specifically the BeanCreationException occurs when Spring Cloud Task TaskLifecycleListener (ApplicationLifecycleListener impl) tries to resolve the Component that contains the JPARepository Autowire.

Discussion
Had a discussion with Andy Wilkinson and he validated the case.

To Reproduce

• Pull from my local repo this branch of Spring Cloud Task: https://github.com/cppwfs/spring-cloud-task/tree/TASK-439A
• Build mvn clean install. The JPA sample test will fail. <Build time about 2 min 10 sec>

[wilkinsona]

There's a cycle: entityManagerFactory -> taskLifecycleListener -> taskListenerExecutor -> taskRunComponent ->taskRunRepository -> entityManagerFactory. The link from entityManagerFactory to taskLifecycleListener happens because the latter is an ApplicationListener<ApplicationEvent> and the former, via DataSourceInitializedPublisher.DataSourceSchemaCreatedPublisher (a JpaVendorAdapter), publishes an event which triggers the initialisation of taskLifecycleListener which has a transitive dependency on entityManagerFactory.

Irrespective of what, if anything, we can do about this in Boot, I think a change in Spring Cloud Task so that TaskLifecycleListener doesn't trigger early initialisation of all its dependencies as soon as an ApplicationEvent is published would be a good idea.

[wilkinsona]

There's a broader problem here that affects earlier version of Spring Cloud Task. With Spring Cloud Task 1.2.3, the JPA sample will fail if there's a schema.sql file. Once again the problem is a cycle, although it's slightly different to the one described above. In this case the cycle is dataSource -> dataSourceInitializer -> taskLifecycleListener -> taskExecutionListeners -> taskListenerExecutor -> taskRunComponent -> taskRunRepository -> entityManager -> entityManagerFactory -> dataSource. The cause of the cycle is taskLifecycleListener. This time it's being created because the schema.sql script has been run, the schema created event is being published, and, therefore, application listeners are being initialised. This is a variant of #13042.

[wilkinsona]

The problem can be avoided with a more focussed application listener that also makes that type information available via its bean definition:

private final class ApplicationReadyEventListener
		implements ApplicationListener<ApplicationReadyEvent> {

	@Override
	public void onApplicationEvent(ApplicationReadyEvent event) {

	}

}

@Bean
public ApplicationReadyEventListener jpaUsingApplicationListener(
		EntityManagerFactory emf) {
	return new ApplicationReadyEventListener();
}

In this case the jpaUsingApplicationListener method will only be called when an ApplicationReadyEvent is being published, not when the first ApplicationEvent is published.

[wilkinsona]

Here's a possible change that makes Boot more tolerant of an ApplicationListener that is a potential recipient of DataSourceSchemaCreatedEvent and depends on the EntityManagerFactory. I believe it will fix the first cycle describe above but will not fix the second one or the other broader problems caused by TaskLifecycleListener described in spring-cloud/spring-cloud-task#448.

Given that Spring Cloud Task really needs to be changed in this area anyway, I don't think we have to do something here. We need to decide if we want to do something anyway. If we do, it will make things more robust for other application listeners that can trigger unwanted early initialisation.