Use app's thread context class loader for callbacks into app

[trask]

Wondering if there's any reason not to do this?

The test is not very realistic. The problem is that the agent's thread context class loader appears to be ClassLoader.getSystemClassLoader(), which works in simple unit tests where the app is also in the system class loader. Maybe a smoke test (in an app server with nested class loaders) would be better?

[mateuszrzeszutek]

Is there a problem with how the gauge functions are run? Why would we want to touch the context CL in the first place?

[laurit]

This has come up previously in #7391 #7220 Probably it would be more correct to use the context class loader from the time when the instrument was registered.

[mateuszrzeszutek]

Thanks, I completely forgot about that issue 😅 (I did remember removing the setContextClassLoader() calls though)

The same issue also applies to FunctionCounter and FunctionTimer, we should update them too. (And the OTel metrics API itself... though we might want to leave fixing that for later)

[mateuszrzeszutek]

Probably it would be more correct to use the context class loader from the time when the instrument was registered.

Context classloader, and if not set then obj.getClass().getClassloader()?

[sebastian-hans-swm]

Thank you for taking up the issue! We had to disable a few interesting metrics due to this when moving to metrics collection via the agent. I'm really looking forward to re-enabling them.

[laurit]

@sebastian-hans-swm could you elaborate why it fails for you, are you doing something similar to #7220

[sebastian-hans-swm]

@laurit, we are using a Gauge to keep track of the number of Quartz jobs in our application. The Quartz API allows us to query its triggers from the database. Somewhere in the call chain Quartz tries to create a proxy for the JDBC Connection (the implementation of which is loaded lazily by Spring Boot magic) using the thread context class loader – and fails.

[trask]

Probably it would be more correct to use the context class loader from the time when the instrument was registered.

done 👍

Context classloader, and if not set then obj.getClass().getClassloader()?

it seems more precise to only carry over the context class loader from registration to execution, but I could easily be convinced otherwise

The same issue also applies to FunctionCounter and FunctionTimer, we should update them too

added tests for these (they are covered by the same underlying change) 👍

(And the OTel metrics API itself... though we might want to leave fixing that for later)

opened open-telemetry/opentelemetry-java#5694 👍

[mateuszrzeszutek]

it seems more precise to only carry over the context class loader from registration to execution, but I could easily be convinced otherwise

I don't have a strong opinion (in fact it's so weak it's barely there), I'd be fine with merging this and waiting for further bug reports.