Spring boot starter r2dbc - configuration bug

[ndopj]

Current release 2.3.0 contains a bug when using auto-configuration and manual configuration of r2dbc drivers to use reactive repositories, making reactive repositories functionality unusable at all.

Gradle Dependencies:

    dependencyManagement {
        imports {
            mavenBom("org.springframework.boot:spring-boot-dependencies:2.3.0.RELEASE")
        }
    }

    dependencies {
         implementation('org.springframework.boot:spring-boot-starter-data-r2dbc:2.3.0.RELEASE')
         implementation('io.r2dbc:r2dbc-h2')
         implementation('io.r2dbc:r2dbc-pool')
    }

application.properties

spring.r2dbc.url=r2dbc:h2://localhost/test
spring.r2dbc.username=sa
spring.r2dbc.password=password
spring.r2dbc.initialization-mode=always

Spring Boot main application:

@SpringBootApplication
@EnableR2dbcRepositories(basePackages = {"com.**"})
public class ApplicationLauncher {
    public static void main(String[] args) {
        SpringApplication.run(ApplicationLauncher.class, args);
    }
}

Error:

Description:

Field accountRepository in com.**.DatabaseAccountService required a bean named 'r2dbcDatabaseClient' that could not be found.

When trying to do configuration manually different error occures (same dependencies but without application.properties r2dbc properties):

Configuration

@Configuration
@EnableTransactionManagement
@PropertySource(value = "classpath:application.properties")
@EnableR2dbcRepositories(basePackages = {"com.**"})
public class CoreR2dbcConfiguration extends AbstractR2dbcConfiguration {

    @Override
    @Bean
    public ConnectionFactory connectionFactory() {
        H2ConnectionConfiguration configuration = H2ConnectionConfiguration.builder()
                .inMemory("testDB")
                .username("sa")
                .password("password")
                .build();
        return new H2ConnectionFactory(configuration);
    }

    @Bean
    ReactiveTransactionManager transactionManager(ConnectionFactory connectionFactory) {
        return new R2dbcTransactionManager(connectionFactory);
    }
}

Error:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

    org.springframework.data.r2dbc.mapping.R2dbcMappingContext.<init>(R2dbcMappingContext.java:45)

The following method did not exist:

    'void org.springframework.data.r2dbc.mapping.R2dbcMappingContext.setForceQuote(boolean)'

This is probably somehow linked to:
spring-projects/spring-data-r2dbc#296 (comment)
Mentioned conflict reason is usage of wrong dependencies, but since i am only using spring boot starter dependencies this is not my case.

[philwebb]

@ndopj Are you able to share a sample project to save us a bit of time building one from the snippets you provided?

[ndopj]

https://github.com/ndopj/spring-boot-2.3.0-r2dbc-bug/tree/manual-configuration-bug

Master branch contains configuration for the first specified case. The second case is really probably conflict between (as was proposed within issue linked in the description) spring-boot-data-jpa and spring-boot-data-r2dbc dependencies, since i am using both of them in my project. However i am still not able to reproduce second case bug in regular project so i will investigate further on my own.
Edit:
spring-data-relational is used by both spring-data-r2dbc, spring-data-jdbc:
https://mvnrepository.com/artifact/org.springframework.data/spring-data-relational/usages

That means following conflict reason might be causing second case bug (since i am getting exactly same error), if spring-boot-starter-data-jdbc and spring-boot-starter-data-r2dbc are using different version of spring-data-relational:
spring-projects/spring-data-r2dbc#296 (comment)

For the first bug, possible solution might be creation of bean r2dbcDatabaseClient manually, but i would expect spring boot auto-configuration to configure that bean same as EntityManager bean is configured in case of spring-boot-starter-data-jpa, with use of properties inside application.properties file, so one can use "CrudRepositories" without any additional configuration.

Both bugs i mentioned are already mentioned in the link i posted in the description of this issue:
spring-projects/spring-data-r2dbc#296,

[snicoll]

@ndopj thanks for the sample but this project works fine for me (if we ignore the r2dbc url that I've changed to use an in-memory database. Just to confirm, I am using the branch). The error you've described above could happen if you use the experimental r2dbc support that has moved to Spring Boot 2.3 or if your dependency management is broken. None of that is the case in the sample that you've shared and it works properly for me.

To go further with this, we need a sample that reproduces the error above.

[ndopj]

With clearing gradle cache, project cache, gradle dependencies and reevaluating the project i can confirm that auto-configuration in the first case is working properly as expected. I need to investigate second case on my own since as @snicoll proposed, problems might have different origin as i tough and i am not able to reproduce. I am using only spring boot 2.3.0 starter dependencies.

Thank you all for cooperation and sorry for time taken by this issue, since it doesn't seem to be bug at all.

[snicoll]

Thanks for letting us know.

[ndopj]

After hours of debugging dependencies in gradle i've finally found out that second case error might occur when using spring-boot-starter-data-r2dbc together with spring-cloud-sleuth dependency management. I am using latest version of spring-cloud-sleuth (2.2.2.RELEASE: Mar, 2020). Note that gradle automatically downgrades most of spring boot starter dependencies to 2.2.5 versions with this dependency management setup.

    dependencyManagement {
        imports {
            mavenBom("org.springframework.boot:spring-boot-dependencies:2.3.0.RELEASE")
            mavenBom("org.springframework.cloud:spring-cloud-sleuth:2.2.2.RELEASE")
        }
    }

[philwebb]

@ndopj I'm having trouble replicating that behavior, can you please share a sample project that shows the downgrades happening?

[wilkinsona]

This looks like a mistake in the Spring Cloud Sleuth documentation to me. It recommends using spring-cloud-sleuth as a bom but it doesn't look like it should be used that way to me. Via its parent it pulls in spring-boot-dependencies which results in it potentially clobbering your Spring Boot version. At a glance, spring-cloud-sleuth-dependencies or spring-cloud-dependencies (the latter is what start.spring.io recommends) look like better alternatives to me.

[snicoll]

It is indeed and the reference guide actually describes the correct setup. I've created spring-cloud/spring-cloud-sleuth#1658 so that this page refers to the correct bom.

@ndopj you can also create an app on start.spring.io with the dependencies that your project needs if you want an example of a working setup.