Clear context class loader from started threads

[laurit]

Thread inherits context class loader from the thread that started it. This could be problematic when a thread is started from an application thread. For example with the StrictContextStorage (which is not used by default) some agent tests run on tomcat produce the following warning

Jul 14, 2025 4:08:02 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads
WARNING: The web application [app] appears to have started a thread named [weak-ref-cleaner-strictcontextstorage] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 java.base/jdk.internal.misc.Unsafe.park(Native Method)
 java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:371)
 java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(AbstractQueuedSynchronizer.java:519)
 java.base/java.util.concurrent.ForkJoinPool.unmanagedBlock(ForkJoinPool.java:3780)
 java.base/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3725)
 java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1707)
 java.base/java.lang.ref.ReferenceQueue.await(ReferenceQueue.java:67)
 java.base/java.lang.ref.ReferenceQueue.remove0(ReferenceQueue.java:158)
 java.base/java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:234)
 io.opentelemetry.context.StrictContextStorage$PendingScopes.run(StrictContextStorage.java:270)
 java.base/java.lang.Thread.run(Thread.java:1583)

Basically this tells that even when you undeploy the application the resources can't be freed because there is thread that has a reference to the application class loader.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.00%. Comparing base (8009415) to head (41415e5).
⚠️ Report is 183 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #7488   +/-   ##
=========================================
  Coverage     90.00%   90.00%           
  Complexity     7078     7078           
=========================================
  Files           803      803           
  Lines         21405    21408    +3     
  Branches       2086     2086           
=========================================
+ Hits          19265    19268    +3     
  Misses         1477     1477           
  Partials        663      663           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jkwatson]

this seems fine. are there any downsides to removing the context class loader, though? What is it generally used for?

[laurit]

this seems fine. are there any downsides to removing the context class loader, though? What is it generally used for?

Totally forgot this PR. Context class loader is used when code in the parent class loader needs to load a class from the child class loader. For example JDK uses it when you call SericeLoader.load without a class loader. DocumentBuilderFactory.newInstance tries to load the parser implementation from context class loader when class loader is not specified. Frameworks could use it to load webapp classes when the framework jars are in the ear class loader.
There shouldn't be downsides to removing it because in our code we don't use the context class loader. If it is used and we end up loading something from the application it would definitely be unexpected.

[brunobat]

@laurit I'm having an issue related with this PR here: quarkusio/quarkus#52252
Leaving a note here that might be useful to someone else.
When clearing the classloader, Gauges calling app beans, as an example, cannot be resolved.
This was working for us probably for the wrong reasons and the right way would be to instantiate a managed executor coming from the APP/framework itself. The default reader doesn't allow to set that:

opentelemetry-java/sdk-extensions/autoconfigure/src/main/java/io/opentelemetry/sdk/autoconfigure/MetricExporterConfiguration.java

Lines 82 to 85 in 7655192

	MetricReader reader =
	PeriodicMetricReader.builder(customizedMetricExporter)
	.setInterval(config.getDuration("otel.metric.export.interval", DEFAULT_EXPORT_INTERVAL))
	.build();

The only alternative I found was to create a new MetricReader from the MetricReaderCustomizer. See: quarkusio/quarkus#52585