"resource:" URL scheme not supported (needed for GraalVM)

[kohlschuetter]

Jetty version(s)
12.0.0.alpha3

Java version/vendor (use: java -version)
openjdk version "19.0.1" 2022-10-18
OpenJDK Runtime Environment GraalVM CE 22.3.0 (build 19.0.1+10-jvmci-22.3-b08)
OpenJDK 64-Bit Server VM GraalVM CE 22.3.0 (build 19.0.1+10-jvmci-22.3-b08, mixed mode, sharing)

OS type/version
macOS

Description
When using Resources from the resource class path, GraalVM turns them into URLs of the abstract "resource:" scheme (e.g., resource:/com/example/server/webapp/). This resource scheme appears to be currently unsupported by Jetty:

java.lang.IllegalArgumentException: URI scheme not supported: resource:/com/example/server/webapp/
	at org.eclipse.jetty.util.resource.ResourceFactoryInternals$CompositeResourceFactory.newResource(ResourceFactoryInternals.java:145)
	at org.eclipse.jetty.util.resource.ResourceFactory.newResource(ResourceFactory.java:229)

How to reproduce?

Place a file named "test.txt" in the resource class path relative to some class (e.g., foo.bar.SomeClass -> src/main/resources/foo/bar/test.txt). Build GraalVM native image.

Compare the output of

Resource res = ResourceFactory.root().newResource(SomeClass.class.getResource("test.txt"));
System.out.println(res);    

between Hotspot and native-image.

With Hotspot, the URL will be something like jar:file:///path/to/classpath.jar!/foo/bar/test.txt or file:///path/to/resource/foo/bar/test.txt).

With GraalVM native-image, it's resource:/foo/bar/test.txt.

Note that this also means that tricks to enumerate/list the contents of a resource directory (by traversing the file hierarchy or jar archive) will fail.

[joakime]

The Resource layer in Jetty 12 is based on java.nio.file.Path and java.nio.file.FileSystem.
This was desired as the old school URL Protocol Handling is now deprecated in newer versions of Java.
So are all of the constructors on the URL class.

We have a fallback Resource implementation for URL support, but you have to register your scheme.
Example:

ResourceFactory.registerResourceFactory("resource", new URLResourceFactory());

See also https://github.com/eclipse/jetty.project/blob/jetty-12.0.x/jetty-core/jetty-util/src/test/java/org/eclipse/jetty/util/resource/UrlResourceFactoryTest.java

[joakime]

You could, alternatively, also register your own Resource implementation using the same ResourceFactory.registerResourceFactory() method.

[kohlschuetter]

Thanks for the fast response, @joakime!

So is GraalVM support out of scope for now?
Would you accept a GraalVM-compatible ResourceFactory as a submission?

fwiw, I tried the URLResourceFactory approach, but it seems it needs additional work. For example, the exists() check in URLResourceFactory fails for resource: URLs because newConnection always succeeds.

[joakime]

how would your exists() check work on your proposed ResourceFactory?
The behavior of exists() is the same as it is on Jetty 9/10/11 (which uses URL as well).

Perhaps we should add a getInputStream() check to exists as well? (but man is that SLOOOOOW).

[joakime]

GraalVM support is not something we spend time on, far too few people in the community use GraalVM to make the effort worth it.

We accept PRs though, so if you feel this is useful, then lets see it.

[kohlschuetter]

I think I've chased this bug long enough. Java Paths are fun, until they're not.

[github-actions]

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.

[joakime]

Jetty 12 support was added in PR #9136