One of the features which we have not managed to finish for NetBeans 7.3 was a Network Monitor. When developing an application which talks to a server all sorts of problems can happen. Server may not respond and simply abort communication; server may send different data than expected; the data which our application sent to a server were not processed on the server as expected; etc. In times like that it is invaluable to be able to analyse what exactly is being exchanged between the server and our application. Did our application used the right URL? did it set right request headers? what exact data are being send to server? what exact data has server responded with? in what format the data are? These and other questions can now be answered with help of the Network Monitor. The feature just landed into nightly builds of next NetBeans release. It is not completely finished, the UI needs to be polished but it is good enough for a first round of review.
Let's look at what it does. When running a project in "Chrome with NetBeans Integration" browser or "Embedded WebKit" browser the Network Monitor monitor window will open automatically similarly to the Browser Log window or debugging session windows:
As I said the UI is preliminary. Trigger a REST or WebSocket communication in your browser application and you will notice network requests to start appearing in the Network Monitor UI. As mentioned on the previous screenshot not all network requests are monitored. The focus of NetBeans network monitoring is to help resolve common problems which happen during development of applications which are using REST and WebSocket communication. Network requests like loading of static resources (ie. images, css, etc.) are automatically filtered out. If you need to see those you can analyse them directly using your browser tooling for example in Chrome Developer Tools. However, any network request which fails is logged and brought to attention regardless of whether it is REST, WebSocket or plain static resource request.
Let's look how network requests are presented:
Above screenshot shows three network requests recorded. First one failed and is therefore shown in red color. The last one is a call to the Twitter Search REST API and shows request and response headers. Switch to Response tab to see data received from the service:
The response from server in this case is JSONP (notice that content-type in the response headers in previous screenshot was "application/javascript") and IDE automatically extracted JSON data from the javascript response and reformatted the single line JSON stream into a more readable form. If it is desirable to see data as they came from the service just tick "Raw Data Response" checkbox at the right bottom corner. In this instance the outcome is:
The last tab shows callstack which triggered this network request and links allow you to quickly dive into your application's code:
For monitoring WebSocket communication the UI is similar but instead of response data you get to see list of textual frames as they happen:
Blue color indicates that WebSocket request is still open and more data frames may be received/sent.
When a network request fails the Network Monitor shows server's status code in the Headers panel, for example "404 - Not Found". There is one error case which the Network Monitor is distinguishing and trying to provide more help than that. It is the case of REST service call which your browser aborted due to Same Origin Policy:
This can happen for example if you are developing REST service and deploying it to a GlassFish server (which by default runs on port 8080) and at the same time you are trying to access this REST service from your HTML5 project which runs on NetBeans lightweight web server (which by default runs on port 8383). In this scenario browser's Same Origin Policy stops your JavaScript code from accessing REST service because the policy says that JavaScript can access only resources on the same server, using the same port and the same protocol.
There are few options how to resolve this. You could run both projects on single server. Or you could enhance your REST service to support JSONP and use JSONP from your JavaScript which would workaround the Same Origin Security policy. However, if you plan to make your REST service publicly accessible then the best approach is to utilize Cross-Origin Resource Sharing (CORS) and amend your REST service to tell browser that it can be called from different domains. For REST services developed in the NetBeans using Jersey this can be as simple as following the "Jersey Cross-Origin Resource Sharing Filter" wizard (in the Web Services category) to create subclass of Jersey's ContainerResponseFilter SPI and provide all necessary CORS headers:
public class NewCrossOriginResourceSharingFilter implements ContainerResponseFilter { @Override public ContainerResponse filter(ContainerRequest request, ContainerResponse response) { response.getHttpHeaders().putSingle("Access-Control-Allow-Origin", "*"); response.getHttpHeaders().putSingle("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE"); response.getHttpHeaders().putSingle("Access-Control-Allow-Headers", "content-type"); return response; }
} The wizard automatically registered the filter in web.xml for you.
Hope you find this feature helpful! Any feedback or suggestions are appreciated.