Question about Paths.get(URI) in deployed web application

[hubfruser]

Question: anyone has experience of constructing Path using URI, like Paths.get(URI), in deployed web applications?

The Readme says: " In most cases it is sufficient to use Java Path objects constructed with a URI representing s3:// URI. Constructing Paths with Strings (as opposed to URIs) will normally default to the local filesystems NIO provider rather than this provider so use of URIs should always be preferred over Strings for all Path objects (even local ones)."

Indeed, constructing Paths.getwith URI is the simplest like below:

var s3Path = Paths.get(URI.create(args[0]));   

It worked on my standalone local test program with main(). But when I tried to construct Path this way in a deployed web application, I got "Provider s3 not found" error. The cause was that Paths.get(URI) checks FileSystemProvider.installedProviders() , which search FileSystemProvider class in system classloader (not the application level class loader in current thread's context) . Below code on line 153 shows FileSystemProvider.installedProviders().

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java

Environment: JDK 8, Weblogic

This aws-java-nio-spi libraries resides in one webpplication's ear, not on system class path where only jdk, and weblogic fundamental classes are loaded. The current thread's context classloader can see the classes of this application's EAR file including this aws-nio-spi library, but current thread's classloader is not the system classloader. So when Paths.get(URI) runs, code will check FileSystemProvider.installedProviders(). It can not find the S3FileSystemProvider of this library because it is not on system classpath. The library is on application's class path bundled inside the app's ear.

Now I have to manually create a S3SystemProvider first then use it to create a S3FileSystem. Then use the S3FileSytem to create a Path . It is not very clean. If I copy this aws nio libary to class path, it's said to be a bad practice to put this library (or any other custom library) to system classpath. I wonder if anyone had experience of constructing Path in deployed web applications and somehow configured their app or server settings to make system classloader be able to find the S3FileSystemProvider defined in this library.

Thank you for your time.

[stefanofornari]

Not putting libraries in the classpath is not a bad practice in all cases. I think the statement must be taken as to avoid to put everything in it. In the case of a FileSystem provider, it make sense because it is meant to add a functionality to the JVM. Therefore just put it in the system class path but be aware any war/ear will be able to access it.

Just my two cents...

[markjschreiber]

The library is intended to be used as a JVM provider and therefore must be accessible to the JVM. Depending on the JVM version this can be done by adding it to an extension folder or on the JVM classpath. I'm not sure if an EAR can add JVM providers specifically for a single app but one of the nice things about the provider model is that individual apps don't need to bundle providers or worry about how to talk to S3.

When a uri is requested by an app the JVM will check if it has a provider that can deal with the prefix (s3) and delegate to it.

[hubfruser]

Thanks, stefanofornari and Mark. I will try what you said above.