Un-deprecate PathResource (for java.nio.file.Path resolution in createRelative)

[userquin]

When creating a FileSystemResource with a Path containing .. in the path, then createRelative resolves to a wrong path.

The problem resides on StringUtils::applyRelativePath method: I suggest change the method on FileSystemResource checking first if the location is a Path and then use Path::resolve instead calling StringUtils::applyRelativePath.

println(FileSystemResource(Paths.get("../xxxx/dist/")).createRelative("index.html"))

print ../index.html instead ../xxx/dist/index.html.

Attached image shows the variables inside FileSystemResource::createRelative method.

[userquin]

I'm using spring.resource.static-locations on a webflux project and works with default ones (classpath resources), but externalizing resources doesn't work due to the reported error when using .. in the path. It work when using paths without ...

[jhoeller]

As far as I can reproduce this, it is unfortunately by design: Due to the handling of trailing slashes in the java.io.File and java.nio.file.Path APIs, the cleaned paths always point to the directory itself, not to a base path for subdirectories. Resource.createRelative therefore applies at the same level as the directory, consistent for java.io.File and java.nio.file.Path sources.

Quoting the FileSystemResource(File) javadoc: When building relative resources via createRelative, the relative path will apply at the same directory level: e.g. new File("C:/dir1"), relative path "dir2" -> "C:/dir2"! If you prefer to have relative paths built underneath the given root directory, use the FileSystemResource(String) constructor with a file path to append a trailing slash to the root path: "C:/dir1/", which indicates this directory as root for all relative paths.

I suppose we should add the same comment to the FileSystemResource(Path) constructor. As for usage scenarios in Boot, is that particular constructor being used? This could be replaced by FileSystemResource(String) usage where the trailing slash is going to be an actual differentiator for a base path.

[jhoeller]

It seems that our now deprecated PathResource implements the behavior that you're suggesting. Maybe we should un-deprecate it for pure java.nio.file.Path handling, independent from FileSystemResource semantics, if such behavior is still desirable for some scenarios. Since it only got deprecated in 5.1.1, we could still easily un-deprecate it in 5.1.13+.

[userquin]

I think it will be necessary to do it (un-deprecate), I just create my own to handle only Path resources: why to handle the same way if java.nio resolves almost all problems to resolve path problems, including resolving .. uri path requests?.