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

Spring fails to load ressources via Java Network Launching Protocol (WebStart) since Java6 [SPR-6480] #11146

Closed
spring-projects-issues opened this issue Nov 30, 2009 · 5 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression)

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 30, 2009

Alexander Schäl opened SPR-6480 and commented

When started via Java6 WebStart, the Spring PathMatchingResourcePatternResolver tries to handle the URLConnection (wich is in a WebStart context actually an JNLPCachedJarURLConnection) just like a normal file URL. The PathMatchingResourcePatternResolver checks the resources only for a JarURLConnection, any other is handled as a path on the local file system.

So the resource request for "http://service.ACME.com:42/webstart/ressources.jar" (which would be propperly handled by the com.sun.jnlp.JNLPClassLoader) is crippled to "http:\service.ACME.com:42\webstart\ressources.jar", which of course can't be handled by any class loader and logically ends up in an FileNotFoundException due to the destroyed URL syntax.

A solution COULD be to extend the URLConnection type checking at the method doFindPathMatchingJarResources of org.springframework.core.io.support.PathMatchingResourcePatternResolver from JarURLConnection to an JNLPCachedJarURLConnection in order to treat this connection not as a "file:"

Java WebStart 5 used to cache all resources (especially the JAR files listed as resources in the JNLP file) on the local file system and the PathMatchingResourcePatternResolver could access these JAR files using a local path like "file://path/on/local/system". Java WebStart 6 has got another (obfuscated) cache structure - there are no longer any plain JAR files. That's why the JNLPClassLoader returns JNLPCachedJarURLConnection for any JAR resource instead of JarURLConnection like WebStart 5 did.


Affects: 2.5.6

Issue Links:

4 votes, 4 watchers

@spring-projects-issues
Copy link
Collaborator Author

Alexander Schäl commented

Thank you for assigning this issue to version 3.0.1! Since we are planing to finish our Java 6 upgrade project within the next months and I could not find a release date for Spring v3.0.1, I'd like to ask you for an estimated release date.

In case the release interval of one or two months from the last versions won't be fit for the 3.0.1, I furthermore would like to ask you, if a patch / hot fix for the web start issue could be provided.

yours sincerely
Alexander Schäl.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Actually, JNLPCachedJarURLConnection indirectly extends JarURLConnection, so PathMatchingResourcePatternResolver should actually treat it as a jar file: i.e. call the getJarFile() method and then the JarFile.entries() method. Where exactly is it failing there? Could you post the stacktrace please?

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Stephan Menzel commented

We were not able to reproduce the bug and
discovered that we were using a wrong test configuration.
Under these circumstances we would like to thank for your support. This issue can be closed.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

No problem - closing this as not reproducible then...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Feb 13, 2012

Tom Jahncke commented

I am running into some bean creating performance issues with Java 6, Spring 3.0.x and webstart, #13755. Any insight you might have to my issue would be greatly appreciated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression)
Projects
None yet
Development

No branches or pull requests

2 participants