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 :
 customer  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.
Posted Date : 2006-07-06 13:08:36.0

N/A

I tried to reproduce the problem but failed.  Emailed the original submitter for more information.
Posted Date : 2006-07-11 01:13:49.0

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.
Posted Date : 2006-07-17 23:46:07.0

I am still seeing this behavior on Java 1.6.0-b105 (March 2007).

I'm also seeing this behavior on Java 1.6.0-b105.

I am seeing this in 1.6.0_01-b06.  When do you expect to have a fix for this?  Does Sun understand how big of a deal this is?

I am also seeing this in 1.6.0_01. Java autoupdate "on" by default is a nightmare for inhouse deployers ! All was going well in 1.5+ ! I am about to replace JWS by a .bat solution. Not very sexy, but rock solid.

Is there a work around for this defect?

Is there a workaround solution for 6453535 or related to this defect, please give some pointers please.

I have a critical situation where my build and packaging environment is java 1.5.1 (i use pack200,signtool of 1.5.1), whereas the client (end-user) system has java 1.6 automatic update, Causes java webstart to fail to launch with my pack.gz. files.

There is hope:, see:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6549428

I filed a new bug report, as this clearly is not fixed. Not yet visible though. Stay tuned.

See bug 6563938.

REPOST: I originally posted this comment on bug 6549428 - I'm reposting it here for the sake of others:

We've found two other reproduceable situations in which the shortcut stops working (points to a cached version that no longer exists): 

1) Click the 'cancel' button at just the right time while the app is updating.

2) Simulate a network error (i.e. yank the network cable out of the back of your machine) while an app is updating,

We’ve reproduced this bug in yet another situation with 1.6.0_3 and both Windows XP and Vista.

In this case, we receive the error by simply renaming the desktop shortcut. After renaming the shortcut, the first launch/update works fine. The second launch attempt fails with a “CouldNotLoadArgumentException” as detailed in the bug report above.

This bug should be re-opened.

This still occurs Nov 2007.