15

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.

skiphoppy
  • 97,646
  • 72
  • 174
  • 218
  • Have you tried setting up Tomcat outside of JBoss and putting your webstart app up there? What happens? Does it report different times after you shutdown tomcat? – chubbsondubs Dec 01 '11 at 20:18

3 Answers3

3

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.

blahdiblah
  • 33,069
  • 21
  • 98
  • 152
  • Wow, I'm not sure what JBoss is doing with my exploded ear and war, but it took three minutes without saying anything, then threw an exception when it ran out of permgen space! – skiphoppy Dec 05 '11 at 20:06
  • For some versions of JBoss, the exploded directory name has to end with `.war` or `.ear` as appropriate. Are you doing that? – blahdiblah Dec 05 '11 at 21:19
  • No, I was making some other stupid mistake which I corrected this morning -- and it turns out this works! Thank you for a simple and concise workaround! :) – skiphoppy Dec 06 '11 at 19:06
  • Took me a day to realize that marking your answer as the selected answer didn't award you the bounty. Sorry about that! The interface changes every time I'm here. :) – skiphoppy Dec 07 '11 at 15:03
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).

Chris
  • 22,923
  • 4
  • 56
  • 50
0

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

bugske
  • 218
  • 1
  • 8