Regression: DLL handled as classpath resource [SPR-12928]

[spring-projects-issues]

Carlo Luib-Finetti opened SPR-12928 and commented

After migrating our Eclipse-based RCP-Client from Spring 2.5.6 (!) to the latest release 4.1.6 we met this strange error:

java.util.zip.ZipException: Exception in opening zip file: D:\uvdms\client\configuration\org.eclipse.osgi\bundles\101\1\.cp\lib\jacob-1.17-x86.dll

This jacob DLL comes into play as an entry in the MANIFEST.MF of one of out jars; it looks as this:

Bundle-NativeCode: lib/jacob-1.17-x86.dll

It seems that Spring treets it as classpath Jar, and the classloader tries to open it as Zip file.

---

Affects: 4.1.6

Issue Links:

• 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 should close jar file from JarURLConnection if not cached [SPR-6295] #10961 PathMatchingResourcePatternResolver should close jar file from JarURLConnection if not cached

Referenced from: commits 6a7aab0, 49f3046

[spring-projects-issues]

Juergen Hoeller commented

Does this stacktrace come out of the JarFile constructor as called by Spring's PathMatchingResourcePatternResolver?

We're generally only trying to open jar files that are being declared with a jar or zip prefix in the runtime classpath. I suppose Eclipse adds such an entry for that dll, derived from your manifest entry. If it does have a jar or zip prefix, it is an invalid classpath entry though. In any case, we're going to be more lenient there, ignoring jar entries that we can't open.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

This seems to be a consequence of #16711 where we started to evaluate classpath root entries in a more comprehensive way...

[spring-projects-issues]

Juergen Hoeller commented

I've added a corresponding try-catch block that silently skips such classpath entries that we fail to process as jar files.

Juergen

[spring-projects-issues]

Carlo Luib-Finetti commented

Hi Juergen,
in the meantime I helped myself with a workaround. In fact, the entry in MANIFEST.MF ("Bundle-NativeCode: lib/jacob-1.17-x86.dll") isn't needed, if the DLL can be found at runtime at the current directory or by system path entries. So I removed the statement from the manifest.
Just to give you the stacktrace and other hints, today I put the statement again into the manifest. But, to my very surprise, the problem didn't show up again! I don't know why.

Anyway, because we had this bundle classpath statement since a long time in the manifest, and because the error showed excactly when I did the upgrade to Spring 4.1 and the first runs of the application, I was sure Spring must be the culprit.