As a suggestion, in case you want to use a connection pool other than Hikari it would be nice to be able to perform the Hikari exclusion with the property "spring.datasource.hikari.enabled = false", without having to do it in the following way :
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jdbc</artifactId>
<exclusions>
<exclusion>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
</exclusion>
</exclusions>
</dependency>
Also, this is a problem if you want to exclude the Hikari dependency from dependencyManagement since the forces hardcode the spring-boot version:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jdbc</artifactId>
<version>2.1.5.RELEASE</version>
<exclusions>
<exclusion>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</dependencyManagement>
With the property spring.datasource.hikari.enabled you can evaluate the load of autoconfigurations that now continue to be loaded only by evaluating the simple presence of the class in the classpath:
DataSourceJmxConfiguration.Hikari matched: - @ConditionalOnClass found required class 'com.zaxxer.hikari.HikariDataSource' (OnClassCondition)
DataSourcePoolMetadataProvidersConfiguration.HikariPoolDataSourceMetadataProviderConfiguration matched: - @ConditionalOnClass found required class 'com.zaxxer.hikari.HikariDataSource' (OnClassCondition)
DataSourceConfiguration.Hikari: Did not match: - @ConditionalOnProperty (spring.datasource.type=com.zaxxer.hikari.HikariDataSource) found different value in property 'spring.datasource.type' (OnPropertyCondition) Matched: - @ConditionalOnClass found required class 'com.zaxxer.hikari.HikariDataSource' (OnClassCondition)
DataSourcePoolMetadataProvidersConfiguration.HikariPoolDataSourceMetadataProviderConfiguration matched: - @ConditionalOnClass found required class 'com.zaxxer.hikari.HikariDataSource' (OnClassCondition)
It's just a suggestion. thank you
Comment From: juliojgd
I think this "enabled" property would be useful because HikariCP is a "special" case as it is included by default as a "compile" dependency in spring-boot-starter-jdbc
.
Other connection pool libraries like tomcat-pool
or dbcp2
are not included so their "enabled" properties are not useful, you can just not include their dependency..
Comment From: snicoll
@juliojgd Spring Boot already offers a spring.datasource.type
property where you can specify the connection pool to use. If you're not happy excluding the dependency then you should give that a try. We don't offer enabled
property for core features.
Comment From: LidoDev
This property is nice to have. I am externalizing the pooling of connection to a third party server [PgBouncer in my architecture]. Why should i override datasource with a hard coded bean to disable and exclude application pooling side? I want to get a dedicated service of pooling connections to databases.
An environment variable to disable hikari is a good feature.
Comment From: snicoll
@LidoDev given you thumbs down my comment, I must assume you've read it.
Why should i override datasource with a hard coded bean to disable and exclude application pooling side?
You don't really have to. You can use spring.datasource.type
as I've explained.
I want to get a dedicated service of pooling connections to databases.
OK. So what does your hard coded bean looks like? If you're using an unsupported DataSource
, then it is normal you have to create your own bean, excluding Hikari won't help you as we need to configure the DataSource
for you.
Comment From: LidoDev
@snicoll spring.datasource.type didn't accept those values :
- none
- SimpleDriverDataSource
I ended by creating a SimpleDriverDataSource Bean and excluding hikari in pom.xml.
import org.springframework.beans.factory.annotation.Value;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.jdbc.datasource.SimpleDriverDataSource;
import javax.sql.DataSource;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Properties;
@Configuration
@ConfigurationProperties("spring.datasource")
public class DataSourceConfiguration {
@Value("${spring.datasource.url}")
private String uri;
@Value("${spring.datasource.username}")
private String username;
@Value("${spring.datasource.password}")
private String password;
@Bean
public DataSource dataSource() throws SQLException {
SimpleDriverDataSource dataSource = new SimpleDriverDataSource();
dataSource.setDriver(DriverManager.getDriver(uri));
dataSource.setUrl(uri);
dataSource.setUsername(username);
dataSource.setPassword(password);
Properties connectionProperties = new Properties();
connectionProperties.setProperty("useUnicode","true");
connectionProperties.setProperty("characterEncoding","UTF-8");
connectionProperties.setProperty("prepareThreshold","0");
dataSource.setConnectionProperties(connectionProperties);
return dataSource;
}
}
<exclusions>
<exclusion>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
</exclusion>
</exclusions>
Comment From: snicoll
SimpleDriverDataSource
is supported since Spring Boot 2.3.x. Please review the description of the property:
Fully qualified name of the connection pool implementation to use.
Therefore, as of Spring Boot 2.3.x
, the following works out of the box with no need to exclude anything:
spring.datasource.type=org.springframework.jdbc.datasource.SimpleDriverDataSource
Even if it wasn't, there is no need to inject those attributes using @Value
. This is also described in the reference guide.