JDK-6549428 : Shortcut stops working if jnlp file changed on server while running single instance application
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6,6u1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-04-24
  • Updated: 2010-11-04
  • Resolved: 2008-06-26
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 JDK 7
6u10 b24Fixed 7Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

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

A DESCRIPTION OF THE PROBLEM :
Shortcut stops working if jnkp file of a signed jar changed on server.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Sign a Java application.
2. Install a Java Webstart deployed software via its online jnlp, making sure the jnlp file contains:
 <offline-allowed />
     <shortcut>
      <desktop/>
    </shortcut>

3. Allow the install of the shortcut.
4. Change something in the jnlp file. ie. Change SEVERE to WARNING in demo JNLP.
5. Try to run the application with the shortcut.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Exp. result: the application starts.
ACTUAL -
Act. result: an error message appears: Unable to launch the application

ERROR MESSAGES/STACK TRACES THAT OCCUR :
CouldNotLoadArgumentException[ Could not load file/URL specified: C:\Documents and Settings\John\Application Data\Sun\Java\Deployment\cache\6.0\34\38fa84a2-422f80a7]
	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 ----------
<?xml version="1.0" encoding="ISO-8859-2"?>
<jnlp spec="1.0+" codebase="http://example.com" href="myapp.jnlp">

  <information>
     <title>Title</title>
     <vendor>Vendor</vendor>
     <homepage href="index.html" />
     <description>Description</description>
     <offline-allowed />
     <shortcut>
      <desktop/>
      <menu submenu="My Application"/>
    </shortcut>
   </information>

  <resources>
     <j2se max-heap-size="128M" version="1.5+" 
href="http://java.sun.com/products/autodl/j2se"/>
     <jar href="myapp.jar" main="true" />

<property name="myapp.log.level" value="SEVERE"/>
</resources>

  <application-desc main-class="MyApp"/>

  <security>
     <all-permissions/>
  </security>

</jnlp>
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Uninstall the application and install again.
Same issue reported by a CAP member:

Encountered a problem with their deployments with Sprint and Electronic Arts that happens with the latest Java 6 JRE.  Both accounts are using the desktop icon shortcut to launch their respective applications, and both are encountering this bug -- which renders their desktop icons non-functional with cryptic user-visible error messages.
the CAP member can still reliably reproduce it on the early access release, and so can some of 
the other users 
based on the comments.  Attached is their a reproducible test case:

http://content.mpowerplayer.com/hosting/java.com/

Comments
EVALUATION Problem: Shortcut stops working if jnlp file changed on server while running single instance application two issues shown by the customer's application: 1. if another instance of a single instance application is started and we need to go to the java code, we should not update the cached jnlp. instead, as soon as we got a LaunchDesc, we should check if another instance of the application is running, and signal and exit if necessary. 2. launching of the second instance via jnlp file directly should not launch java at all. the native code should be able to signal the current running instance already. problem here is the customer's jnlp file uses multiple resources element, and main=true is not specified. our native code fail to read the correct resources element to find out the first jar as main jar. Fix: 1. check for single instance as soon as we have a LaunchDesc 2. native code should process the valid resources element to find out the main jar testcase: http://web-east.east.sun.com/deployment/www/tests/1.6.0_10/6549428/
23-04-2008

SUGGESTED FIX http://web-east.east.sun.com/deployment/www/webrevs/ngthomas/6549428/webrev/
23-04-2008

EVALUATION i can reproduce the problem with customer's test case. customer's jnlp application is using single instance service, and registered as a single instance application. if you just close the application window, the instance won't go away, and now if you click on a different jnlp file, the single instance code will bring up the application using the running jvm again, but also it will update the cached jnlp, but not the desktop shortcut. problem only exists for single instance application. normal jnlp application does not have the problem. need to investigate 2 things: 1. why the incoming new instance will go into the java code ? the native code should be able to detect the single instance too, so it should not get into the java code at all. 2. for the case it needs to get to the java code, if we are still running the same instance, we should not update the cached jnlp file ?
11-06-2007

EVALUATION cannot reproduce with 6u2 b02 or b03. b02 can be downloaded from: http://download.java.net/jdk6/binaries/
01-06-2007