United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6549428 Shortcut stops working if jnlp file changed on server while running single instance application
JDK-6549428 : Shortcut stops working if jnlp file changed on server while running single instance application

Details
Type:
Bug
Submit Date:
2007-04-24
Status:
Closed
Updated Date:
2010-11-04
Project Name:
JDK
Resolved Date:
2008-06-26
Component:
deploy
OS:
windows_xp
Sub-Component:
webstart
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6,6u1
Fixed Versions:
6u10 (b24)

Related Reports
Backport:
Relates:

Sub Tasks

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

cannot reproduce with 6u2 b02 or b03.  b02 can be downloaded from:
http://download.java.net/jdk6/binaries/
                                     
2007-06-01
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 ?
                                     
2007-06-11
SUGGESTED FIX

http://web-east.east.sun.com/deployment/www/webrevs/ngthomas/6549428/webrev/
                                     
2008-04-23
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/
                                     
2008-04-23



Hardware and Software, Engineered to Work Together