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.
Steps to reproduce: 1. Create a web service project for Tomcat. 2. Create a new web service. 3. Define a security role for the web service. 4. Enable basic authentication in context.xml 5. Define security roles and security constraints for web service in web.xml 6. Compile and deploy to Tomcat. 7. Create a web service client project. 8. Select File > New File... 9. Select Web Service Client from Web Services category. Click Next. 10. Select Project radio button and choose secured web service. 11. Click Next to load WSDL. At this point the IDE freezes up. If the security constraints are removed, the WSDLs load just fine. I'm using the June 26 daily build.
I managed to reproduce the issue. It's an infinite loop. IDE is repeatedly trying to access directly the secure web service.
Fixed. Diff: http://websvc.netbeans.org/source/browse/websvc/core/src/org/netbeans/modules/websvc/core/client/wizard/ClientInfo.java?r1=1.20.8.3.2.32&r2=1.20.8.3.2.33
The cause of the freeze is that the AWT thread runs in a busy wait loop, effectively blocking the UI (filed issue 79514 for that). The authenticator needs to display its dialog, so it will wait on the AWT thread forever. It seems to be the intention of the code in validatePanel() to wait for WsdlRetriever to terminate. But the fix ignores that and breaks the wait loop when the authenticator dialog needs to be displayed. Probably harmless because on the other hand the WSDL retriever will send an event when it terminates. But it is unnecessarily complicated and hard to understand. What is for example the meaning of: throw new WizardValidationException(this, "", ""); //NOI18N which now happens even before the retriever terminates? The fix probably introduced another issue: if the Cancel button is pressed in the authenticator dialog the wizard's Finish button is disabled and stays so no matter what is changed in the wizard. Seems weird and brittle. I hope it will be removed when issue 79514 is fixed.
I agree with Andrei about the wait loop and the issues he has described that both it and the fix to this deadlock introduce. I would like to add that there are some rare scenarios, possibly hypothetical, where the retriever thread might not terminate at all (e.g. if the HTTP connection hangs). The original design of the wizard allowed for such possibility without an adverse effect on the IDE. I don't think this is true anymore, even with this patch. I understand this loop was introduced for the purpose of removing the <WSDL Retrieve...> step and instead download the WSDL automatically when the user selects <Next...>. I think the implementation of this change should be revisited (which I believe is the point of issue 79514)
Deadlock has been fixed, the rest is filed as a separate issue 79514 => this one has been verified