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.
Put a breakpoint to JSP and start debugging. Wait till JSP breakpoint is reached. 1) Go to Runtime -> Server Registry and select Refresh popup action on bundlet tomcat node. Status will changes to 'stopped'. This hasn't any other serious consequences. 2) Open Start/Stop dialog. It says that server is not running. Now you can try to 'start' it, but it will fail because of port conflict. 3) Open properties of bundlet tomcat and change e.g. some port number or debugger type. This shouldn't be allowed because server is actually running. Finish debugger session and try to debug again. It will fail because server is still running on old port.
I'm not sure whether we can do anything about this in cases when Tomcat has been started externally. When the server stops on the breakpoint, it becomes completely deaf to any calls which looks like it is not running. To case 3, for externally started Tomcat we do not prevent users from changing server instance properties at all. Case 1 and 2 won't work on internally started Tomcat either for the same reason. The case 3 should however work on internally started Tomcat, since the running status is determined from the Tomcat's process state. The problem seems to be that the j2eeserver resets the TomcatManager instance, which then no longer holds reference to the Tomcat's process. Needs more investigation why and when this happens.
Agree, not sure how to fix it with current implementation of Start/Stop. This is another manifestation of a known architecture issue.
It may be possible to put in a special check for the internally started server. When the debugging session is active in IDE we can just assume the server is running. Or even display a third stats [debugged].
this was already implemented - server stopped on break point has a special status and all actions are disabled
Verified in 20050825-0258.