JDK-6576052 : Application Launch failed after Webstart driven JRE installation
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-07-02
  • Updated: 2011-02-16
  • Resolved: 2007-11-07
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 b07Fixed 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 :
Windows XP SP2

EXTRA RELEVANT SYSTEM CONFIGURATION :
Solars or Linux Server running Tomcat hosting an application, also hosting a webstart download/installer service as per JNLP specs.

Client Side is Windows XP or Win2K using webstart to run application, and using webstart extension download/installation process to manage JRE installations using the locally hosted installer service instead of Sun's

A DESCRIPTION OF THE PROBLEM :
In cases of WebStart 1.6 managing the installation of 1.6 jre of the same version, the installation stage succeeds but the WebStart 1.6 internal caches seem to get corrupt and the application cannot launch after the installation, throwing this exception, the 2nd attempt to same application will succeed ( The installer having successfully installed/claimed the extension, webstart will simply use it and the webstart driven installation is not launched )

This is the exception:
java.io.IOException: Cannot find cached resource for URL: http://myserver:8080/MyApplication/includes/App.jar
        at com.sun.deploy.net.DownloadEngine.getCachedResourceFilePath(Unknown Source)
        at com.sun.javaws.LaunchDownload.getSignedJNLPFile(Unknown Source)
        at com.sun.javaws.LaunchDownload.checkSignedLaunchDescHelper(Unknown Source)
        at com.sun.javaws.LaunchDownload.checkSignedLaunchDesc(Unknown Source)
        at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
        at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
        at com.sun.javaws.Launcher.launch(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)



STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) You will need a WebStart JRE installer, Custom or reuse Sun���s WebStart installer
The webstart installer should locate the exiting installed JRE and claim it, or use the same Sun jre-6u1 run it, and then claim the JRE using the webstart required method from the ���javax.jnlp.ExtensionInstallerService���  setJREInfo(String,String) method then following by the installSucceeded(false); method.

2) Launch the application which should have a <J2SE version=���1.6.0_01���
href=���http://myserver.com/InstallationService/j2se���>

You will hit the error

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Under java 1.5, multiple entries where possible in the deployment.properties for the same JRE, and webstart 1.5 installation process allowed. A WebStart driven JRE installation of any JRE packaging was possible.

  From the release notes, and some research I see that under 1.6 deployment configuration management has been rewritten.
So Under 1.6
There is only 1 entry for the JRE in the workstation���s deployment configuration (deployment.properties),
���	This limitation seems to be only imposed by webstart at JRE installation time
���	This limitation is not observed using the Java Control Panel
���	Something other than webstart can rewrite the deployment.properties, and has no problem with Multiple entries for a JRE
���	Nor when multiple entries are administratively added to the deployment configuration file. (Java Control panel rewrites the deployment configuration file, and does not impose the same limits as webstart ).

Launching the application which should have a <J2SE version=���1.6.0_01��� href=���http://myserver.com/InstallationService/j2se���>
Expected behaviour:

i.	WebStart will not find the installed JRE , (as it was already installed using Sun's installer, and the location was set to Sun's URL)
ii.	WebStart will launch the JRE installer as directed (regardless if is Sun���s installer or a custom one),
iii.	at the end of the JRE installation the application should launch
iv.	The deployment.properties will have a new entry set to ( deployment.javaws.jre.1.location= http://myserver.com/InstallationService/j2se )

ACTUAL -
As expected:
i.	WebStart will not find the JRE
ii.	WebStart will launch the JRE Installer as required
iii.	The JRE installer completes successfully, the deployment.properties is correctly updated. (deployment.javaws.jre.0.location= http://myserver.com/InstallationService/j2se)

iv.	WebStart proceeds to launch the application but fails with the exception mentioned in this bug report.
v.	The 2nd click to launch the same application again will succeed
vi.	The issue is after WebStarts uses a JRE installer that claims the same JRE, webstart gets its cache/runtime environment corrupted, and cannot continue to launch applications.

Potential Issues tested and dismissed: The application JNLP file is the same one, and there are no IO issues from the server to access any of the required resources spelled out in the JNLP file. All resources are statically hosted, no download service.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.io.IOException: Cannot find cached resource for URL: http://myserver:8080/MyApplication/includes/App.jar
        at com.sun.deploy.net.DownloadEngine.getCachedResourceFilePath(Unknown Source)
        at com.sun.javaws.LaunchDownload.getSignedJNLPFile(Unknown Source)
        at com.sun.javaws.LaunchDownload.checkSignedLaunchDescHelper(Unknown Source)
        at com.sun.javaws.LaunchDownload.checkSignedLaunchDesc(Unknown Source)
        at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
        at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
        at com.sun.javaws.Launcher.launch(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)



REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Switch application to use JRE 1.5)
WebStart 1.6 managing non 1.6 jre installations (WS 1.6 installing a 1.5 JRE), programmatically rewriting the deployment.properties will overcome the limitation, the rewrite has to be done after the webstart driven installation process. At application startup. Any attempt to rewrite the deployment.properties during the webstart driven installation process, will get overwritten at the end of the installation process by webstart from its runtime/cache

Its a compromise to use the application on JRE 1.5, but not a solution.

Comments
SUGGESTED FIX I think it would be beter to double launch in this case, by including your new jreInstalled variable to the test in line 634.
07-08-2007

SUGGESTED FIX webrev: http://web-east.east/deployment/www/webrevs/ngthomas/6576052/webrev/
07-08-2007

EVALUATION I can finally reproduce the bug after a few email exchange with the customer. Problem is the customer's own JRE installer is basically reclaiming the installed JRE, but setting it to a different href. Our code in Java 6 will only download application resource until we got a correct JRE, and relaunch. But we didn't handle the case that after the JRE installed, there is no relaunch needed, so we continue to launch and hit the exception as shown in the bug report. Simple fix is just to handle the case where JRE installer is invoked, and after that if no re-launch is necessary, download resources before we continue to launch in the current jre. Customer claimed this works in Java 5, but not in Java 6.
07-08-2007

EVALUATION I tried to host the JRE 6.0 auto-download installer on my own server, and have Java Web Start 6u2 on the client, and launch a jnlp application that requires 1.6.0, which will auto-dl 6.0 from my own server. It works without any problems. 6u2 Java Web Start will auto dl the JRE 6.0, installs it, and then launch the application with the JRE 6.0 installed. Will email customer for more information.
02-08-2007