Java Web Start uses a different cache directory

Question

I have a Java Web Start application. My JNLP instructs Java to prompt when there is an update, and create a desktop shortcut.

On UAT site, it works as intended. The shortcut's target will be something like this:

C:\Windows\SysWOW64\javaws.exe -localfile -J-Djnlp.application.href=[https]://[Domain]/[Path to my JNLP].jnlp "C:\Users[User name]\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\21\5819ce55-139863fe"

In Java Control Panel, I can see my application listed in the cache's Applications list. In the Resources list, I can see the entries for both JNLP and JAR files.

But on Pre-production site (using the same client machine), Java will use a different cache folder:

C:\Windows\SysWOW64\javaws.exe -localfile -J-Djnlp.application.href=[https]://[Domain]/[Path to my JNLP].jnlp "C:\Users[User name]\AppData\Local\Temp\tmp_cache2515468182853051613.tmp"

In Java Control Panel, the Pre-Production application is not listed in the Applications list. In the Resources list, I can only find the JAR file but not the JNLP file.

It is because of the missing JNLP in cache, that whenever I launch the Pre-Production version via the shortcut, Java will prompt that an update is available and will re-download the JAR file.

I tried turning on deployment log, but I have no idea what I should look for. I found entries like this:

Wrote URL [https]://[Domain]/[Path to JNLP].jnlp to File C:\Users[User name]\AppData\Local\Temp\tmp_cache3515307480207784226.tmp

But I have no idea why Local\Temp is used over DeploymentCache. The JNLP files of UAT and Pre-Production sites are nearly identical, the only differences are a change in the title element and contents in properties files.

Another difference I can think of is the server certificates - the JNLP and JAR files are hosted on Apache servers. Java will show a dialog for the Pre-Production certificate, saying that it failed to check CRL. I tried disabling CRL checking and the dialog went away, but it's still using Local\Temp instead of DeploymentCache.

What can be the reason behind this behavior of using different cache locations? It is almost like Java found something untrustworthy about the Pre-Production version and refused to cache its JNLP.

Edit: In a nutshell:

1. Same client machine, same settings.

2. Load UAT version of the application, JNLP and JAR gets cached in DeploymentCache folder (expected behavior).

3. Load Pre-Production version of the application, only JAR gets cached in Local/Temp folder, JNLP is not cached (unexpected behavior).

4. Only differences between UAT and Pre-Production versions are that they have different title in JNLP, properties files with different content, and that the Apache server hosting the Pre-Production version is using a certificate that Java can't check its CRL. Application JAR is signed by a different certificate that Java has no problem validating.

5. I would like to know what influence Java Web Start to behave like that. I suspect it has something to do with the certificate on the Apache server, but I can't find any documents about that.

Answer 1

Have you looked into deployment.user.tmp property in deployment.properties ? http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/properties.html

Answer 2

As per Applet stopped working with a JNLP MissingFieldException <jnlp> see the cookie information to understand if Httponly is contained within it -- looks like it can cause this behavior with jws.

Alternatively this actually worked for me specifically...

In a browser, access the same exact resource from lower and upper environments and inspect the HTTP headers to see if there are any Cache-Control (no-cache and/or no-store directives) or Pragma: no-cache differences. Suspicion is that the environment that is not working has caching directives explicitly specified which, as per first comment of Java Web Start "Cannot find cached resource for URL" and first comment of https://bugs.openjdk.java.net/browse/JDK-8034978, happen to cause java web start to write to a different cache folder than what is specified in java configuration settings and, ultimately, causes the behavior discrepancy you're seeing. The fix would be to update the app server, web server and or any other intermediaries (eg. load balancers) to remove it from the http response headers.