new-classpath-resource returns 404s when jar hosted on Windows

[OliverM]

I'm generating an uberjar from a yada project and running that on a VM via java -jar uberjar.jar. This works perfectly on Unix servers but I'm getting 404 errors on Windows machines for resources handled by new-classpath-resource. From looking at the source it seems that the resource uses a Unix path separator rather than looking up the current path separator from the JVM.

If that sounds like a reasonable reason why, I'm happy to take a crack at a pull request myself, but I'm not sure what to do about tests - presumably the test suite shouldn't have tests that can only pass on Windows?

[malcolmsparks]

Hmm - I think that / should work on both platforms, since we're talking jar resources here. But yes, do have a play with it and see if you can figure out why it's not working. We can discuss on this thread.

Thanks for spotting this and helping out!

[solatis]

As some additional information, I know there are issues with Windows when generating uberjars in boot, due to conflicting manifest.xmls. I had to resort to doing this, specifically:

(uber :exclude #{#"(?i)^META-INF/[^/]*.(MF|SF|RSA|DSA)$"

"(?i)^META-INF\[^/]*.(MF|SF|RSA|DSA)$"

                #"(?i)^META-INF/INDEX.LIST$"
                #"(?i)^META-INF\\INDEX.LIST$"})

[nottmey]

FYI: This problem still persists in the current version. (1.2.9)

Creating a similar resource to new-classpath-resource with a direct creation of io/resource did the trick for me, e.g. (io/resource (str "public" (-> ctx :request :path-info))) (simplified, without index files).