Changes in resource loading for 3.0.4 breaks for zipped files [SPR-7559]

[spring-projects-issues]

Will May opened SPR-7559 and commented

In the AbstractFileResolvingResource.exists() method which was introduced in Spring Core 3.0.4, the call to URLConnection.getContentLength() assumes that it will return a negative number if the file doesn't exist. In actual fact, it will return -1 simply if the content length isn't known which is the case if the file is inside of a zip (or jar).

Bug introduced in commit rev. 3545 of Spring Core.

---

Affects: 3.0.4

Referenced from: commits e211c09

[spring-projects-issues]

Chris Beams commented

Thanks for the submission, Will. Unfortunately, I'm not able to reproduce this behavior. For example, the following test passes for me:

@Test
public void testJarContentsExist() throws IOException {
     assertThat(new UrlResource("jar:file:/path/to/spr7559.jar!/actualfile.txt").exists(), is(true));
     assertThat(new UrlResource("jar:file:/path/to/spr7559.jar!/bogusfile.txt").exists(), is(false));
}

Do you have a repro case that you could share? Even just explaining how you got there would be fine if you cannot actually bundle up the code and zip file.

[spring-projects-issues]

Will May commented

The problem starts with WebLogic. When the call to openConnection() is made in AbstractFileResolvingResource.exists(), it returns a weblogic.utils.zip.ZipURLConnection which extends URLConnection. ZipURLConnection doesn't override getContentLength() or getHeaderField(String), so all calls to getContentLength() will return the default which is -1.

[spring-projects-issues]

Chris Beams commented

Juergen, what do you think? This issue is reminiscent of #5988.

[spring-projects-issues]

Juergen Hoeller commented

Fixed for 3.0.5 now, through adding a fallback that checks for stream existence (as in 3.0.3 and earlier).

Please give one of the upcoming 3.0.5 snapshot a try and let me know whether it works for you...

Juergen