spring.datasource is ambiguous #2183
Comments
|
The conclusion of our discussions is to go the break route (that is option 1). Please let me know asap if I got this wrong. |
|
@cemo that's not the place to ask. We already discussed that (I just can't find the issue right now). |
Previously, all datasource-related settings were bound to `spring.datasource`, including datasource-specific settings. Update `DataSourceBuilder` to bind to an arbitrary namespace and provide a default one for known types (i.e. the tomcat implementation now binds to `spring.datasource.tomcat`). Since `spring.datasource` is used for common settings, it is still bound by default as well which makes this change backward compatible. Users were redirected to the use of `ConfigurationProperties` to configure extra datasource instances. This is still valid but they now can also use `DataSourceBuilder` directly to achieve the same effect and still retain common settings if need to be. Closes spring-projectsgh-2183
|
Okay so we had a lengthy discussion with @dsyer on the proposal (snicoll@e71504b) and it's definitely more complicated than I thought. Spring cloud uses |
|
I think we should push this back to 1.4 for now and just live with things in 1.3. |
Previously, all datasource-related settings were bound to `spring.datasource`, including datasource-specific settings. Update `DataSourceBuilder` to bind to an arbitrary namespace and provide a default one for known types (i.e. the tomcat implementation now binds to `spring.datasource.tomcat`). Since `spring.datasource` is used for common settings, it is still bound by default as well which makes this change backward compatible. Users were redirected to the use of `ConfigurationProperties` to configure extra datasource instances. This is still valid but they now can also use `DataSourceBuilder` directly to achieve the same effect and still retain common settings if need to be. Closes spring-projectsgh-2183
Previously, Spring Boot mapped both `DataSourceProperties` and the actual `DataSource` implementation to the same prefix. This results in a huge amount of keys in the `spring.datasource` namespace with no way to identify those that are valid for the pooled data source in use. This commit maps the four pooled data sources we support in four isolated namespace, keeping `spring.datasource` only for the common settings. These are `spring.datasource.tomcat`, `spring.datasource.hikari`, `spring.datasource.dbcp` and `spring.datasource.dbcp2` for the Tomcat, Hikari, Commons DBCP and Commons DBCP2 implementations respectively. Closes spring-projectsgh-2183
philwebb
changed the title
|
Updated the release notes as well. |
|
Is this working for properties that cannot be changed at runtime (eg . Hikari's connectionTestQuery) ? |
|
That commit does not change anything related to binding. If it's working now, it will work as well and I can't see anything that would prevent proper binding. |
|
I had missed the binding part. Thanks to have pointed that. |
|
For some reason |
spring.datasourceis used to configure Boot's own configuration support (seeDataSourceProperties) but it's also used to configure the connection pool specific implementation when it's auto-configured.Depending on the environment,
spring-datasourcecan react to Tomcat, Hikari or Commons DBCP. These pools have commonalities but they do have conflicts too (urlvs.jdbcUrl). It would probably be better if those boundaries where clearly identified. This has several advantages:spring.datasource.tomcatfor TomcatThe clear downside is that you have to configure the same settings twice if you happen to use 2 different connection pools and they share the same property.
We can approach this issue in two ways:
spring.datasourcefor implementation specific settings.A good approach would be to support the existing namespace and the implementation specific namespace ASAP and ask user to move to that model. Update meta-data harvesting so that only the specific namespaces are discovered (easy).
On a final note: we should think carefully about choosing the right namespace. If we go for
spring.datasource.tomcatthen it's clear that it becomes 'reserved' for the tomcat specific implementation (same for hikari, dbcp and dbcp2). Hopefully product names are specific enough.The text was updated successfully, but these errors were encountered: