Why does Java Web Start redownload jars from JBoss?

Question

We just discovered that every time we restart JBoss, all of our Java Web Start clients redownload all of their jars, instead of reusing the cached jars, even if our application has not changed.

From what I've seen on the web, Java Web Start does an HTTP HEAD to decide whether or not to download a jar. So I ran HTTP HEAD on all jars in our application, and discovered that after restarting JBoss, the modified time of all the jars has changed!

Why is this, and how can I fix it? The jars inside of my application archives have not changed at all. As near as I can tell, JBoss uses the time of startup or time of deploy as the modified time. This is going to completely short-circuit Java Web Start's ability to use cached jars from previous runs, if I understand correctly.

We use JBoss 6, if that's an issue. Previously we used JBoss 4. I want to check to see if we had the problem under JBoss 4, but we now have so many dependencies on the newer JBoss that it is going to take some work to make that test happen.

Answer 1

Try deploying your application as an exploded web application instead of a WAR file.

That would prevent JBoss having to decompress the application and potentially mess up the modification dates.

You'll have to handle updates to your app in a way that preserves modification dates, e.g., rsync, but that might be easier than downgrading or patching JBoss.

Answer 2

It looks like VFSUtils isn't maintaining the lastModifiedDate of the file when it mounts the filesystem to the tmp directory on server startup. You could patch the copy methods in that class to try to set the timestamp of the new file based on the values from the physical file.

As a response to the comment by chubbard: the problem does not occur with Tomcat (tomcat 7.0.21 to be precise).

Answer 3

There is an issue (https://issues.jboss.org/browse/JBVFS-177) created about the VFSUtils.unzip() which does not preserve timestamps while deploying (still applicable to JBoss 6.1).

As the issue is related to the unzip method the solution of blahdiblah may indeed works.

Another way would be to use Java Web Start with a version based (Modification of the jnlp with versionEnabled and creation of a version.xml).