Skip to main content

Webstart JAR updates are completely broken in 6u14

3 replies [Last post]
soltesza
Offline
Joined: 2009-04-17

Guys,

I just bumped into a seemingly horrible Webstart issue.

The report I sent to Sun is below. Let me know if you have a workaround.

I hope I am wrong and the problem is in my environment but I don't think this is the case because earlier JREs still do the job right.

--------------------------------------------------
A DESCRIPTION OF THE PROBLEM :

With JRE 6u14, my Webstart application installation works but JARs updated on the server are not downloaded (ignored completely) so the client application is not updated. The application is simply started with the old JARs without warnings or any sign of the problem.

My Webstart application's JNLP uses the following update settings:

This means that all resources should always be checked before the application starts and if a JAR is updated on the server (it has a newer timestamp), the JAR should be downloaded and placed in the cache. I have tried the timeout setting as well but it doesn't work either.

The JARs in question are referenced by a JNLP Component which is embedded into a JNLP Application file. This should make no difference compared to a JAR directly referenced by a JNLP Application descriptor.

Currently, in JRE 6u14, this seems to be completely broken. Webstart doesn't notice the updated JAR on the server and it doesn't download it.

As a safety-check, I installed JRE 6u11 onto an other Windows machine and tested the behaviour from the same Webstart web server.

JRE 6u11 works as expected. If I update the JAR on the web server and restart the application, Webstart immediately notices the new JAR and downloads it. This proves that there is no timestamp problem on the web server.

I checked the timestamps on the web server manually and they are correct. The webstart client and the server practically doesn't have any time difference (both are attached to internet time servers).

FULL JAVA VERSION :
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)

OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
Also reproduced on Ubuntu Linux 9.04 Jaunty

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Any webstart application should be possible to use for reproduction:

- Make sure the JNLP has proper update settings (always)
- Install the webstart app, close it
- Update one of the JARs on the server, check that the timestamp is newer
- Start the previously installed webstart app

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Webstart should download the updated JAR
ACTUAL -
No download happens, Webstart starts the application with the OLD JAR

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
No workaround, practically makes Webstart unusable.

I have no idea how this bug made it to u14, there should be an automatic test case for this.

Please, Sun, fix this bug because all of the already installed Webstart applications are now frozen, it is impossible to update them on the client (if the user installs u14 but this can happen easily with JRE updates).

We have a lot of clients using our Webstart applications and some of them installed JRE 6u14 (a growing number).

------------------------------------------------------

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
soltesza
Offline
Joined: 2009-04-17

I seem to have found a partial workaround for this problem until it gets resolved.

Change the name of the Component JNLP file on the server (e.g. put a version number postfix in the name) and correspondingly change the href in the Application JNLP's extension tag.

This triggers Webstart to re-check the component when the application starts next time and downloads the updated JARs of the component.

This is painful because you will need to rename the component JNLP and correct the referencing application JNLPs every time you update a JAR in the component but at least enforces updates on the component.

manish22786
Offline
Joined: 2010-01-07

Hello,

I am in to similar issue and I am not sure if its related but may be you could help

Heres our setup.

We have a file share ; The jnlp , the jars are all housed in the shared file server. (Not a web server to be clear)

There are about 15- 20 clients accessing this application using Java Web start.

If the client PC has a Java 6u14 version and is running.and now I update the jars on the share - the client breaks. I have to restart it to get it working. I believe the client should have be running from the cache and the update effect would not have taken place till i restart it. My Update tag is

However this works fine in earlier versions of Java 1.5.0-X, which is how it should be. This makes us dependent on version of Java which is bad.

Thanks
Manish

soltesza
Offline
Joined: 2009-04-17

It seems that only JARs embedded in JNLP components are affected, JARs directly referenced from the application JNLP are updated normally.

This is still a pretty big problem because for different reasons, a lot of applications need to use JNLP components (referenced as extension from the application JNLP).