> On Jul 24, 2019, at 5:50 AM, Jean-Louis Monteiro <[email protected]> > wrote: > > Hi, > > In this PR, looks like we changed our code to use BasicURLClassPath. > https://github.com/apache/tomee/pull/176 > > But while running under Java 11, I just realized, it produces exceptions > >> java.lang.IllegalAccessException: class >> org.apache.openejb.loader.BasicURLClassPath cannot access class >> jdk.internal.loader.URLClassPath (in module java.base) because module >> java.base does not export jdk.internal.loader to unnamed module @157632c9 [...] > Does someone know why we have done that?
I think this is one of those situations where zooming out and rethinking our approach is good. The `ClassPath` abstraction likely needs to die. The fundamental concept of it is to "edit" a ClassLoader. This wasn't really a good idea in 2003-2006 range when I added it and is worse of an idea now with modularity. We use it primarily for: - OpenEJB standalone uses it to do a Tomcat-like startup that dynamically adds files under lib/*.jar. Tomcat, however, does this by creating a child classloader. OpenEJB standalone does it by pushing the lib/*.jars files into the system classloader. We don't really need to do that, we could create a child classloader. Or we could eliminate the OpenEJB standalone dist and trim some code out. - TomEE Webapps use it for dynamically forcing jars into the Tomcat classloaders to virtually make a "TomEE" on the fly. We already discussed eliminating this and agreed it was a good goal. - The new command-line tools use it like OpenEJB standalone uses it. It could create a vanilla child classloader, or it could have the script create a more complete classpath. Either would work. -David
