JDK-6446676 : JWS can't find the cache file for the application when trying to upgrade
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: solaris_11,6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: generic,x86
  • Submitted: 2006-07-06
  • Updated: 2011-02-16
  • Resolved: 2006-08-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b94Fixed
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) SE Runtime Environment (build 1.6.0-rc-b87)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b87, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
When upgrading the JNLP application on the server JWS corectly detects that an update is waiting. It performs the download and then presents me with a typical application error box (very user unfriendly BTW), this is the wrapped exception:
java.io.FileNotFoundException: C:\Documents and Settings\Shai Almog\Application Data\Sun\Java\Deployment\cache\6.0\19\25c064d3-5077faf2 (The system cannot find the file specified)
	at java.io.FileInputStream.open(Native Method)
	at java.io.FileInputStream.<init>(Unknown Source)
	at java.io.FileInputStream.<init>(Unknown Source)
	at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
	at com.sun.javaws.Main.launchApp(Unknown Source)
	at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
	at com.sun.javaws.Main$1.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Which obviously means JWS can't find the file it tried to store.

This is the regular exception:
CouldNotLoadArgumentException[ Could not load file/URL specified: C:\Documents and Settings\Shai Almog\Application Data\Sun\Java\Deployment\cache\6.0\19\25c064d3-5077faf2]
	at com.sun.javaws.Main.launchApp(Unknown Source)
	at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
	at com.sun.javaws.Main$1.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This happens every time I upgrade my application on our server, this happens on my development machine so I can't verify whether something is broken in my own installation. BUT THIS IS STILL A BUG! JWS should be robust enough to deal with a broken installation and should at the VERY MINIMUM detail what is going on and how this should be fixed! Many people have multiple versions of the JDK on their machine and this sort of failure is very likely.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Application should run correctly. And failing to do so provide a user friendly error dialog that provides actual details of what went wrong or better yet fix the users installation for him (i.e. the cache directory).
ACTUAL -
Users might think my application is broken since even the error message blames my application rather than JWS which is really whats broken!

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Application Error
Unable to launch application

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Uninstall the application and try to install it via JNLP (uninstall is required you can't just click the JNLP), this works. Its just updating that fails.

Comments
SUGGESTED FIX http://web-east.east/deployment/www/webrevs/ngthomas/6446676/webrev/
18-07-2006

EVALUATION I can reproduce the problem locally now. Two problem discovered in this bug: 1. Bug in native javaws.exe xml parser. In xmlparser.c, function SkipXMLDocType, we failed to skip the close bracket ">". This cause problem to jnlp file that contains the DOCTYPE xml header, and our native launcher cannot parse that file at all. So if the jnlp file contains jvm arguments, we will always relaunch when we get to the java code and can parse the jnlp file correctly. 2. If there is an jnlp file update, we update the cached jnlp file before doing a relaunch. If a shortcut for the application already exists, the shortcut won't be updated and will point to the old cached jnlp file location, which does not exist anymore.
17-07-2006

EVALUATION I tried to reproduce the problem but failed. Emailed the original submitter for more information.
11-07-2006