Skip to main content

Bug: Web start starts application twice if certificate hostname mismatch

2 replies [Last post]
Joined: 2005-11-16

This is very confusing for our users.

In JRE 1.5.0_08 (so probably in 1.6 too), try this:
- Make a signed webstart application where the certificate name doesn't match the URL (for example the URL could be localhost and the certificate could be "x").
- Configure it to make a desktop shortcut
- Open the jnlp from the URL, and say yes to run even with the hostname mismatch and yes to install the shortcuts. (In my case I also had to say twice to run it even though the certificate is self-signed... why twice?)
- Close the application
- Open the desktop link. You 'll get the "hostname mismatch" dialog twice. If you click run twice, the application with start twice.

I've tested this several times, on 2 winXP installations: it's definitly not one time "I double clicked the shortcut to much" mistake on my part.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-10-13

I have seen an issue similar to this one.
It also occurs only if there is a hostname mismatch over an ssl connetion.

Basically, the issue I am seeing is that my look and feel is getting reset to the platforms default look and feel, AFTER I have set my own custom look and feel.

This problem is very repeatable, especially on a dual core machine. It also occurs on normal single core and hyper threaded machines, but much less frequently... indicating to me that there is likely a threading issue in how webstart is handling its popup dialogs.

The way I get this to happen is I launch my app over webstart. At some point 2 separate dialogs are popped up, asking me the same question, and with the same title "hostname mismatch". I agree to one of them... and then the loading continues... then i cancel the other one... but that one comes back after my app has launched ( and after I have set the look and feel) When i finally answer yes to the reappearing dialog, it resets my look and feel back to the platforms default look and feel (metal, in this case). And my widgets start getting rendered in metal, instead of my custom LAF.

I used a watchdog thread to printoit UIManager.getLookAndFeel().getName() and it demonstrated to me that in fact I was setting my custom LAF properly... and that in fact, the LAF was being set back to metal.

It doesnt seem that Swing is being restarted, but it does seem that it is perhaps being reinitialized, or some other issue... this happens after accepting the final re-occuring dialog.

Joined: 2005-11-16

I wanted to verify this in the latest JRE 1.6 binary snapshot (the one from today), but the JRE 1.6 java webstart didn't recognize that my jars are signed and fails at application startup because my app is requesting system access. So it also didn't matter that my ip didn't match my localhost.