David M. Lloyd

> > Could it be that `RuntimeUpdatesProcessor` is getting duplicated onto both class loaders, and it's the "wrong one" being accessed? Or something along those lines? > > Yes, that's...

> > Could it be that `RuntimeUpdatesProcessor` is getting duplicated onto both class loaders, and it's the "wrong one" being accessed? Or something along those lines? > > Yes, that's...

> > The first class loader argument (the source class loader) was (iirc) originally used as a test for the class being cloned, but it didn't end up being usable...

This does seem like a real bug to me. Our thread pools should always be propagating the correct class loader, so it's odd that it's being erased somehow.

I don't know about how any of the higher-level frameworks do it, but at the lowest level the thread pool (`EnhancedQueueExecutor`) captures the TCCL of the calling thread at the...

Poking around in the JDK, it looks like it only uses the delegate executor *sometimes*. Sometimes you're running from the selector manager thread which doesn't necessarily do anything with TCCL...

A workaround could be to wrap the injected ManagedExecutor with your own executor that simply initializes the TCCL before submitting the task.

> > Yeah, @gsmet is proposing reverting #40033 in the 3.11 branch - which would be done by opening a PR against that branch specifically > > For what I...

#41664 might solve this. I think maybe the logging library switched from `wildfly-common` to `smallrye-common-net` for this at some point? Anyway there's a decent chance that this solves the problem,...

I think this was indirectly caused by #39295. On reaugment, the dev mode processor forces the JAR type to be `mutable-jar`. Previously, this overrode the native-build setting, but now that...