QueuedThreadPool sets wrong Classloader for use in quarkus

[JiriOndrusek]

Jetty version(s)
jetty-9.4.40.v20210413

Description
QueuedThreadPool sets classloader for new threads to getClass().getClassLoader() which sets classloader to QuarkusClassLoaderQuarkus Base Runtime ClassLoader for quarkus based project. This classloader can not load classes from the current project.
Correct classloader should be obtained by Thread.currentThread().getContextClassLoader(), which sets classloader to QuarkusClassLoader:Quarkus Runtime ClassLoader which works even for current projects.

This issues blocks apache/camel-quarkus#2651

How to reproduce?

git clone git@github.com:apache/camel-quarkus.git
cd camel-quarkus
git revert 406058c468609835f9f0ac91a5c0b76e4f52a392
mvnd clean install -Dquickly

cd integration-tests/avro-rpc
mvn clean test

[sbordet]

@JiriOndrusek the reason QueuedThreadPool sets the class loader in that way is this issue: #5859.

We cannot know how applications use the threads in QueuedThreadPool so basically anything we do would be wrong.
The only thing that we can do is to "reset" everything, and applications should take care of doing what they need, e.g. set the TCCL, and unset it when done.

You can override QueuedThreadPool.runJob(Runnable) to set/unset the TCCL, or you can wrap your jobs to set/unset the TCCL.

I don't think there is much that we can do in general -- if we set the TCCL we break OSGi applications, if we don't we break someone else.

See also #6396.

[JiriOndrusek]

@sbordet thanks for the explanation and some ways of solving this.. I wasn't sure whether this thing could be changed in jetty. I'll try to override it.

[sbordet]

@JiriOndrusek please report back your solution, it would help others as well. Thanks!

[janbartel]

@JiriOndrusek can this issue be closed now?

[JiriOndrusek]

This issue could be closed.

.