OpenTelemetryDataSource error when refresh configuration

[kkz-01]

Describe the bug
When using nacos to refresh the configuration, the OpenTelemetryDataSource reports an error and the configuration refresh does not take effect

Steps to reproduce
Use pom.xml to import opentelemetry-instrumentation-bom(v2.12.0) and opentelemetry-spring-boot-starter then use nacos to modify the configuration

What did you expect to see?
OpenTelemetryDataSource does not report an error and can obtain the correct constructor, Configuration refresh works fine

What did you see instead?
Refresh configuration failed. Through debug, found the error ExistingValue must be an instance of com.zaxxer.hikari.HikariDataSource.

It seems that SpringBoot cannot get the correct constructor of OpenTelemetryDataSource well.

What version and what artifacts are you using?

• opentelemetry-instrumentation-bom(v2.12.0)
• opentelemetry-spring-boot-starter
• nacos-client(v2.3.2)
• SpringBoot(v3.2.7)
• use pom.xml to reference artifacts

Environment
Windows 10

Additional context
Through debug I got some information

The entrance is nacos-client, but the final error is due to the constructor method error returned by OpenTelemetryDataSource

error:

entrance:

I have been tracking the problem through debug and found the method link is as follows:

CacheData(nacos-client) -> publish RefreshEvent by ApplicationContext -> SimpleApplicationEventMulticaster#invokeListener (spring-context) -> ... -> ConfigurationPropertiesRebinder#onApplicationEvent -> ... -> ConfigurationPropertiesRebinder#rebind(String name, ApplicationContext appContext) -> initializeBean#initializeBean -> ... -> ConfigurationPropertiesBean#get which Causes an error

beacause of the findFactoryMethod returns the wrong construction method, it causes an error in bindTarget = bindTarget.withExistingValue(bean);

and i find that if factoryMethod return null. in ConfigurationPropertiesBean#createBindTarget it can return correct Constructor

finally catch by ConfigurationPropertiesRebinder#rebind

This looks like a bug right?

[trask]

transferred to opentelemetry-java-instrumentation repo where the spring boot starter lives

cc @jeanbisutti @zeitlinger

[jeanbisutti]

@kkz-01 Could you please provide a small repro with the detailed steps to reproduce the issue? It would help investigate.

[kkz-01]

@jeanbisutti you can find code in repository
I have provided detailed steps to reproduce the issue and related picture in README.md

[kkz-01]

I looked the code of opentelemetry-spring-boot-starter and found that OpenTelemetryDataSource wraps the data source through DataSourcePostProcessor#postProcessAfterInitialization but does not inject it into the container. I think the easiest way to fix this problem is to inject OpenTelemetryDataSource into the container through @Bean or other methods.

[kkz-01]

Because OpenTelemetryDataSource is not injected into the container and in SpringBoot DataSourceConfiguration$Hikari#dataSource method create a Default HikariDataSource, the bean obtained by the beanFactory.getMergedBeanDefinition("dataSource"); is the bean injected by DataSourceConfiguration$Hikari#dataSource which causes the constructor obtained is not OpenTelemetryDataSource and does not pass the check in Bindable#withExistingValue