WeldResourceLoader is used to determine a class loader to load classes with for further processing. The code now tries to grab the TCCL and work primarily with that, using WeldResourceLoader.class.getClassLoader() as a fallback should TCCL be null.

Now, if in SE and with bean discovery enabled, we by default use ForkJoinPool.
JDK 8 and 9+ both have different results if you invoke Thread.currentThread().getContextClassLoader() and operate on a thread from ForkJoinPool. See this JDK issue for more info. In short, since JDK 9+, any thread from this pool has hard-set system CL as it's TCCL whereas in JDK 8 this was inherited from parent thread.

Alas, system CL cannot load the classes we need, hence we get errors.

The solution would be to either:

• Implement a fallback behaviour, trying TCCL first, then using CL which loaded WeldResourceLoader
• Setting setting TCCL to null, just like it's done in WFLY
  • Can be done via wrapping Callable, first set TCCL to null, then call() and finally set TCCL back to previous value
  • Preferable solution