4.x: MP test fails when using -DforkCount=0

[romain-grecourt]

Environment Details

• Helidon Version: 4.0.12
• Helidon MP

---

Problem Description

When using Surefire in "no-fork" mode with Helidon MP projects, resource classes are not discovered.
This causes the tests to fail with 404.

---

Thread.currentThread().getContextClassLoader() is used to load the discovered classes, however it's set to the application class-loader. Instead this should be either the class-loader of the current class or the class-loader created by surefire.

This seems to be related to #2269 which nullifies the fix to WELD-2494 which in turn is a work-around to JDK-8172726.

---

In short...

JDK-8172726 changed the behavior of fork-join in JDK9+ to hard-set the thread context class-loader to the system class-loader instead of the parent class-loader.

In environments where the application code is dynamically loaded (E.g. application server, OSGi, surefire in no-fork) the system class-loader cannot be used to load the application code.

WELD-2494 introduces a work-around: wrap the fork-join task to set the TCCL to null and then handle a fallback.

---

2269 fixes both 2207 and 2115

org.eclipse.microprofile.config.ConfigProvider.getConfig() is sensitive to the thread context class-loader, Helidon's implementation does cache per class-loader.

And... io.helidon.config.MetaConfigFinder does not handle the thread context class-loader being null.

So far I did not manage to reproduce the behavior described in 2207 ; however it is crucial to understand before making any changes.

Steps to reproduce

mvn test -DforkCount=0