Test RESTful WS action generates a java script tester page, which works only with a limited set of web browsers. The Google Chrom was not tested.

The application should be improved to work with Google Chrom as well.

I also hit this, and same applies to the Opera browser. This is really a defect (not enhancement).

Not for the upcoming release.

*** Bug 192758 has been marked as a duplicate of this bug. ***

I'm not a Javascript expert, but it looks like WADL is not downloaded from the server. The local page is accessing the wadl via XmlHttpRequest and this seems to be forbidden since certain release of chrome due to security risk.

I don't think there is easy way to fix this. I tested it works when the test page is uploaded on server as part of application.

I agree with Petr H., it's not able to access the wadl file. The exact cause of these troubles is that local file (file://) is calling wadl which run on the server (http://localhost:8080...) - it means that it's XSS security problem. 

I'm afraid that not just Opera, Chrome are solving this security issue, but also FF 4 should be do that, so problems will appear still in more and more browsers in the future (because of improving browsers security).

There are possible two solutions (from the error aspect):
1, keep the wadl and REST testing page on the same domain ... it means the same solution what mentioned Petr - have the rest-test resources as a part of web project sources
2, I wasn't able to check it but adding header information "Access-Control-Allow-Origin:*" into responses from application server should help
For more information see http://www.w3.org/TR/cors/.

But I'm afraid that I have to agree that it's not for easy fix.

Thanks Petr and Martin for the evaluation. Regarding a possible solution:

> 1, ... have the rest-test resources as a part of web project sources

I don't really like putting the rest-test sources into the project - this pollutes project sources and the user loses control over the packaging.
But how about a modification of this approach - packaging the rest-test sources to a separate application (e.g. netbeans-rest-tester), and deploying it alongside the main project?

> 2, ...adding header information "Access-Control-Allow-Origin:*" into responses

How would this work in practice? How can I force the server to do this? Also, if the REST tester page is a local file, how/when would this header be applied?

I am also wondering, could there be other solutions? E.g. (just brainstorming):

3, If we have the embedded browser one day, open the tester page in this embedded browser and through some APIs, change the access control parameters for this page.

4, Do the same thing as 3, but for external browser. I.e. we would require some tight integration with the external browser and call it via native APIs.

1, sounds like only one, universal solution

2, this header would be sent by server (since the local file call server url), but I'm afraid that it would pollute the application as well (filters in web.xml, custom servlet for processing requests etc.)

3, I don't know possibilities of embedded browser, theoretically it's possible, but I'm afraid that plans with embedded browser were many times tried out and you know, still no ideal solution

4, It sounds to me like really much work for one P3. I also think that API like this wouldn't be possible for all browser (also it would need much of maintainance then, I would assume)

This issue is not for 7.0 already.

But I would like to clarify the result of suggestions:
as I understand the definite solution would be putting WADL file locally.
Am I right ?

In the latter case I don't see a problem actually.
No need to package WADL file along with application ( it is useless actually
as I understand ).
How it can be done : the test client is generated on the local filesystem inside
build folder EACH time when Test action is invoked.
So it is possible to download WADL file from the J2EE server before Test client
is opened in the browser. JS will use local WADL file instead of remote if it
exist. WAD file download can be done via Java code or ANT task.

Will this scenario work from the JS point of view ?

> download WADL file from the J2EE server before Test client is opened in the 
> browser

I didn't think of this, but you are right this could be a solution.

> Will this scenario work from the JS point of view ?

Not sure, can you somehow try it out by downloading the WADL and manually tweaking the test page?

Yes, it should work at least for generating the page (the left menu).

But not sure how will it work by additional communication. It's perhaps really needed to try it...

I forgot to say that the place of the downloaded WADL file should be somewhere inside of build folder near with Test HTML file.
In that case it will not be bundled with WAR file.

>Not sure, can you somehow try it out by downloading the WADL and manually
>tweaking the test page?
I don't have neither Chrome nor Opera :)
But OK, I will install and check .

So actually my suggestion is incorrect.
Simple replacement from the remote URL to local WADL file doesn't work.
XMLHttpRequest is used for access to file and it doesn't work with local file.

Reading local filesystem is also security bug as I understand. I'm not an expert 
in the JS but I suppose local file reading requires additional permissions for JS.

So Test client needs to be placed into the same WAR. As result it will be in the 
same domain and will no throw security issue.

So the only way which I can suggest for now is :
- download WADL via ant or Java code.
- parse it before Test client is generated
- create Test client ( HTML and JS ) via Java code based on parsed WADL content.
So the dynamic content based on WADL file content is moved from JS into Java code.
But I'm not sure if it helps to handle HTTP request from local JS to remote host.
It seems such HTTP request can throw the same security problem as WADL access.
So the WADL access problem is only first problem here.

More addition :
the WADL issue is really only "interface" problem.
Generated HTML file is not able to access to remote content of WS via HTTP.

How I've checked this :
open Test client in FF and select all. Then use "View Selection Source".
Grab HTML content and save it to the file. Open this HTML in the Opera.
There will be good content with WebServices and their urls on the left side.
Try to send some HTTP request to the WS.
It fails.
So the LOCAL JS client is the main problem .
It really should be bundled with the Web App in the same WAR.
I don't see other solution.

The second solution which would not polluted user application is the one mentioned by Petr J. Wrap content of rest-test dir into new web application. If it will be deployed on the same server there will stay the same URL and port (i.e. localhost:8080) which will be identified as the same domain.

web-main
changeset:   193603:e757bc37de3b

Integrated into 'main-golden', will be available in build *201105120000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/e757bc37de3b
User: Denis Anisimov <ads@netbeans.org>
Log: Fixes for BZ#198475 - JAX-WS client issue in Maven MavenCalculatorClient project and BZ#159653 - Test RESTful Web Services does not display correctly in Chrome and Opera.

I assume the fix also applies to FireFox 4 and 5? Have been getting some user complaints regarding those.

Fix doesn't detect automatically user's browser.
So it doesn't relate to special vendor. User chooses the way how test client will be generated by himself. 
So if browser has no security restriction then local client can be chosen.
Otherwise client should be generated inside some web project and the client should work with ANY browser without restrictions.

*** Bug 202464 has been marked as a duplicate of this bug. ***

*** Bug 203075 has been marked as a duplicate of this bug. ***

*** Bug 203075 has been marked as a duplicate of this bug. ***

*** Bug 209013 has been marked as a duplicate of this bug. ***

*** Bug 212513 has been marked as a duplicate of this bug. ***