P2
It seems that the JavaWebStart client in Mustang often fails to launch a local JNLP file. Investigated in detail in b57 but broken for a while now (do not know when it started). Not broken in JDK 5, so a Mustang regression.
How to reproduce (hope it works for you; sorry but this looks like a timing or other semirandom condition, so I do not know how to narrow down):
0. My environment: Fedora Core 4 Linux (all updates applied).
1. Install Mustang b57.
2. Download a NetBeans IDE development build, e.g.
http://www.netbeans.org/download/5_0/daily/200510261858/netbeans-5_0-daily-bin-200510261858-26_Oct_2005_1858.zip
should probably work as well as anything else. Just need a 5.0 build.
3. Unpack IDE to some dir on disk.
4. Run e.g. .../netbeans/bin/netbeans --jdkhome /path/to/mustang --userdir /tmp/testing
5. Select File -> New Project. Choose Samples -> NetBeans Plug-in Modules -> FeedReader. Set e.g. Project Location to /tmp and pick any free dir name for Project Name. Finish.
6. Delete ~/.java/deployment/ dir.
7. In Projects tab, right-click Feed Reader Application and choose Run JNLP Application.
8. Output Window should appear with some Ant output. A couple of minutes later, javaws should start. Accept the signature (it's a testing signature, not supposed to be valid). Application "Feed Reader Demo" should start. Use File -> Exit or just close the window to shut it down.
9. Now right-click Feed Reader Application and choose Clean All. Choose Run JNLP Application again. This time, early in the javaws startup sequence, the launch fails with a mysterious error. See attachment for screenshot, but here is the meat of it:
Error: Unable to load resource file:/tmp/feedreader-suite2/dist/jnlp/local/app/jdom.jar
JNLPException[category: Download Error : Exception null : LaunchDesc : null ]
at com.sun.javaws.LaunchDownload.downloadJarFiles(LaunchDownload.java:848)
at com.sun.javaws.LaunchDownload.downloadEagerorAll(LaunchDownload.java:749)
at com.sun.javaws.Launcher.downloadResources(LaunchDownload.java:1066)
[etc.]
Some observations:
- JDK 5.0u5 does not suffer from this problem.
- The exact JAR on which it claims to fail differs each time. It seems to randomly fail on one of the JARs in the application.
- It does not seem to fail if the ~/.java/deployment directory was deleted immediately before running javaws.
- On subsequent runs (with an existing deployment cache dir), it will often fail repeatedly. But sometimes, apparently at random, it begins working, and then continues to work - until you do a clean build (regenerate and resign the JARs).
So it looks like some sort of problem with corruption of the cache under some conditions. Whatever the cause, the error reporting from javaws is terrible in this case. If it cannot provide a more detailed error message, it should at least suggest that you clean out your cache, or try to repair itself somehow.
Looking at (somewhat old) sources for LaunchDownload.java, it appears that the test which is failing is
if (Cache.isCacheEnabled() && cacheFileURL == null) {...}
meaning perhaps that DownloadEngine.getResource(...) returned null. Shouldn't this method throw an exception with a description of the problem instead?
In DownloadEngine.getResourceCacheEntry(...) I do see the worrisome comment:
if (doDownload) {...} else {
// TODO: download to cache temp directory (offline support?)
}
How to reproduce (hope it works for you; sorry but this looks like a timing or other semirandom condition, so I do not know how to narrow down):
0. My environment: Fedora Core 4 Linux (all updates applied).
1. Install Mustang b57.
2. Download a NetBeans IDE development build, e.g.
http://www.netbeans.org/download/5_0/daily/200510261858/netbeans-5_0-daily-bin-200510261858-26_Oct_2005_1858.zip
should probably work as well as anything else. Just need a 5.0 build.
3. Unpack IDE to some dir on disk.
4. Run e.g. .../netbeans/bin/netbeans --jdkhome /path/to/mustang --userdir /tmp/testing
5. Select File -> New Project. Choose Samples -> NetBeans Plug-in Modules -> FeedReader. Set e.g. Project Location to /tmp and pick any free dir name for Project Name. Finish.
6. Delete ~/.java/deployment/ dir.
7. In Projects tab, right-click Feed Reader Application and choose Run JNLP Application.
8. Output Window should appear with some Ant output. A couple of minutes later, javaws should start. Accept the signature (it's a testing signature, not supposed to be valid). Application "Feed Reader Demo" should start. Use File -> Exit or just close the window to shut it down.
9. Now right-click Feed Reader Application and choose Clean All. Choose Run JNLP Application again. This time, early in the javaws startup sequence, the launch fails with a mysterious error. See attachment for screenshot, but here is the meat of it:
Error: Unable to load resource file:/tmp/feedreader-suite2/dist/jnlp/local/app/jdom.jar
JNLPException[category: Download Error : Exception null : LaunchDesc : null ]
at com.sun.javaws.LaunchDownload.downloadJarFiles(LaunchDownload.java:848)
at com.sun.javaws.LaunchDownload.downloadEagerorAll(LaunchDownload.java:749)
at com.sun.javaws.Launcher.downloadResources(LaunchDownload.java:1066)
[etc.]
Some observations:
- JDK 5.0u5 does not suffer from this problem.
- The exact JAR on which it claims to fail differs each time. It seems to randomly fail on one of the JARs in the application.
- It does not seem to fail if the ~/.java/deployment directory was deleted immediately before running javaws.
- On subsequent runs (with an existing deployment cache dir), it will often fail repeatedly. But sometimes, apparently at random, it begins working, and then continues to work - until you do a clean build (regenerate and resign the JARs).
So it looks like some sort of problem with corruption of the cache under some conditions. Whatever the cause, the error reporting from javaws is terrible in this case. If it cannot provide a more detailed error message, it should at least suggest that you clean out your cache, or try to repair itself somehow.
Looking at (somewhat old) sources for LaunchDownload.java, it appears that the test which is failing is
if (Cache.isCacheEnabled() && cacheFileURL == null) {...}
meaning perhaps that DownloadEngine.getResource(...) returned null. Shouldn't this method throw an exception with a description of the problem instead?
In DownloadEngine.getResourceCacheEntry(...) I do see the worrisome comment:
if (doDownload) {...} else {
// TODO: download to cache temp directory (offline support?)
}