Description
There is the following warning on the page Spring Cloud Context: Application Context Services:
If you have a DataSource bean that is a HikariDataSource, it can not be refreshed. It is the default value for spring.cloud.refresh.never-refreshable. Choose a different DataSource implementation if you need it to be refreshed.
This statement may be misleading because it appears in the section describing @RefreshScope. As far as I understand, there is nothing that prevents users from annotating a HikariDataSource bean with @RefreshScope, since the underlying target bean is recreated when the refresh scope is refreshed.
It is probably true that relying on @ConfigurationProperties rebinding for a HikariDataSource is not a good idea. That behavior is explicitly disabled through the spring.cloud.refresh.never-refreshable property, which includes HikariDataSource by default. However, looking at the implementation of ConfigurationPropertiesRebinder#getNeverRefreshable, this property only affects configuration property rebinding and is unrelated to beans managed by @RefreshScope.
I also don't understand why HikariDataSource is singled out here. Pooled DataSource implementations are generally fairly complex objects, and relying on configuration property rebinding alone is probably too simplistic. If that's the concern, it would seem to apply equally to other pooled DataSource implementations (for example, Tomcat JDBC Pool), not just HikariDataSource.
Suggestion
Update the documentation as follows:
- Move the note about
HikariDataSource from the Refresh Scope section to the Environment Changes section.
- Generalize the note to explain that relying on configuration property rebinding for pooled
DataSource implementations may not be appropriate in general, rather than singling out HikariDataSource.
Description
There is the following warning on the page Spring Cloud Context: Application Context Services:
This statement may be misleading because it appears in the section describing
@RefreshScope. As far as I understand, there is nothing that prevents users from annotating aHikariDataSourcebean with@RefreshScope, since the underlying target bean is recreated when the refresh scope is refreshed.It is probably true that relying on
@ConfigurationPropertiesrebinding for aHikariDataSourceis not a good idea. That behavior is explicitly disabled through thespring.cloud.refresh.never-refreshableproperty, which includesHikariDataSourceby default. However, looking at the implementation ofConfigurationPropertiesRebinder#getNeverRefreshable, this property only affects configuration property rebinding and is unrelated to beans managed by@RefreshScope.I also don't understand why
HikariDataSourceis singled out here. PooledDataSourceimplementations are generally fairly complex objects, and relying on configuration property rebinding alone is probably too simplistic. If that's the concern, it would seem to apply equally to other pooledDataSourceimplementations (for example, Tomcat JDBC Pool), not justHikariDataSource.Suggestion
Update the documentation as follows:
HikariDataSourcefrom the Refresh Scope section to the Environment Changes section.DataSourceimplementations may not be appropriate in general, rather than singling outHikariDataSource.