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.
Description: The HTTP Monitor does not work properly when multiple instances of FFJ are running on a multiuser server. The HTTP Monitor seems does not realize that mutiple users are running FFJ, and gets 'confused' on where to send HTTP traffic data. To replicate: Have 2-5+ users login to a single server/workstation (Solaris/Linux). Each user should run their own instance of FFJ. Create a JSP page, compile and execute it. Open the HTTP Monitor to see if any HTTP traffic data is reported. Only the user who own the first loaded instance of FFJ will be able to see anything in his/her HTTP Monitor. All other users will not be able to see anything in their HTTP Monitor. Furthermore, the HTTP traffic data for *all* users will be sent to the user who owns the first running instance of FFJ. This stops users from being able to use the HTTP Monitor feature on multi-user servers and SunRay environments. Evaluation: We can partially solve this by adding an init parameter to the monitor filter which specifies what the internal port of the IDE is. This will require restarting the server if the port number of the internal HTTP server changes. The monitor can probably fire a warning to this effect. We will not be able to do that fix for the version that goes into the RI so I will have to keep the current stuff as it is. Also, just doing this means that we remove the ability of the monitor to record requests on servers that are managed by a different IDE (or managed externally of the monitor). That might not be so bad in the short term because those are not well recorded anyway. A comment.
This issue needs to be resolved in conjunction with other modules (server integration and/or web module/DD editor). The issue at hand is that the server side component (a servlet filter) of the monitor needs to send data back to the IDE. It uses the internal HTTP server for this purpose, so the filter needs to know which server and port to send the data too. This needs to be identified on a per IDE basis. A possible solution is to add a parameter to the filter declaration in the deployment descriptor (or default deployment descriptor, if such exists) of the server with the correct port number. This solution would have to be coordinated across multiple modules, and it's important that it is designed in such a way that it will work automatically for any server plugin, not just for Tomcat.
After discussing this issue with Petr Jiricka, we agreed to the following solution in the 3.5/Nevada time frame: the tomcatint module will declare the host and port of the IDE's internal server as init-params to the monitor filter as follows <init-param> <param-name>name of host</param-name> <param-value>port</param-value> </init-param> It will do this by using the open APIs to get the port number. (I'm assuming that it is possible to listen to changes to the port number?). A side effect for the user is that unlike today, if the port number of the internal server changes, it will be necessary to restart the web module for the monitor to be able to start recording again. We could theoretically add a listener to the Monitor client, such that if the client is open and it receives an event that the port number of the internal server changes, then it warns the user that the server must be restarted in order to continue to record data. However, this is a GUI change and I don't think it can be done for 3.5.
Corresponding integration was made by Petr to the tomcatint module, so this mechanism now works. The monitor client will only send data to the IDE which deployed the web module.
Verified in release 3.5.1.