Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

WebStart auto-update doesn't always work properly

 
Peter Taucher
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Peter Taucher
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Any notion / hint / something?
 
Maneesh Godbole
Saloon Keeper
Posts: 11340
16
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(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.
 
Peter Taucher
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic