The handling of aliases in DataSourceBuilder requires explicit reflection that isn't covered by RuntimeHints. A typical use case is setJbcUrl on Hikari for the url property.
This can be reproduced by creating a DataSource with our builder as follows:
@Bean
@ConfigurationProperties("db")
DataSource dataSource() {
return DataSourceBuilder.create().build();
}
I believe this worked so far as our auto-configuration exposes HikariDataSource and the hints for configuration properties cover the case.
Comment From: snicoll
It turns out I got it wrong looking at a sample I didn't build. The binding was done in application.yaml, so the fact the most precise type isn't returned was the actual problem.
I've built an additional sample to check if DataSourceBuilder itself works and that went fine. It remains our use of reflection for a connection pool that we don't support explicitly though, see ReflectionDataSourceProperties.
Comment From: wilkinsona
It's quite hard for us to generate the necessary metadata as we need to know the type. That's possible when it's declared through spring.datasource.type. If it's done programatically by calling DataSourceBuilder.type(Class<D>) or DataSourceBuilder.derivedFrom(DataSource) we won't be able to detect it. Given this limited benefit and that, as far as I can remember, we haven't seen any users affected by this, I'm going to close this one. We can reconsider in the future if it becomes a common problem, possibly addressing it by broadening the types that we support directly so that reflection isn't required.