The idea of lazy Datasource is to have it up once it needed/possible. In my case I put Lazy there because before connection the app should open a secured tunnel to the DB server. But this DataSourcePoolMetricsAutoConfiguration still starts the connection on the app start.

DataSourcePoolMetricsAutoConfiguration should track those connection but only after it started.

(moving out of context also that the scope of connection can be PROTOTYPE and so this metric useless as the instance it working on is every time new)

Comment From: wilkinsona

Unfortunately, I don't believe it's possible to detect when a @Lazy bean is eventually initialized.

Rather than relying on nothing using the DataSource until the secured tunnel has been opened, have you considered configuring your DataSource bean to depend on the bean that initialises the tunnel? That should ensure that the tunnel is open before the DataSource attempts to connect to the database, no matter how the DataSource is used in your application.

Comment From: msangel

Once again: the problem here is that DataSourcePoolMetricsAutoConfiguration cause @Lazy beans initialization at startup.

Also that is not true that impossible to detect lazy beans, the very first result in google show the solution: https://stackoverflow.com/questions/48328189/spring-detect-lazy-beans-at-runtime

for the beginning this metric configuration can simply skip lazy beans, but provide a way to add data sources there at runtime, so the responsibility of tracking metrics will be for that person who put @lazy annotation.

Comment From: msangel

Ideal case: specific listener that listen to certain type of lazy beans initialization and add them to metric tracker after instantiation (and remove on destruct, like in case of PROTOTYPE scoping)

Comment From: wilkinsona

I didn't say that it was impossible to detect lazy beans. What I said was that I don't believe it's possible to detect when a lazy bean has eventually been initialized. Those are two quite different things.

for the beginning this metric configuration can simply skip lazy beans

Unfortunately, this would be a breaking change for anyone currently relying on metrics being published for a @Lazy DataSource. We could perhaps introduce it has an opt-in configuration option, but it's not yet clear to me that it's needed.

From what you've described thus far, I'm not sure that @Lazy is the ideal way to solve the problem that you have. It sounds like you need to initialize things in a particular order and @Lazy doesn't do that. I sounds like it would be more robust if you used @DependsOn to ensure that the secure tunnel is initialized before the DataSource is used.

If this suggestion doesn't help and you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

Comment From: msangel

Thanks for the clarifying.

The solution I did is:

@SpringBootApplication(exclude = {
        DataSourcePoolMetricsAutoConfiguration.class
})

and after added own DataSourcePoolMetricsAutoConfiguration with own implementation.