jdbc-observations / datasource-micrometer

Micrometer Observation API instrumentation and Spring Boot 3 Auto-Configuration for JDBC APIs
Apache License 2.0
50 stars 8 forks source link

Spring Boot Auto Configuration conflicts with spring-boot-data-source-decorator project #33

Open ZIRAKrezovic opened 6 months ago

ZIRAKrezovic commented 6 months ago

When using JDBC observability linked from official Spring Boot documentation https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html#actuator.observability -> https://jdbc-observations.github.io/datasource-micrometer/docs/current/docs/html/ and including the mentioned spring boot starter

<dependency>
    <groupId>net.ttddyy.observation</groupId>
    <artifactId>datasource-micrometer-spring-boot</artifactId>
    <version>1.0.3</version>
</dependency>

Application startup fails when datasource-proxy-spring-boot-starter project is also present as a dependency

<dependency>
    <groupId>com.github.gavlyukovskiy</groupId>
    <artifactId>datasource-proxy-spring-boot-starter</artifactId>
    <version>1.9.1</version>
    <optional>true</optional>
</dependency>

Error:

***************************
APPLICATION FAILED TO START
***************************

Description:

The bean 'dataSourceNameResolver', defined in class path resource [net/ttddyy/observation/boot/autoconfigure/DataSourceObservationAutoConfiguration.class], could not be registered. A bean with that name has already been defined in class path resource [com/github/gavlyukovskiy/boot/jdbc/decorator/DataSourceDecor
atorAutoConfiguration.class] and overriding is disabled.

Not sure who has to fix their bean naming, but it would be nice if any one of you would fix it :)

ZIRAKrezovic commented 6 months ago

https://github.com/gavlyukovskiy/spring-boot-data-source-decorator/issues/95

ttddyy commented 6 months ago

It looks like both libraries have defined a bean with the same name - dataSourceNameResolver. com.github.gavlyukovskiy.boot.jdbc.decorator.DataSourceNameResolver and net.ttddyy.observation.boot.autoconfigure.DataSourceNameResolver.

Since both bean definitions have @ConditionalOnMissingBean, I think a quick workaround is that if you define either bean with a different name in your application configuration, the one from auto-configuration should back off.

ZIRAKrezovic commented 6 months ago

My workaround is as follows

import io.micrometer.observation.ObservationRegistry;

import net.ttddyy.observation.boot.autoconfigure.DataSourceNameResolver;
import net.ttddyy.observation.boot.autoconfigure.DataSourceObservationAutoConfiguration;
import net.ttddyy.observation.boot.autoconfigure.DefaultDataSourceNameResolver;

import org.springframework.boot.autoconfigure.AutoConfiguration;
import org.springframework.boot.autoconfigure.condition.ConditionalOnClass;
import org.springframework.boot.autoconfigure.condition.ConditionalOnMissingBean;
import org.springframework.context.annotation.Bean;

import javax.sql.DataSource;

@AutoConfiguration(before = DataSourceObservationAutoConfiguration.class)
@ConditionalOnClass({DataSource.class, ObservationRegistry.class})
public class ProjectDataSourceObservationAutoConfiguration {
    @Bean
    @ConditionalOnMissingBean
    public DataSourceNameResolver defaultDataSourceNameResolver() {
        return new DefaultDataSourceNameResolver();
    }
}