BasicURLClassPath with Java 11

[Jean-Louis Monteiro <jl...@tomitribe.com>]

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
> at
> java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
> at
> java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591)
> at java.base/java.lang.reflect.Method.invoke(Method.java:558)
> at
> org.apache.openejb.loader.BasicURLClassPath.addJarsToPath(BasicURLClassPath.java:110)
> at
> org.apache.openejb.loader.ContextClassPath.addJarsToPath(ContextClassPath.java:39)
> at org.apache.openejb.server.Main.main(Main.java:126)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.openejb.cli.MainImpl.main(MainImpl.java:149)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.apache.openejb.cli.Bootstrap.main(Bootstrap.java:189)
>

Does someone know why we have done that?
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

Re: BasicURLClassPath with Java 11

[David Blevins <da...@gmail.com>]

> On Jul 24, 2019, at 5:50 AM, Jean-Louis Monteiro <jl...@tomitribe.com> 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