DataSourceUnwrapper calls Wrapper.isWrapperFor with a interface rather than an class causing HikariDataSourceMetricsRegistry failure

[ankeway]

This problem causing hikariDataSource return null
because target.isInterface()

org.springframework.boot.actuate.autoconfigure.metrics.jdbc.DataSourcePoolMetricsAutoConfiguration.HikariDataSourceMetricsConfiguration.bindMetricsRegistryToHikariDataSources(Collection)

@Autowired
void bindMetricsRegistryToHikariDataSources(Collection dataSources) {
  for (DataSource dataSource : dataSources) {
    HikariDataSource hikariDataSource = DataSourceUnwrapper.unwrap(dataSource, HikariDataSource.class);
    if (hikariDataSource != null) {
        bindMetricsRegistryToHikariDataSource(hikariDataSource);
    }
  }
}

[ifrozenice]

yes， in 2.3.7Version, there is no hikaricp metrics in actuator/prometheus endpoint。
in2.3.4Version, it's work well。

[philwebb]

@ankeway Can you provide some more details about your setup, or even better a sample application that replicates the issue. I'd like to know the DataSource class that gets passed to the unwrap method.

[ankeway]

@ankeway Can you provide some more details about your setup, or even better a sample application that replicates the issue. I'd like to know the DataSource class that gets passed to the unwrap method.

The most simple example that use HikariDataSource and Request actuator/prometheus endpoint
Both oracle and mysql, can not get the related data of DataSource
HikariDataSource hikariDataSource = DataSourceUnwrapper.unwrap(dataSource, HikariDataSource.class);
because hikariDataSource return null;
you can debug
org.springframework.boot.actuate.autoconfigure.metrics.jdbc.DataSourcePoolMetricsAutoConfiguration.HikariDataSourceMetricsConfiguration class, bindMetricsRegistryToHikariDataSources method
Spring Boot 2.3.6 don't have this problem， The only difference is target.isInterface()

[snicoll]

The most simple example that use HikariDataSource and Request actuator/prometheus endpoint

@ankeway unfortunately, that doesn't help. We're asking for a sample because we have several tests that exercise this scenario and they pass. As Phil has requested, can you please share a sample that showcases the problem? You can do so by attaching a zip to this issue or share a link to a GitHub repository.

[ankeway]

The most simple example that use HikariDataSource and Request actuator/prometheus endpoint

@ankeway unfortunately, that doesn't help. We're asking for a sample because we have several tests that exercise this scenario and they pass. As Phil has requested, can you please share a sample that showcases the problem? You can do so by attaching a zip to this issue or share a link to a GitHub repository.

https://github.com/ankeway/DsDemo.git

if add such as javamelody-spring-boot-starter , dataSource will become net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler
or like JdkDynamicAopProxy io.opentracing.contrib.spring.cloud.jdbc.JdbcAspect. a dynamic proxy,
so try to safeUnwrap JdbcWrapper or JdkDynamicAopProxy and all of them are not a isInterface
but spring boot 2.3.4, don't have target.isInterface(), DataSourceUnwrapper.unwrap(JdbcWrapper, DynamicRoutingDataSource.class) return DynamicRoutingDataSource;
spring boot 2.3.7 DataSourceUnwrapper.unwrap(JdbcWrapper, DynamicRoutingDataSource.class) return null;
I have to use custome DynamicRoutingDataSourceUnwrapper solve this problem

thanks

[snicoll]

@ankeway thanks for the sample although it does not reproduce the problem for me. The reference to net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler is helping though.

[snicoll]

We discussed this one today with two options:

• Try to unwrap HikariConfigMXBean rather as it may expose everything that we need.
• Handle the Oracle case explicitly and revert the interface check

If the first option works we'd have to report an issue against the HikariCP project to suggest an interface to be offered by the project for datasource unwrap needs like this one.

[oburgosm]

But with the new implementation, call to DataSourceUnwrapper.unwrap with a class, for example DataSourceUnwrapper.unwrap(myds, AtomikosDataSourceBean.class), always return null.

As workaround I can call DataSourceUnwrapper.unwrap(myds, DataSource.class, AtomikosDataSourceBean.class), but I think it's a bug.

[wilkinsona]

Unfortunately, the contract for Wrapper.unwrap(Class<?>) states that the argument must be an interface. Prior to the change made in #24200 we were not adhering to the contract which caused problems with some DataSource implementations.

Using DataSourceUnwrapper.unwrap(DataSource, Class<I>, Class<T>) isn't a workaround and is what you should do when you want the result of unwrap to be a class rather than an interface. For Atomikos, I would call unwrap(myds, ConnectionPoolProperties.class, AtomikosDataSourceBean.class). This uses Atomikos's ConnectionPoolProperties interface to do the unwrapping and then casts it to AtomikosDataSourceBean.

[baogutang]

you can use instead of org.springframework.boot.jdbc.DataSourceUnwrapper#unwrap(javax.sql.DataSource, java.lang.Class, java.lang.Class),it works!

[baogutang]

you can use instead of org.springframework.boot.jdbc.DataSourceUnwrapper#unwrap(javax.sql.DataSource, java.lang.Class, java.lang.Class),it works!

for example： HikariDataSource hikariDataSource = DataSourceUnwrapper.unwrap(dataSource, HikariConfigMXBean.class, HikariDataSource.class);