This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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
(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.
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...