PathMatchingResourcePatternResolver#convertClassLoaderURL drops URLStreamHandler in version 6.1.x

[vsudebil]

I'm trying to upgrade to spring version 6.1.x. Due to the specific nature of a project, we use a custom class loader and custom java.net.URLStreamHandler which handles the opening of the JAR files.

Up to version 6.0.x the URL object remains as is in PathMatchingResourcePatternResolver#convertClassLoaderURL but since version 6.1.x the whole URL object is replaced by a new one keeping only the URL string.

Currently, there is no method how to keep the URLStreamHandler as the framework constructs a new URL. It would be beneficial to have the possibility to turn off this behaviour or somehow pass the handler of the original URL to the new one constructed.

[jhoeller]

This is actually a regression as of 6.1.7 where we enforce the use of cleaned URLs: #32828

We'll see what we can do to retain the original URL in case of a custom URLStreamHandler. Do those URLs look like regular jar URLs in every other respect, or is there some indication of being a custom URL (other than internally storing a custom handler)?

[vsudebil]

The URLs look like regular jar URLs.
We are required to utilize a custom URLStreamHandler because the JAR file is encrypted and cannot be accessed using the standard method.

[jhoeller]

For the time being, the only way to prevent this URL replacement is for the original URL to expose a pre-cleaned path so that the StringUtils.cleanPath(urlString).equals(urlString) condition is met, in which case the original URL is being retained already. Maybe that's something you could revise your custom ClassLoader towards.

For 6.1.12, we can try to retain the original URL based on some extra indication that it has a custom handler. However, URLStreamHandler usage is pretty opaque, so it is not obvious how we can check for the original URL having such a custom handler. We might be able to do new URL(originalUrl.toString()).equals(originalUrl) and see whether this returns false, assuming that the associated handler differs then. Would that work in your scenario?

FWIW our revision in 6.1 is driven by the deprecation of all URL constructors in JDK 20: https://docs.oracle.com/en%2Fjava%2Fjavase%2F22%2Fdocs%2Fapi%2F%2F/java.base/java/net/URL.html#constructor-deprecation

[vsudebil]

The condition StringUtils.cleanPath(urlString).equals(urlString) is not met only due to path separators in our case. We will revise the ClassLoader if it is feasible to return the cleaned path.

However, the approach of checking equals seems ok (as it is probably the only option, how to check if the URL has a custom URLStreamHandler).