PathMatchingResourcePatternResolver should close jar file from JarURLConnection if not cached [SPR-6295]

[spring-projects-issues]

Stoehr Sukachevin opened SPR-6295 and commented

The "org.springframework.core.io.support.PathMatchingResourcePatternResolver#doFindPathMatchingJarResources(Resource, String)" method does not close a Jar file that it opens if it gets it from a JarURLConnection directly. The reason that is given in the code as to why the Jar file is not closed from a JarURLConnection is because the JarURLConnection "might cache the file reference". However, "setUseCaches(false)" is called on the JarURLConnection instance when it is first obtained presumably because we do not want any caching done. (And internally, at least for the Sun JVM version of the JarURLConnection subclass [sun.net.www.protocol.jar.JarURLConnection], if "useCaches" is "false", then the Jar file is closed after it is no longer needed [e.g., when the input stream from the JarURLConnection instance is closed].)

The net result of this is that the Jar file will NOT be closed for an undetermined
length of time (until the Jar file's "finalize()" method is called by the GC), and in Windows, the Jar file will most likely have an open-file lock on it unnecessarily after this method completes.

The solution is to simply close the Jar file unconditionally at the end of the method. (Curently, it is only closed when the "newJarFile" flag is set, which is not the case when the Jar file is retrieved from a JarURLConnection directly.)

---

Affects: 2.5.6

Issue Links:

• Regression: DLL handled as classpath resource [SPR-12928] #17521 Regression: DLL handled as classpath resource
• PathMatchingResourcePatternResolver cannot search for "classpath*" patterns in a jar file roots [SPR-12095] #16711 PathMatchingResourcePatternResolver cannot search for "classpath*" patterns in a jar file roots
• PathMatchingResourcePatternResolver does not consider manifest based classpaths [SPR-13685] #18260 PathMatchingResourcePatternResolver does not consider manifest based classpaths
• PathMatchingResourcePatternResolver should enforce consistent alphabetical sorting of directory content [SPR-14085] #18657 PathMatchingResourcePatternResolver should enforce consistent alphabetical sorting of directory content

Referenced from: commits 4c96447

1 votes, 4 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

[spring-projects-issues]

Shabin S commented

The "org.springframework.core.io.support.PathMatchingResourcePatternResolver#doFindPathMatchingJarResources(Resource, String)" method still(4.2.4-RELEASE) does not close a Jar file that it opens if it gets it from a JarURLConnection directly. As mentioned in the main description, the reason that is given in the code as to why the Jar file is not closed from a JarURLConnection is because the JarURLConnection "might cache the file reference". However, "setUseCaches(true)" is called on the JarURLConnection instance only if con.getClass().getSimpleName().startsWith("JNLP") written inside ResourceUtils.useCachesIfNecessary(jarCon) method. So if the file is not cached in other cases, why is it not closed?
The newJarFile flag(which is used for checking whether to close the file or not) can be modified to set to true if jarCon.getUseCaches() is false so that the file will be closed if no caching is to be done.

[spring-projects-issues]

Juergen Hoeller commented

As of 4.3, we defensively close jar files from non-cached JarURLConnections. We'll see during the 4.3 release candidate whether that causes a regression in any common environment...

Juergen