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