This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
This happens when you call ConnectionManager.showConnectionDialog() and all the parameters are already provided (username, password, url). I tried to reproduce with the SQL editor, but this doesn't seem to even try to reconnect any more, which is another bug... This didn't happen before, but what happens is the dialog shows briefly saying "reconnecting to database" and then it disappears, but the IDE *hangs* for about 1 minute while we attempt to connect to the database. Try this with MySQL it's very easy to reproduce. Finally an error dialog comes back saying unable to connect, and the dialog to specify user and password is also brought up. But there are *three* error dialogs that come up, so you have to say "OK" three times. Really pretty broken, and I suspect this is due to explorer changes.
Not due to the explorer changes, but certainly exposed by the new explorer. I believe this I fixed this today in my local build. This is what happens when someone writes code that calls out while holding a lock. And after the scary spaghetti of calls and event handlers ends up making a call a NB api (dialog displayer) that clearly states that you should not call it while holding a lock. Please try not to use the new explorer as the first guess at where a mistake is made ;)
Well, back at me. Thanks for fixing this (hopefully).
If it doesn't, it's right back at me again :) I hope to commit again tomorrow. I ran up against this bug, the one where you get multiple messages about connection errors, and I think a few others, while working on the properties stuff for the connection node. Tomorrow's commit may not be the complete fix for this stuff, but it's a step in the right direction. I've also encountered what appears to be timing issues, which I think may have something to do with connections not being re-established from the sql editor. I'm trying to determine if this has to do with our use of the default RequestProcessor, which uses multiple threads and therefore does not guarantee that tasks submitted to the processor will be processed in the order they were submitted.
I'll be committing a fix tonight. I'll follow up with the changeset when it's committed. BTW I can easily reproduce this in 6.5.
Please verify that this fix works. My testing shows it does, but I want someone else to validate it before I mark it as fixed. The changeset is 652504110492
I'll do a pull tonight and try to verify. It's disturbing that this is reproducible in 6.5. How did we miss that?
Fixed, works for me now, thanks.
V