File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JNLP and Web Start and the fly likes WebStart auto-update doesn't always work properly Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JNLP and Web Start
Bookmark "WebStart auto-update doesn Watch "WebStart auto-update doesn New topic
Author

WebStart auto-update doesn't always work properly

Peter Taucher
Ranch Hand

Joined: Nov 18, 2006
Posts: 174
Hi guys!

I'm experiencing weird problems with the auto-update feature of Java WebStart. I'm testing the behaviour on my local Tomcat where I'm deploying first an old version of the application (1.0.0), starting the application via JNLP URL and then deploying the new version of the application (1.0.1-RC) and starting the application yet again.

It seems that the auto-update doesn't always work properly. When starting the application from the desktop shortcut the update and verification seems to always take place correct. But when starting the application via JNLP URL (provided from deployed web application) there's mostly no update / verification and the application starts with the 'old' version from the WebStart cache. I'm thoroughly sticking to the steps to test this behaviour:

1) Clear applications / applets / protocols from Java Control Panel
2) Deploy 'old' WAR in local Tomcat
3) Start application from JNLP URL (via deployed webapp)
4) Undeploy 'old' WAR from local Tomcat
5) Deplay 'new' War in local Tomcat
6.a) Start application from JNLP URL (via deployed webapp)
6.b) Start application from JNLP URL (via Start -> Execute)
6.c) Start application from desktop shortcut (created on first execution of 'old' application)

So in case '6.c' there seem to be no problems, but in cases '6.a' and '6.b' the update / verification sometimes doesn't take place. Here's some excerpt from the two versions of the JNLP file provided:




So the difference is the <update> element and the new <resources> element for 64bit systems. The version of the main <jar> differ ... so in my opinion there should be an update. Or am I wrong?

I'd really appreciate any comment, because I can't think of any cause / reason ... so finding a solution isn't easy ; - ) Please nudge me in the right direction. Thanks in advance!


Censorship is the younger of two shameful sisters, the older one bears the name inquisition.
-- Johann Nepomuk Nestroy
Peter Taucher
Ranch Hand

Joined: Nov 18, 2006
Posts: 174
Any notion / hint / something?
Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 9990
    
    7

(Just thinking out loud here)
When you deploy the new war
1) Navigate to the tomcat exploded folder under webapps
2) Ensure the jnlp file existing is really the new one
3) Ensure the browser is refreshed after war redeployment
4) Download the jnlp file to your local disk and ensure it is the new one.

As you might have guessed, I am wondering if it is some caching issue on the tomcat/browser side.


[How to ask questions] [Donate a pint, save a life!] [Onff-turn it on!]
Peter Taucher
Ranch Hand

Joined: Nov 18, 2006
Posts: 174
Thanks for the reply. I already did inspected the actual JNLP file provided by the browser and it had the correct version. Maybe I'm just paranoid because I couldn't recreate the behaviour on friday. I used following script to deploy / start the applciation:


Of course, the WS uninstall isn't executed for the 'new' version of the application but only for the 'old' one. In any case, the misbehaviour never occured (in about 35 test runs). So maybe it really was only some browser cache issue...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: WebStart auto-update doesn't always work properly
 
Similar Threads
Security Error
JNLP and Jar versions
Two applications One jnlp file
Do jnlp file updates itself
security exception thrown will running application