PathEditor cannot handle absolute Windows paths with forward slashes

[netmikey]

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

[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?

[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.

[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");

[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.

[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.