Update code that needs usage of the Module APIs

[sbordet]

There is code inherited from 9.4.x that uses system properties to figure out module-path and such. For Jetty 10 we need to change those places to use the Module APIs.

[sbordet]

@janbartel the idea of this issue is to update the code in MetaInfConfiguration.findAndFilterContainerPaths() now that we can use Java 9+ APIs.

There, we currently use system properties java.class.path and jdk.module.path to get the jars and match them against a regexp.

I searched around and there is currently no API way to get the jars from the classpath. First reason is that the classloader is not anymore a URLClassLoader. Second reason is that because stuff in the classpath is in an unnamed module, there is no way to access other Module API that would give us the information we want. For example, Module m = Server.class.getModule() would return the unnamed module, but then m.getLayer() == null and it's the ModuleLayer that has API to give access to the jar URIs. So I think the parsing of java.class.path should stay as is.

For jdk.module.path we can do this, assuming we run from the module-path:

Module module = WebAppContext.class.getModule();
ModuleLayer layer = module.getLayer();
Set<ResolvedModule> modules = layer.configuration().modules();
modules.stream()
        .map(ResolvedModule::reference)
        .map(ModuleReference::location)
        .filter(Optional::isPresent)
        .forEach(System.err::println);

The key here is to be able to access the layer to get the ResolvedModules; they have the right API to get the information about the jar URI.

The above prints something like:

file:///home/simon/opensource/jetty/jetty10.0/jetty-distribution/target/distribution/lib/jetty-rewrite-10.0.0-SNAPSHOT.jar
jrt:/jdk.unsupported.desktop
file:///home/simon/opensource/jetty/jetty10.0/jetty-distribution/target/distribution/lib/websocket/javax-websocket-client-10.0.0-SNAPSHOT.jar
file:///home/simon/opensource/jetty/jetty10.0/jetty-distribution/target/distribution/lib/annotations/asm-commons-7.0.jar
jrt:/jdk.jdeps
jrt:/jdk.crypto.cryptoki
file:///home/simon/opensource/jetty/jetty10.0/jetty-distribution/target/distribution/lib/jetty-util-10.0.0-SNAPSHOT.jar
file:///home/simon/opensource/jetty/jetty10.0/jetty-distribution/target/distribution/lib/apache-jsp/org.eclipse.jetty.apache-jsp-10.0.0-SNAPSHOT.jar
file:///home/simon/opensource/jetty/jetty10.0/jetty-distribution/target/distribution/lib/jetty-servlet-api-4.0.2.jar
file:///home/simon/opensource/jetty/jetty10.0/jetty-distribution/target/distribution/lib/websocket/websocket-servlet-10.0.0-SNAPSHOT.jar
jrt:/jdk.jlink
jrt:/java.naming
...

Using the API will give us the resolved modules, which means that modules (and hence jars) that are not resolved won't show up. I guess that's not a problem because if they're not resolved they're inaccessible anyway. I mention this because with jdk.module.path we are considering directories and possibly modular jars that are not resolved.

Thoughts?

[stale[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.