Support non-default file systems in PathResourceManager

PathResourceManager doesn't behave as expected when provided a base Path that does not use the default FileSystem. It ignores the provided FileSystem and looks for files in the default FileSystem instead. In other words, in this case it's not actually reading files from the base Path - it's reading files from a similar-looking Path in a different file system.

Possible fix

I got this working locally with a few minor changes. Let me know if you would like me to work on a PR.

• Add a new member variable to PathResourceManager like private FileSystem fileSystem.
• In the constructor that accepts a user-provided Path, set the manager's FileSystem to the Path's FileSystem.
• In the constructor that accepts an array of Strings instead of a Path, set the manager's FileSystem to FileSystems.getDefault().
• In the setBase(Path) method, set the manager's FileSystem to the Path's FileSystem.
• In the setBase(File) method, set the manager's FileSystem to FileSystems.getDefault().
• Replace all usages of Paths.get(...) with this.fileSystem.getPath(...).
• Replace all usages of File.separator and File.separatorChar with this.fileSystem.getSeparator().
• In PathResource, replace the one usage of File.separator with file.getFileSystem().getSeparator().

Other considerations

The PathResource.getFile() method can't work with non-default FileSystems. The Path will throw UnsupportedOperationException if you try to convert it to a File.

I don't know how much of an issue this is since it doesn't look like Undertow itself calls this getFile() method. Users would just have to avoid calling it.

Use cases

I bumped into this behavior when I tried Jimfs, an in-memory FileSystem: https://github.com/google/jimfs

I want to use Jimfs in tests because my application writes files to disk. I don't want my tests to leave behind stray files on disk, and that'll be easier to manage if everything is contained in a temporary file system that disappears when my tests complete.

Another place where a non-default FileSystem might show up is zip files. The JDK comes with a zip file system provider, so you can write code like this:

Path zipFile = Path.of("path/to/archive.zip");
try (FileSystem zipFileSystem = FilesSystems.newFileSystem(zipFile, null)) {
Path entry = zipFileSystem.getPath("path/to/entry.txt");
List<String> lines = Files.readAllLines(entry);
...
}

I have written an HTTP handler that serves up the files from within zip files on disk. If PathResourceManager respected the user-provided FileSystem, maybe I could have used PathResourceManager for that.