jdbcUrl is preferred over user-provided dataSource in HikariConfig

[Laurent Chiarello]

When setting both a jdbcUrl and a dataSource in HikariConfig, instantiating a new HikariDataSource from this config object will result in the pool creating a DriverDataSource from the jdbcUrl, while completely ignoring the provided and already instantiated DataSource.

This is due to the logic in PoolUtilities#initializeDataSource:

    try {
        if (dataSource == null && dsClassName != null) {
           dataSource = createInstance(dsClassName, DataSource.class);
           PropertyBeanSetter.setTargetFromProperties(dataSource, dataSourceProperties);
           return dataSource;
        }
        else if (jdbcUrl != null) {
           return new DriverDataSource(jdbcUrl, driverClassName, dataSourceProperties, username, password);
        }
   
        return dataSource;
    }

If dataSource is not null, why not simply return it before checking anything else ?

In my use case, I have a HikariConfig object configured through Spring @ConfigurationProperties, and I wanted to provide a custom DataSource (manually constructed using the jdbcUrl and other config properties). In order to make it work, I have to clear the jdbcUrl (config.setJdbcUrl(null)) if I want my DataSource to be picked up !

This is a little bit unfortunate (it was nice to have it logged in DEBUG output :) ), and also completely prevents the usage of the `driverClassName` property, since the later cannot be reset to null (throws an IllegalArgumentException in config.setDriverClassName(null)). And having a non-null driverClassName with a null jdbcUrl throws an IllegalStateException when validating the configuration, so I'm completely stuck.

It would be nice if I could keep the HikariConfig object initialized by Spring (including jdbcUrl and driverClassName), while still being able to provide a custom DataSource implementation to the pool !

[Brett Wooldridge]

What am I missing? If your are eventually specifying the DataSource instance programmatically, what is the purpose of setting jdbcUrl and driverClassName in the Spring HikariConfig in the first place?

-Brett

[Laurent Chiarello]

Originally, the setup was simply:

1. Have HikariConfig configured in a properties files thanks to Spring @ConfigurationProperties (with a provided jdbcUrl)
2. Create a HikariDataSource from this config, thus using the jdbcUrl

Now I need to wrap the DataSource that will be used by HikariCP, but I would prefer not to have to make any changes to the properties file format (which I don't configure in production). Thus, the idea was:

1. Have HikariConfig configured in a properties files thanks to Spring @ConfigurationProperties, exactly as before
2. Create a DataSource instance based on the jdbcUrl from that HikariConfig instance
3. Have HikariDataSource use that DataSource instance, keeping all the other HikariConfig properties equal

It would have been super easy to do if I only had to set the DataSource on the HikariConfig instance before calling new HikariDataSource(config), unfortunately, this does not work (as explained in the first post) :(

Hope I made my point clear ^^

[Brett Wooldridge]

Laurent,

A fix for this has been committed, and will appear in the next release.

-Brett

[Laurent Chiarello]

Thanks for the quick release, really appreciate it !

-Laurent