Description
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?
Activity
trask commentedon Mar 13, 2025
transferred to opentelemetry-java-instrumentation repo where the spring boot starter lives
cc @jeanbisutti @zeitlinger
jeanbisutti commentedon Mar 13, 2025
@kkz-01 Could you please provide a small repro with the detailed steps to reproduce the issue? It would help investigate.
kkz-01 commentedon Mar 14, 2025
@jeanbisutti you can find code in repository
I have provided detailed steps to reproduce the issue and related picture in README.md
kkz-01 commentedon Mar 16, 2025
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 commentedon Mar 16, 2025
Because
OpenTelemetryDataSource
is not injected into the container and in SpringBootDataSourceConfiguration$Hikari#dataSource
method create a Default HikariDataSource, the bean obtained by thebeanFactory.getMergedBeanDefinition("dataSource");
is the bean injected byDataSourceConfiguration$Hikari#dataSource
which causes the constructor obtained is not OpenTelemetryDataSource and does not pass the check in Bindable#withExistingValuezeitlinger commentedon Mar 17, 2025
@kkz-01 sounds like you've found the root cause. A PR with a fix would be highly welcome 😄
shellysam commentedon Apr 30, 2025
@kkz-01 @zeitlinger
I also face the same issue. Is there a fix? Or a way how this can be handled?
dngyukm commentedon May 19, 2025
@kkz-01 @zeitlinger
Hello, I’d like to work on this issue if that’s alright.
zeitlinger commentedon May 19, 2025
@dngyukm yes that would be awesome 😄