Home/ Questions/Q 6905241
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T08:09:34+00:00

At my company we are using Java Web Start to distribute client software to

  • 0

At my company we are using Java Web Start to distribute client software to the customers. They are using different Windows versions: XP, Vista and 7.

We’ve deployed a version through JWS with minimal problems in the past. Our latest release includes several file changes, some jars are gone, other’s appeared, etc.

We found out that upgrade on Windows XP machines fails because JWS still tries to look up jar files which are’nt available anymore on the web server. I’ve checked my HTTP server’s log and the JNLP file never gets accessed from XP machines during application startup. If i try the same on Vista or Windows 7 everything works fine, JWS fetches the JNLP descriptor and downloads the differences when an update is available. So on XP machines only the known jar files gets updated and JWS throws an error if it doesn’t find something from the cached JNLP’s fileset.

I’ve written a servlet which manually generates the JNLP file. I’m using the following header config in my servlet code.

response.setDateHeader("Last-Modified", lastModification);
// IE won't download JNLP file if Cache-Control header presents
//response.setHeader("Cache-Control", "no-cache, must-revalidate");
response.setHeader("Expires", "Mon, 26 Jul 1990 05:00:00 GMT");

This makes the JNLP file always outdated which should trigger recheck of the file every time the client gets started through JWS. I can even see this date in the cache viewer on XP:

Cache Viewer

I’ve found a never resolving problem about this on Oracle’s bugreport site: Bug ID: 6189106 Just tested the same with Java7 on Windows XP but this problem still exists. But only on XP because of the white space characters in the deployment cache’s path ("Documents and Settings" you know). Somebody says there that if i change the deployment cache’s path to something which don’t have space characters in, it will solve the problem. Well it’s not an actual solution because users can hardly ever write to locations other than their profile.

Because this bug exists for such a long time i guess there should be some kind of workaround. I don’t like to tell the customer every time to clear the Java cache and reinstall the application from web. We like to move to a more faster release cycle in the future which will make this even worser. I hope someone has a good idea for this. 😐

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The problem is in the path to the cachedir of the java webstart. If it contains spaces (that is exactly the case in XP) then the path is passed in a wrong format to the javaws and this will block the update check of the jnlp file.

    Change this path in deployment.properties file like this:

    deployment.user.cachedir=C\:\your\path – this path should not contain spaces.

    P.S. clean java cache before that.

    Added: The problem seems to be appeared after update 21.

    • 0