JDK-6536780 : WebStart seems to be trying to open the old (deleted) .jnlp file after updating.
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2007-03-21
  • Updated: 2011-02-16
  • Resolved: 2007-03-28
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode)

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

A DESCRIPTION OF THE PROBLEM :
I get the following exception thrown whenever webstart updates a locally cached .jnlp file:

CouldNotLoadArgumentException[ Could not load file/URL specified: C:\Documents and Settings\keith\Application Data\Sun\Java\Deployment\cache\6.0\49\7c1f76b1-7a84d732]
	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)

The wrapped exception is:

java.io.FileNotFoundException: C:\Documents and Settings\keith\Application Data\Sun\Java\Deployment\cache\6.0\49\7c1f76b1-7a84d732 (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)


The file name specified existed before the application was launched.  However, by the time the exception is thrown, it has been deleted and replaced by a newer version with a different name.

This sounds like bug #6446676, which was supposedly fixed in Mustang(b94).  However, I'm still seeing it in b105.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This happens every time a new copy of a locally cached .jnlp file is downloaded to the client.  Since we're dynamically building the .jnlp file on the server, this happens every time (other than the 1st time) the application is launched.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expect webstart to use the new file that it just saved rather than the old file it just deleted.
ACTUAL -
Webstart throws the exception on every invocation after the first one.
Even though our application requires 1.5, our customers are starting to see this error as soon as they install 1.6 on their desktop since the newly installed 1.6 will handle the initial .jnlp file.

So, simply installing 1.6 on a client breaks existing 1.5 production applications.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Dialog stating "Application Error" "Unable to launch the application" with the previously mentioned exceptions.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Either: (1) uninstall 1.6 so that 1.5 handles the ,jnlp file; (2) manually run the application in offline mode; or (3) delete it locally before launching.

Since our customers are accustomed to clicking a link on a web page to launch our application, neither of workarounds (2) or (3) is going over very well.

Release Regression From : 5.0
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION since the issue of relaunching with incorrect cached jnlp file path is already fixed in 6u2, the only remaining issue is native parser cannot parse non utf-8 jnlp file. closing this bug as dup of: 6537987: improve javaws.exe native parser
28-03-2007

EVALUATION our native code will not parse the jnlp file, unless the encoding for the jnlp is in utf-8. this has been the case since 1.4.2. since the customer jnlp file uses a customzie heap size and it uses the iso-8859-1, a relaunch will be required.
28-03-2007

EVALUATION the problem of relaunching with wrong path to cached jnlp is fixed in 6u2, as a side effect of bug fix for 6511789, where we improved the initial jnlp file downloading code. bug cannot be reproduced by latest 6u2 build.
23-03-2007

EVALUATION the very first line in the jnlp file: <?xml version="1.0" encoding="ISO-8859-1"?> seems to cause our native launcher fail to parse the JNLP file correctly, causing a relaunch later. if changed to <?xml version="1.0" encoding="utf-8"?> seems to work fine and no re-launch is needed.
23-03-2007

EVALUATION I can reproduce the problem using customer's application. Problem is when we do a relaunch of JRE 1.5, we passed in the old(deleted) jnlp as argument, causing the issue. A bug in 1.6 Java Web Start.
22-03-2007

EVALUATION cannot reproduce the problem. emailed customer for more information.
22-03-2007