As identified by https://github.com/spring-projects/spring-boot/issues/41231, we should review our auto-configuration in the places where it accepts both a URI and separate properties as there's the potential for some confusion and inconsistency.
Upon initial inspection, it would appear that the Neo4j auto-configuration ignores any user info in its URI and only uses the separate username and password properties for authentication. The Elasticsearch auto-configuration does things differently as it uses any user info in the configured URI(s) with the separate username and password being used as a fallback. Part of this is differences in the underlying services leaking out into Boot's properties but I think a review is still warranted as we should try to make things as consistent as possible and document any remaining inconsistencies.
As identified by https://github.com/spring-projects/spring-boot/issues/41231, we should review our auto-configuration in the places where it accepts both a URI and separate properties as there's the potential for some confusion and inconsistency.
Upon initial inspection, it would appear that the Neo4j auto-configuration ignores any user info in its URI and only uses the separate username and password properties for authentication. The Elasticsearch auto-configuration does things differently as it uses any user info in the configured URI(s) with the separate username and password being used as a fallback. Part of this is differences in the underlying services leaking out into Boot's properties but I think a review is still warranted as we should try to make things as consistent as possible and document any remaining inconsistencies.