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.
System info: NetBeans IDE 6.0 Preview (M9, build 070427) 1.5.0_07; Java HotSpot(TM) Client VM 1.5.0_07-87 Mac OS X version 10.4.9 running on i386 en_US (nb); MacRoman Although the problem happens on Solaris, Ubuntu and Windows as well with those systems running JDK 6. Steps to reproduce: Create a web project and add a web service to it. Enable message level security for the WS Create a new Web project and add a web service client for the WS you already created. Right click the WSC and select edit ws attributes. In the Edit Attributes dialog the WSIT Configuration tab is blank(see screen shot)
Created attachment 41885 [details] Image of blank tab
Created attachment 41886 [details] WS service project
Created attachment 41887 [details] WS client project
Additionally you can use the attached projects to test.
I don't have Mac to test with, but it works fine with the same configuration replaced with Solaris 11 b61. How about attaching an IDE log file?
We are not able to reproduce the issue (on a different OS than MacOS), so downgrading this to P2 and removing J1/PREVIEW stopper keywords.
I cannot reproduce on Ubuntu JDK 6, Build 070429
Can't reproduce also on WinXP.Decreasing priority to P2
I'm confused now. So how and where can I reproduce this?
I was able to reproduce the "blank client config" problem by doing as you suggested: making the service unavailable and then doing a Refresh Client check local wsdl. The refresh threw an error saying in effect the service was unavailable. After redeploying the service and successfully doing a Refresh Client, the client config GUI (WSIT tab and WSDL tab) was fine. I don't think this problem is that serious. When creating the WSC in the first place, if the service you want to use is not available, NB gives an error and does not create the web service reference. So you can't get to the problem yet. The only way to make this problem happen is to successfully create a web service client -- which at that point has a proper client config UI -- and then attempt a Refresh Client while the referenced service is down. It is a bug that the ill fated refresh compromises the client -- leaving it in a bad state -- but it is easily remedied by bring the service up and redoing the Refresh Client. So I'd say the priority is P3 or even P4.
If you invoke Refresh Client when the service itself is inaccessible, the wsdl/xsd files are deleted and the client is corrupted. This should be detected and files should be deleted only if the service artefacts are accessible.
Rassigning to correct owner
What does it mean : service is unaccessible ? The behaviour is correct, I think. The Refresh Client action - cases : Case 1 : option Replace local wsdl with original wsdl located at ... is checked If wsdl file is unavailable the Retriever output shows : Sep 28, 2007 10:43:34 AM : Retrieving Location: http://localhost:8080/WebApplication1/AService?wsdl Error: An I/O error occured. Connection refused Nothing is refreshed. Thet's correct. Case 2 : the above option is not checked and the local wsdl (located under xml-resources/web-service-references) is corrupted somehow, - the client node changes to invalid (the icon is badged), and that's correct. Moreover, "Clean and Build" is always trying to regenerate the jax-ws artifacts from that local wsdl file. It is the "main citizen" here and, of course, it can be corrupted by the user.. We cannot do much with that.
Verified...old no longer valid.