Since Java can handle Windows paths expressed with forward slashes, people usually express any filesystem path in a configuration file with forward slashes, no matter the OS.
However, Spring's PathEditor
doesn't seem to handle what seems to me like a pretty common case:
PathEditor tested = new PathEditor();
tested.setAsText("c:/tmp");
While FileEditor
handles this case just fine and the rather obvious Path.of("c:/tmp");
works, the second line will result in:
java.io.FileNotFoundException: class path resource [c:/tmp] cannot be resolved to URL because it does not exist
at org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:214)
at org.springframework.core.io.AbstractFileResolvingResource.getFile(AbstractFileResolvingResource.java:160)
at org.springframework.beans.propertyeditors.PathEditor.setAsText(PathEditor.java:109)
... 71 more
I should mention that, like for Path.of(...);
, as a user, I wouldn't expect the resulting Path to necessarily exist on the filesystem. An example use-case would be specifying a path at which something should be created by the application. Such a path wouldn't exist at startup.
Using: org.springframework:spring-beans:5.3.25
Comment From: sreenath-tm
Hi, I would like to contribute to this issue can you assign this issue to me? Can you let me know how I can go about solving this issue?
Comment From: sbrannen
Hi @sreenath-tm,
Thanks for making the offer, but please hold off on submitting a PR.
This issue is still labeled as waiting-for-triage
. Consequently, we have not yet investigated the claim. I'll bring this up with the team, and we will come to a decision.
Comment From: snicoll
However, Spring's PathEditor doesn't seem to handle what seems to me like a pretty common case:
The value is not a path but an URL that ultimately delegates to DefaultResourceLoader#getResource
. As such, it's like any file URL in Java using Windows. You can make it more obvious it's an url and the following should work:
tested.setAsText("file:///c:/tmp");
Comment From: netmikey
May I kindly ask you to reconsider this?
I find it very counterintuitive that a class called PathEditor
doesn't behave like the Path
class it's supposed to convert to. If I use a Path
object in a configuration, I would expect to be able to specify an actual path as string - straight forward - and not having to disguise it as file URL (otherwise I would've used URL
).
The reliance on DefaultResourceLoader
seems like an implementation detail and shouldn't be a justification for a clumsy API.
Comment From: snicoll
Alright. I thought using it as an URI was actually expected to avoid ending in a situation where we'd have too many fallbacks. We've discussed this and @jhoeller thinks we can make the fallback more lenient.