Parent / child classloading control

[Jonathan Gallimore <jo...@gmail.com>]

Hey folks

I'm looking at an issue where a third-party library used in a webapp
includes an API and implementation - in this case MicroProfile config 1.3.
The API is using the service loader mechanism to load the implementation,
but has code in it to force the parent classloader to be used. The
MicroProfile Config 1.4 API actually fixes this, but the specific versions
of libraries  included in applications isn't in my control.

The following patch to TomEE enables this to work:

---
a/container/openejb-core/src/main/java/org/apache/openejb/util/classloader/URLClassLoaderFirst.java
+++
b/container/openejb-core/src/main/java/org/apache/openejb/util/classloader/URLClassLoaderFirst.java
@@ -153,7 +153,11 @@ public class URLClassLoaderFirst extends
URLClassLoader {
     }

     public static boolean shouldDelegateToTheContainer(final ClassLoader
loader, final String name) {
-        return shouldSkipJsf(loader, name) || shouldSkipSlf4j(loader,
name);
+        return shouldSkipJsf(loader, name) || shouldSkipSlf4j(loader,
name) || shouldSkipMicroProfileApi(loader, name);
+    }
+
+    private static boolean shouldSkipMicroProfileApi(ClassLoader loader,
String name) {
+        return name.startsWith("org.eclipse.microprofile.config.");
     }

But I wonder if we could actually make this smarter - and allow people to
configure patterns that will always come from the webapp classpath (or
vice-versa). If you look at the code
for org.apache.openejb.util.classloader.URLClassLoaderFirst there's all
sorts of logic in there - no doubt all very valid, but I think some config
to cover other edge cases would be useful.

What do you think?

Jon