Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-issuemaster opened this issue Apr 17, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Apr 17, 2015

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:

  • #16711 PathMatchingResourcePatternResolver cannot search for "classpath*" patterns in a jar file roots
  • #10961 PathMatchingResourcePatternResolver should close jar file from JarURLConnection if not cached

Referenced from: commits 6a7aab0, 49f3046

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 24, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 24, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 24, 2015

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-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 27, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.