DataSourceInitializer accidental override because of bean name clash

[wtatum]

Beginning in 1.1.3, the autoconfig report always includes the positive match:

DataSourceAutoConfiguration.DataSourceInitializerConfiguration
      - @ConditionalOnMissingBean (types: org.springframework.boot.autoconfigure.jdbc.DataSourceInitializer; SearchStrategy: all) found no beans (OnBeanCondition)

Since this match is conditional on the spring boot DataSourceInitializer, it will still be created even if the non-boot type org.springframework.jdbc.datasource.init.DataSourceInitializer is present. This wouldn't appear to be a big deal. The DataSourceInitializer won't do anything unless the schema.sql or data.sql are present (if I understand correctly), but since the "natural" name for both beans is dataSourceInitializer and the autoconfig one is created early (possibly related to #1115?) my bean was not created.

Changing the name of my bean to any other name resolves the issue, but perhaps the @ConditionalOnMissingBean should refer to the spring-jdbc type and not the boot specific type?

[wtatum]

Also, it's probably not related, but beginning with boot 1.1.3 the DataSourceInitializer began trying to resolve Resources without a qualifier relative to the web app context instead of the classpath. Adding a 'classpath:' prefix fixed the issue, but it seemed odd for it to change.

[dsyer]

Definitely the @ConditionalOnMissingBean should not refer to the JDBC type (or at least that was never the intention). I can see this is a bit frustrating and hard to debug when it goes wrong for you, but I estimate very few users will have a @Bean of either type, never mind one with the same name. Maybe just adding another @Conditional that skips this one if a bean of the same name is already present would be worthwhile (but then this argument applies to all autoconfigured beans and we can't treat them all as special). So my inclination is to do nothing. Note there is a log record when the override is detected.

The other problem is a different issue (but I'm also tempted to mark as "won't fix" since the workaround is best practice anyway).

[wtatum]

Sorry it took me a while to get back on this. You're right that the issue is essentially just the naming conflict, and that this could happen with any autoconfigured bean. I think the issue was just a little harder to debug since the two classes have the same unqualified name, which tends to be treated as the "default" name. It would probably be excessive to make any autoconfig bean conditional on name.

Maybe boot (or spring context?) shouldn't silently allow one bean configuration to mask another. I take it this was the go to mechanism to "override" a bean definition under XML config, so maybe the assumption in the application context is that any bean definitions that clash on name is intentional? It would be nice to see a warning when this is happening, rather than having to dig into the autoconfig report or bean graph.

I'm closing, but I do think it might be worth while to look the above mentioned warning as a feature.

[dsyer]

For sure there is a warning in the logs when this happens, so it's not completely silent. It's a Spring feature (not Spring Boot).