Java Web Start broken since JDK 1.7

Question

HERES THE ANSWER: It appears (through our testing) that Java 7 Web Start requires you to host your resources on a server using an SSL certificate. Your cert does NOT have to be signed, but unsigned certs will prompt the client with a trust message that they can ignore. See the below answer for more details

We have an internal application which we have been using for many years now. In order to make maintenance easier for this application we have not provided an installable version of the application to our employees, we simply give them a link to a .jnlp and use JWS to launch it on their box. This has thus far worked fantastic, but as soon as any of our employees update to Java 7 the JWS system stops working on their computer. We have checked, rechecked, and even validated our JNLP schema and it's fine, which leads us to think there is an issue with Web Start itself.

When the user clicks the jnlp file, it launches the Java 7 splash screen, which then begins to download the resources we need. From there it simply hangs and the progress bar on the JWS launching app remains at zero percent.

Any ideas? It is very much caused from the fact that they upgrade to Java 7. In the mean time we have advised that all employees are to remain on Java 6 until further notice. All of our code is properly signed.

Here's a copy of our JNLP:

<?xml version="1.0" encoding="utf-8"?> 
<jnlp 
  spec="1.5+" 
  codebase="http://peiportal/updater">
  <information> 
    <title>PEI Portal Application</title>
    <vendor>Petz Enterprises, Inc.</vendor>
    <offline-allowed/>
  </information>
  <security>
      <all-permissions/>
  </security>
  <resources>
    <jar href="PEIPortalLauncher.jar"/>
  </resources>
  <application-desc/>
</jnlp>

Answer 1

We recently ran into this issue when people started installing Java 7 on their Windows boxes. We have instances of jar files on three different linux servers, and found that we could download the application from two of them, one remote and one local, but not the third, also local, server.

The key was in the codebase specification in the jnlp file. In order for the jar file to be successfully downloaded to a Windows box running Java 7, the codebase had to specify "https:..." rather than "http:...".

The remote server cited above is set up as a secure server, and so was specifically set up with https. Neither of the local servers are set up securely, but the one that worked just happened to use "https:" in the codebase specification. Changing the jnlp on the other server made it work as well. (Our jnlp is templated, and modified for each install outside of source control, hence the potential for differences.)

You may need to delete any non-working Applications listed in your Java Control Panel to synchronize with the new jnlp on your server: go into the General tab of the Java Control Panel (available from the Windows Control Panel), press the "View..." button under "Temporary Internet Files", and delete any non-working Applications.