I appreciate the suggestion, but that sounded a bit indirect …
Instead I copied File/PathResource/Manager into new classes MappedPathResource/Manager, ripped out all the things that aren’t relevant in this case (like symlink support, case sensitivity, and watching the file system). The result is simpler than expected: the Resource class is basically identical to PathResource (minus pointer type back to the manager), and the new MappedPathResourceManager is just 150 lines or so. Here’s how to use it:
Map<String,Path> mappings = new HashMap<>();
// insert some test data
mappings.put( "/foo", Paths.get( System.getProperty("user.home") + "/.bashrc" ));
Undertow server = Undertow.builder()
new MappedPathResourceManager( mappings )))
and it seems to work and serve my purposes.
Q: Is that something that would be of use to anybody else? If so, I’d be happy to clean up the code and submit a PR.
P.S Ideally a bit a refactoring should be done so that PathResource and MappedPathResource share the same code (all these inner classes and threaded-related behavior) but that would require some kind of intermediate superclass that collects functionality common to PathResourceManager and MappedPathResourceManager.
P.S.2: I like Undertow. Give what kind of $%*&WQ@)$^& web servers there are in Java land …
You could possibly use io.undertow.server.handlers.resource.ResourceSupplier, and then use PathResourceManager under the hood to actually return a path resource. If all these files have a common root path you could basically create a PathResourceManager that maps to this, and then use Map<String, Resource> in the supplier.