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.
Tried with 2 services: * RESTful service from entity classes, both MySQL and Derby db versions * Simple service from patterns Created the service from entity classes according to our Getting Started from REST tutorial.Created a service from patterns with the following GET method: @GET @Produces("application/xml") public String getXml() { String hello = "Hello, World!"; return hello; } Built both applications without problem. Deployed both applications without problem, both when using Deploy on Save and when not using Deploy on Save option. Most testing done was with Deploy on Save *disabled*. Testing the RESTful service from entity classes produced the error "Cannot access WADL" at the URL http://[2001:0:5ef5:79fd:3009:38d4:c10a:bc68]:7001/CustomerDBWLDerby/resources/. That URL in the browser gives me "Internet Explorer cannot display the webpage." Replacing the weird string with "localhost" returns a 404. The RESTful service from patterns was stranger. Yesterday I tested it and it was OK. Today I tested the same service, still deployed to the same server, and got the "Cannot access WADL" message, again with some weird string for the host name. I tried undeploying, rebuilding, and redeploying but could not get the test to work again, although as I said it worked yesterday. WebLogic server version is 10.3.3.
Forgot to mention that I also tested the URL for individual web service operations. The simple service from patterns gave me "Hello, World!" output even when the RESTful web service tester was complaining that it could not find the WADL. Testing an operation of the RESTful service from entity classes gave me a 404.
I don't think it relates to WS functionality. Webservice url which is used in test action based on ${client.url} property value. This property is set by deployment ant task. So this is Weblogic deployment problem most likely. Please do the following : - invoke action "Run" for your project. It should just opens index.jsp page for Web project. It's URL is also based on the same property value of ${client.url}. Please let me now the url which is used as result in your browser. - if on previous step you will get normal url ( not the same as you reported originally ) please open build-impl.xml file in your nbproject directory and "-post-run-deploy" task there. Please add inside it the string : <echo message="XXXXXXXXX ${client.url}"/> Then run deploy for web project and find string started with XXXXXXXXX in the output tab. Please write here result url from this message .
Running the project opens the following URL in the browser: http://192.168.1.36:7001/CustomerDBWLDerby/. The Hello, World! JSP page displays correctly. My localhost IP is the default 127.0.0.1, not this. Adding the URL echo line to the -post-run-deploy task results in this message when the application is deployed: My client.url value is: http://localhost:7001/CustomerDBWLDerby I hope you can make some sense out of all this.
OK. This string : [2001:0:5ef5:79fd:3009:38d4:c10a:bc68] is most likely your IPv6 address. I suppose you have IPv6 enabled and it works along with your IPv4 address. To approve it please run the following command in your command window : ipconfig /all Please write here the output of this command. The next thing : please check the same as I have wrote before ( exactly the same steps ) and invoke Test RESTful WS action right away after these checks. I believe that : - in case when you have client.url value is http://localhost:7001/CustomerDBWLDerby test client works correctly. - in case when test client works as your reported the client.url value is http://[2001:0:5ef5:79fd:3009:38d4:c10a:bc68]:7001/CustomerDBWLDerby. Please confirm or disclaim this . One more thing which I want you to check: do you have any firewall ? There can be two options: - custom firewall manually installed - windows internal firewall please check whether they enabled/disabled The last thing : please put here the output of command netstat -an
Created attachment 103949 [details] Results of running ipconfig/all
Created attachment 103950 [details] Results of running netstat -an
Denis, I've run ipconfig/all and the results are attached. You are correct about {string beginning with 2001} being my IPv6 address. I restarted WebLogic and ran the deployed application again. However, this time I got this in my output when the IDE redeployed the application: My client.url value is: http://[2001:0:5ef5:79fd:2868:1f4f:c10a:bc68]:7001/CustomerDBWLDerby The browser opened to that address but "Internet Explorer cannot display the webpage" I ran Test RESTful Web Service, and again during redeployment got the output message My client.url value is: http://[2001:0:5ef5:79fd:2868:1f4f:c10a:bc68]:7001/CustomerDBWLDerby Test failed due to WADL not being found at that address, as before. I cleaned (which undeploys the app) and rebuilt. Then I tried to run, but I cannot run web applications on WL without deploying them first separately. If I try, run fails in the redeployment step, because according to the error message, there is no application to undeploy. (Is it supposed to work like that?) I deployed the application, and got the message My client.url value is: http://localhost:7001/CustomerDBWLDerby Then I ran the application again, but after redeployment step the output gave the message My client.url value is: http://[2001:0:5ef5:79fd:2868:1f4f:c10a:bc68]:7001/CustomerDBWLDerby and IE could not display anything. I ran Test RESTful Web Service, and again during redeployment got the output message My client.url value is: http://[2001:0:5ef5:79fd:2868:1f4f:c10a:bc68]:7001/CustomerDBWLDerby Test failed due to WADL not being found at that address, as before. I ran netstat -an and the results are attached. My Windows firewall was active. I turned it off and ran the application again, but the problem persisted: client.url was my IPv6 address, and IE could not display any results for that URL.
Thank you very much Jeff for this information. I will analyze it on the Monday. I have asked you about firewall just for sure actually . The problem is clear for now : there are several IP addresses on your box : localhost ( which is already exist for any box ) your local net ip address 192.168..... and IPv6 address. client.url which is set by deployment Ant task differs each time . I don't know what exactly algorithm is used for it but sometimes it returns localhost sometimes 192.168.... sometimes IPv6 address. Both localhost and 192.168... addresses are IPv4 addresses and WL server has a listen socket on both of these addresses. But it seems this is not so for IPv6 address. But client.url could have a value with this address. This is the problem. Application is not deployed on server because there is no server on IPv6 address. So the problem as I said from very beginning in the WL deployment functionality. I will confirm this as I said after detailed analyze on Monday. The workaround for now : disable IPv6 support on your box.
Jeff, as I see your IPv6 address is listening by WL server. I just checked that for me all works fine : I have installed IPv6 , configure it and I'm able to start WL . Also there is no problem with URL with IPv6 address . It perfectly works. My web service also works fine. I cannot reproduce the problem. There is only one thing which I can suggest : there is still service which prevents your from working with IPv6 addresses. It can be a firewall . Please check that you really don't have any firewall enabled. It could be a proxy setting in your browser. Please check that you have direct access without any proxies . It could be a IE problem . I'm using firefox and it doesn't have problems with URL with IPv6 address. May be your browser has some problems with this. In any case : this has no any relation to WS functionality. This is common problem. But I don't know exactly what is the source of this problem.
I'm happy to dismiss the whole thing as a vagary of my machine, which is barely able to run WL and NB at the same time.
Works on my new machine