JDK-6921609 : regression: JWS does not update desktop shortcut following JNLP update with 6u18 release
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u10,6u16,6u18
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    windows_2003,windows_xp,windows_vista windows_2003,windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2010-02-01
  • Updated: 2011-02-16
  • Resolved: 2010-03-04
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
6u18-revFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Description
FULL PRODUCT VERSION :
1.6.0_18-b07

ADDITIONAL OS VERSION INFORMATION :
Windows XP, Windows Vista, and Windows 7 using IE and Firefox browsers

A DESCRIPTION OF THE PROBLEM :
When an updated JWS app is launched from the desktop jnlp shortcut, the shortcut is not updated to the new jnlp cache location.

If the JNLP includes the security/all-permissions element, the outdated jnlp entry will be deleted (upon close of the application / exit of the VM). The next launch of the application from the desktop link returns the following exception since the cache entry for the outdated jnlp has been deleted and the shortcut was not updated.

CouldNotLoadArgumentException[ Could not load file/URL specified: C:\Documents and Settings\troy\Application Data\Sun\Java\Deployment\cache\6.0\33\2efbeba1-5823be8f]
	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)

If the JNLP does not contain the security/all-permissions element, the subsequent launches of the app from the desktop link following an update will not fail but will incorrectly use the outdated version of the JNLP.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I've posted the Sun Notepad app to our production servers to provide a simple illustration.

Here are the steps we've found to replicate the issue on Windows XP, Vista, and Windows 7 using both IE and Firefox:

1) Download the sample JWS application and allow the desktop link to be created - http://www.planwithvoyant.com/voyant/launch/notepadAllPerm

2) Inspect the desktop shortcut and notice the path to the JNLP cache entry

3) Modify the JNLP at the server. The following url updates the Last-Modified header for the sample Notepad app JNLP - http://www.planwithvoyant.com/voyant/launch/setLastModified

4) Run the application via the desktop link again- at this point the application will download updates and execute without issues.

5) Close the application - upon close, JWS will remove the old JNLP cache entry if the JNLP contained the security/all-permissions directive.

6) Inspect the desktop shortcut again - notice that the path to the JNLP cache entry will remain unchanged

7) Launch the application again using the desktop link - JWS will fail with a cache exception

I've also included a version the Notepad app JNLP which does not request the security/all-permissions - http://www.planwithvoyant.com/voyant/launch/notepad.

Following the same steps, you'll notice that the desktop link doesn't fail in this case. However, the app does launch with the outdated JNLP.... a potentially worse scenario depending up the application.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -

Expected the desktop shortcut link to be updated to the new jnlp cache entry
ACTUAL -

Desktop shortcut is not updated and thus subsequent invocations of the shortcut either fail with a "Could not load file/URL specified" exception or successfully launch the application using the outdated JNLP.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
CouldNotLoadArgumentException[ Could not load file/URL specified: C:\Documents and Settings\troy\Application Data\Sun\Java\Deployment\cache\6.0\33\2efbeba1-5823be8f]
	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)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

Sample Notepad app hosted at  http://www.planwithvoyant.com/voyant/launch/notepadAllPerm

See steps to reproduce above.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :

The desktop shortcut is corrected if the application is launched from the browser using the original jnlp url/link.


This is not a viable workaround as there's no mechanism in JWS to provide a message to the user upon failure of the desktop shortcut.

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

Comments
SUGGESTED FIX http://web-east.east.sun.com/deployment/www/webrevs/ngthomas/6921609/webrev/
05-02-2010

EVALUATION Problem was a mistake when we change signature of Launcher.notifyLocalInstallHandler: we passed in false as value of isUpdated, causing no shortcut update when there should be one.
04-02-2010