JDK-6189106 : Java Web Start jnlp file caching problem.
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.4.2,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,windows_2000
  • CPU: x86
  • Submitted: 2004-11-01
  • Updated: 2010-04-04
  • Resolved: 2005-01-19
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 JDK 6
5.0u3Fixed 6 b20Fixed
Description
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Microsoft WIndows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Webstart seems to keep using the old jnlp file after the first time it encounters a problem with a bad href in the jnlp file. After fixing the href in the jnlp file on the webserver, webstart keeps using the old cached jnlp file no matter what I do. The only way to resolve the problem is to uninstall the webstart application from using the java control panel.

I understand how this can happen when launching the app from the desktop icon. Basically, the app can't get the updated jnlp file without using the href in the old jnlp file (check and egg problem).

However, this should not happen when I launch the application from the browser, but it does. I turned off all browser caching and even set the applciation/jnlp to not allow offline or desktop/shortcut support and it still happens. When launched from the browser, the browser is passing to webstart a new and proper jnlp file, but webstart still trys to use its old jnlp file and ingnores the one passed in by the browser. This is busted and needs fixing. If the site administrator make a mistake one time, every user will need to delete their jnlp cache before they could get the app to work again. This is not good when you have hundred or thousands of desktop users.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a webstart application and put its jnlp file on a webserver. Request the jnlp file from the desktop and run the webstart application. Now go to the webserver and modify the "href" attribute in the jnlp file to be something that is "wrong". Of course now when you run the webstart app from the desktop it will tell you that there is a problem with the jnlp file and it will not start. Now fix the "href" in the jnlp file on the webserver and try to start the application again. The application will give the same error and will reference the old bad jnlp file whether you launch it from the desktop webstart icon or from an IE browser.

The only way to fix the problem is for the desktop user to uninstall the webstart application.


REPRODUCIBILITY :
This bug can be reproduced always.
###@###.### 11/1/04 23:23 GMT
Comments
EVALUATION we incorrectly assume a cached jnlp file is "beter" than one passed in. This would be the case if A -> B - B would be in cache when A is passed in. But this is not the case if A -> B (and B dosn't exist), and new A' is passed in. in this case A'->A', and gets hung on old B. ###@###.### 2004-11-05 19:52:31 GMT This is bad in the case given, where the JNLP file has an href, but for jnlp files w/o an href, the problem is worse. When clicking on an updated jnlp file from web browser, the new jnlp file is downloaded, the corrisponding (un-updated) one in the cache is used, since there is no href, java web start cannot try to download it again, so the application will be run with the old, unupdated one from the cache. Any changes to the jnlp file on the web are never cached or used. ###@###.### 2004-11-10 14:26:26 GMT Sorry - re-test shows this is not true. When a jnlp file w/o an href is run from the web, the downloaded jnlp file replaces the jnlp file in the cache every time. ###@###.### 2004-11-10 14:59:35 GMT Problem is we were always taking the jnlp file from the cache, when a different one was passed in. This only matters if the href is different, which it can be if the app uses a query string, or if the href was originally bad and later fixed. We will now put the new jnlp file into the cache if it is different (if it was the same, it may already be in the system cache, so we don't want to add another copy in the user cache) ###@###.### 2005-1-04 20:53:50 GMT
05-11-2004