See #17963 for background. As well as fixing the name generation we should add a setAllowBeanDefinitionOverriding method and align with SpringApplication.
Comment From: snicoll
I've given this one a try and a few tests in spring-boot-autoconfigure started failing. They all involve @ComponentScan one way or the other and it looks like the component scan directive is processed twice. I haven't investigated more than that but it can be reproduced using https://github.com/snicoll/spring-boot/tree/gh-18019
Comment From: snicoll
I've fixed a few tests that were a little bit brittle but I can't seem to grasp what CassandraReactiveDataAutoConfigurationTests is doing. Flagging for team attention to see if someone on the team can put me out of my misery.
Comment From: wilkinsona
What was the problem with CassandraReactiveDataAutoConfigurationTests? It doesn't seem to be using the application context runner at the moment.
Comment From: snicoll
Sorry I meant CassandraReactiveRepositoriesAutoConfigurationTests
Comment From: wilkinsona
It looks a bit broken to me. The excludeFilter doesn't appear to do anything. Component scanning itself seems to allow the test to pass when a local Cassandra instance isn't available. It does that by picking up the mocked Session from the TestConfiguration inner-class. That's quite a nasty side-effect. It must be picking up plenty of other stuff too that's unintentional and makes the tests rather confusing.
There's a similar pattern across a number of test classes related to Cassandra. I suspect it may have been written once and then copied to other classes as they were added. It looks to me as if we should rework all of the affected classes to remove the use of @ComponentScan entirely.
Comment From: snicoll
Thanks Andy, I've polished things up in bc066d2