WebStart auto-update doesn't always work properly

[Peter Taucher]

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:

<!-- OLD -->
<jnlp spec="1.5+" codebase="http://localhost:8080/...IntSystem/" href="...Client.jnlp">
	<information>
		<vendor>...</vendor>
		<title>..</title>
		<offline-allowed/>
		<association mime-type="application-x/...webstart-file" extensions="...webstart" />
		<shortcut online="true">
			<desktop/>
			<menu submenu="..."/>
		</shortcut>
	</information>
	<security>
		<all-permissions/>
	</security>
	<resources>
		<j2se version="1.6+" java-vm-args="-esa -Xnoclassgc -Xms256M -Xmx512M"/>
		<jar href="...-startup.jar" version="1.0.0" main="true"/>
		<jar href=".../ext/log4j.jar" version="1.2.14"/>
		<jar href=".../ext/dom4j.jar" version="1.6.1"/>
		<jar href=".../ext/xml-apis.jar" version="1.0.b2"/>
	</resources>
	<resources os="Windows">
		<nativelib href=".../native/nativedll.jar" version="1.0.0"/>
	</resources>
	<application-desc main-class="...Startup" >
		<argument>...profile=integration</argument>
		<argument>...systemname=integration</argument>
	</application-desc>
</jnlp>

<!-- NEW -->
<jnlp spec="1.5+" codebase="http://localhost:8080/...System/" href="...Client.jnlp">
	<update check="always" policy="prompt-run"/>
	<information>
		<vendor>...</vendor>
		<title>..</title>
		<offline-allowed/>
		<association mime-type="application-x/...webstart-file" extensions="...webstart" />
		<shortcut online="true">
			<desktop/>
			<menu submenu="..."/>
		</shortcut>
	</information>
	<security>
		<all-permissions/>
	</security>
	<resources>
		<j2se version="1.6+" java-vm-args="-esa -Xnoclassgc -Xms256M -Xmx512M"/>
		<jar href="...-startup.jar" version="1.0.1-RC" main="true"/>
		<jar href=".../ext/log4j.jar" version="1.2.14"/>
		<jar href=".../ext/dom4j.jar" version="1.6.1"/>
		<jar href=".../ext/xml-apis.jar" version="1.0.b2"/>
	</resources>
	<resources os="Windows">
		<nativelib href=".../native/nativedll.jar" version="1.0.0"/>
	</resources>
	<resources os="Windows" arch="amd64">
		<nativelib href=".../native/x64/nativedllx64.jar" version="1.0.0"/>
	</resources>
	<application-desc main-class="...Startup" >
		<argument>...profile=integration</argument>
		<argument>...systemname=integration</argument>
	</application-desc>
</jnlp>

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]

Any notion / hint / something?

[Maneesh Godbole]

(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]

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:

javaws -uninstall

CALL WAIT 10

DEL /S "%TOMCAT_DIR%\webapps\%WAR_NAME%*"
DEL /S /Q "%TOMCAT_DIR%\work\Catalina\localhost\%WAR_NAME%*"
RD /S /Q "%TOMCAT_DIR%\work\Catalina\localhost"

CALL WAIT 10

COPY "%WAR_DIR%\%WAR_NAME%.war" "%TOMCAT_DIR%\webapps\%WAR_NAME%.war"

CALL WAIT 15

rundll32.exe url.dll,FileProtocolHandler http://localhost:%TOMCAT_PORT%/%WAR_NAME%/%WAR_PAGE%

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...