`PathMatchingResourcePatternResolver` can no longer handle paths containing spaces and special characters

[whydoievenneedthis]

Affects: spring-core : 6.0.5

---

When the spring application is in a directory that contains a space, it skips probably all @ComponentScan-based bean creations (I am sure it skips all @Configuration classes, and I suspect it also skips all @RestControllers as well, so it is a pretty safe bet to assume that it skips everything else as well):

2023-02-25 01:09:30.921 DEBUG [           main] o.s.c.i.s.PathMatchingResourcePatternResolver : 
Failed to complete search in directory 
[C:\My%20Projects\sample\build\classes\java\main\com\example] for files matching pattern 
[**/*.class]: java.nio.file.NoSuchFileException: 
C:\My%20Projects\sample\build\classes\java\main\com\example

Functionality was working fine with 6.0.4.

Also, log level either in the line above, or somewhere close by must be ERROR, not DEBUG.

[wilkinsona]

This is a regression introduced in dbf3609. See spring-projects/spring-boot#34379 for further details.

[sbrannen]

Thanks for reporting the regression.

The cause for the regression is that java.net.URL.getPath() does not decode the path; whereas, java.net.URI.getPath() does decode the path.

Consequently, PathMatchingResourcePatternResolver.convertModuleSystemURI(URI) works as expected, but the recently modified PathMatchingResourcePatternResolver.convertClassLoaderURL(URL) does not.

We'll look into it and provide a fix in 6.0.6.

[sbrannen]

Possible solution outlined by @JoeyBling in #29934 (comment).

[123Haynes]

This also happens if the path contains other chars like ## not only with spaces.
I ran into this because my application is named frontend##3.0.0.war so the tomcat manager recognizes the 3.0.0 as the version number.

[sbrannen]

This also happens if the path contains other chars like ## not only with spaces.

Yes, we are aware that it is a general decoding issue.

I've updated the title of this issue to reflect that.

Thanks for prompting that.