When a JAR file specified in a .jnlp file resides on a web server, javaws will attempt to download it. However, if the URL for the JAR file is HTTPS, and javaws cannot verify the SSL certificate of the server, javaws silently fails to download the JAR file. javawa then dies due to an "error in opening zip file": $ javaws jnlpgenerator-16 netx: Launch Error: Could not launch JNLP file. (java.util.zip.ZipException error in opening zip file) net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file. at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:372) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600) Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:131) at java.util.jar.JarFile.<init>(JarFile.java:150) at java.util.jar.JarFile.<init>(JarFile.java:114) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:345) ... 1 more Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:131) at java.util.jar.JarFile.<init>(JarFile.java:150) at java.util.jar.JarFile.<init>(JarFile.java:114) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:345) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600) But this is deceptive, because the "error" in opening the ZIP file is that the ZIP (JAR) file was never actually downloaded! If I manually download the JAR file in question, and place it in the netx cache directory, javaws dies with a different error: $ javaws jnlpgenerator-16 netx: Launch Error: Could not launch JNLP file. (java.lang.NullPointerException null) net.sourceforge.jnlp.LaunchException: Fatal: Launch Error: Could not launch JNLP file. at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:372) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600) Caused by: java.lang.NullPointerException at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:358) ... 1 more Caused by: java.lang.NullPointerException at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:358) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:600) But, again, this is a result of javaws balking at the SSL certificate that the server presents. If I hand-edit the .jnlp file and change all instances of "https:" to "http:", and ensure the server supports both HTTP and HTTPS, then javaws launches and runs perfectly. If I launch the .jnlp file using Sun Java's javaws, it warns me (via a pop-up window) that it can't validate the certificate, and asks me whether I want to accept it. I think OpenJDK's javaws should do the same thing.
can you test this with the version in rawhide? the zip error should be fixed.
The version in Rawhide (java-1.6.0-openjdk-1.6.0.0-8.b14.fc11) behaves exactly the same way.
thanks. do you have a test case?
Not a public one, no. (The application we're having difficulty running is the Sun ILOM Remote Console application, which connects to the management interfaces on our Sun servers.) However, if you could point me at some sort of lightweight JNLP demo application, I could build you a test case (by downloading it and putting it on a misconfigured HTTPS server). Do you know of anything that would fit the bill?
I believe that I may be seeing this as well (bug 502225), and I can provide a test case (not a public one, but I can provide a hostname and login info privately if there's any chance of getting this fixed).
I have fixed this upstream. It will be there in the next OpenJDK update in F10 (tentatively scheduled 1-2 weeks from now).
java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-18.b16.fc10
java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/java-1.6.0-openjdk-1.6.0.0-22.b16.fc11
java-1.6.0-openjdk-1.6.0.0-22.b16.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
java-1.6.0-openjdk-1.6.0.0-18.b16.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 502225 has been marked as a duplicate of this bug. ***
I just wanted to note that, once I work around bug 507870, I find that the the problem persists with java-1.6.0-openjdk-1.6.0.0-22.b16.fc11.x86_64. The backtrace is unchanged from the one in the original comment. Again, if there's any assistance I can provide, please let me know. I can privately provide access to the failing application.
same problem on both x86_64 and i586. test case here: http://www.geogebra.org/webstart/geogebra.jnlp java-1.6.0-openjdk-1.6.0.0-27.b16.fc11.x86_64 i removed ~/.netx and ~/.netxrc
Hello, I have the same problem with OpenJdk IcedTea6 1.7.4 rhel-1.21.b17.el6-x86_64. In fact, I can't use SSL communication when launching javaws application. No explicit error is shown. The same application can be launched with Sun JDK 1.6.0_30. Thank you,
(In reply to comment #14) > Hello, > > I have the same problem with OpenJdk IcedTea6 1.7.4 rhel-1.21.b17.el6-x86_64. > In fact, I can't use SSL communication when launching javaws application. > No explicit error is shown. > The same application can be launched with Sun JDK 1.6.0_30. > > Thank you, Hi Nadia, IcedTea6 1.7.4 is no longer supported upstream. The latest version of IcedTea6 in RHEL is 1.10.x and icedtea-web is at 1.1.x. Please upgrade to those -- this should be fixed there.