Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-2494

WeldResourceLoader.getClassLoader() will malfunction with JDK 9+ if ForkJoinPool is used


    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 3.0.4.Final
    • Fix Version/s: 3.0.5.Final
    • Component/s: None
    • Labels:


      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

        Gliffy Diagrams


            Issue Links



                • Assignee:
                  manovotn Matěj Novotný
                  manovotn Matěj Novotný
                • Votes:
                  0 Vote for this issue
                  2 Start watching this issue


                  • Created: