JDK-4780676 : Java Web Start sometimes fails to launch applications while offline
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.2.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-11-18
  • Updated: 2002-11-26
  • Resolved: 2002-11-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.
Other
1.4.2 b09Fixed
Related Reports
Duplicate :  
Description

Name: nt126004			Date: 11/18/2002


FULL PRODUCT VERSION :
JRE 1.4.1 JWS 1.2

java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)


FULL OPERATING SYSTEM VERSION :

Windows 2000

ADDITIONAL OPERATING SYSTEMS :

Windows XP

I briefly tested on Sun 8 as well and the problem appeared
to be identical.


A DESCRIPTION OF THE PROBLEM :
There are multiple bugs and nuisances when a JNLP file is hosted
on a password protected server(basic authentication). 

I list in no particular order things I believe should be fixed and
I leave to you to prioritize and categorize them:

1. Every time the Java Web Start application manager is launched, one
logon and password requester is shown for *each* downloaded 
application. 

2. Every time a Java Web Start application hosted on a password
protected server is launched, a logon and password requester is
shown.

3. If you cancel requester #2 above, the application fails to launch.

More information on problem 3 above :
Sometimes I can no longer launch my application offline or
if I press cancel on the button which asks me for login or
password to check for a new update.

This is for a Java Web Start hosted on a password protected
server.

I worry that a similar problem exists for non-password
protected hosting on clients with dial up internet
connection.

It is a regression from Java Web Start 1.0.1, in that it
was possible to press cancel on the login/password
requester for checking for update and have the app launch
afterwards.

REGRESSION.  Last worked in version 1.0.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Either you can configure a server with password protected
hosting of a Java Web Start application, or you can
simulate the corrupt alxxx.jnlp file in the Java Web Start
cache as follows:


1. Modify the alxxx.jnlp file in the cache for any offline
application. Change the line with
_default.forcedUpdateCheck to:

_default.forcedUpdateCheck=true


2. Unplug your network cable.
3. Launch the app.
4. After a couple of seconds, you see Java Web Start
checking for a new version
5. You then get an error message when launching the app

An error occurred while launching/running the application.

Title: Silly app
Vendor: asdfasfsd
  Category: Download Error

Unable to load resource: http://famine/fun/fun.jnlp



EXPECTED VERSUS ACTUAL BEHAVIOR :
The app should have launched without any error message and
if it couldn't check for a newer version, then it should
have been silent about it.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
An error occurred while launching/running the application.

Title: Silly app
Vendor: asdfasfsd
  Category: Download Error

Unable to load resource: http://famine/fun/fun.jnlp

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
This is my "corrupt" alfun.jnlp file from the Java Web Start cache:

#LAP
#Wed Oct 23 16:21:03 CEST 2002
_default.locallyInstalled=true
_default.launchCount=11
windows.installedDesktopShortcut=C\:\\Documents and
Settings\\oyvind\\Desktop\\Silly app.lnk
_default.indirectPath=C\:\\Documents and
Settings\\oyvind\\.javaws\\cache\\indirect\\indirect11803.ind
_default.lastAccessed=Wed Oct 23 16\:21\:03 CEST 2002
_default.forcedUpdateCheck=true
windows.installedStartMenuShortcut=C\:\\Documents and Settings\\oyvind\\Start
Menu\\Programs\\Silly app.lnk
_default.askedInstall=true

---------- END SOURCE ----------
(Review ID: 166130) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-beta FIXED IN: mantis-beta INTEGRATED IN: mantis-b09 mantis-beta
31-08-2004

EVALUATION I will take each of the 3 points and address them seperately: 1.) This is clearly a bug in the Application manager. the CacheImageLoader starts a new thread to check for update of the icon shown. One authentication should be enough (The underlying bug here is a dupe of bug #4772298, wherein each threead requires a new passwd.) 2.) This is the expected behavior. Unless an application is run offline (by invoking javaws -offline ...), webstart will try to check for an update of any application before it is run. It must be able, at a minimum, to verify that the latest version of the jnlp file, and the correct version of all resources are cached, before launching. 3.) That the application is not launched in this case, is also the expected behavior. The user has canceled a check that is required for online launching. 4.) That this "cancel" could ever cause local Application properties value "forceUpdate" to become true is a bug. It turns out that when run online, if you get to the password check from Launcher$RapidUpdateCheck, and hit "cancel" RapidUpdateCheck will think it was modified (since length comes back -1, and is not same as in cache) 1.) and 4) need to be fixed for mantis, 2, and 3 are as should be. ###@###.### 2002-11-20
20-11-2002