Title: Message Title
|
|
|
{{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|https://bugs.openjdk.java.net/browse/JDK-8172726] 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 implement either: * Implement a fallback behaviour, trying TCCL first, then using CL which loaded {{WeldResourceLoader}} . Alternatively, we can think of * Setting setting setting TCCL to null, just like it's done [in WFLY|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/WeldExecutorServices.java#L75] . ** Can be done via wrapping {{Callable}}, first set TCCL to null, then {{call()}} and finally set TCCL back to previous value ** *Preferable solution* |
|
|
|
|
|
_______________________________________________
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues