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.
When a debugger stops at breakpoint the application server appears to be stopped. But If you try to run it it fails. It should not be possible. To reproduce: - create a web application - add breakpoint to index.jsp - start debugger and wait until it stops at breakpoint - in Runtime view call menu item 'Start/Stop Server' on server instance - Server Status window appears with 'Start Server' button enabled - click 'Start Server' button and server tries to run but it fails with port conflict. Start Server button should be disabled to prevent the failure. Note: For application server it displays a warning window first time you click server node but second time it opens Server Status window. Build 20050201-1106, JDK1.5.0_02, WindowsXP.
Does this happen for Tomcat, too? Could you verify this still happens after Ludo's fix of 55290 made yesterday? Thanks.
Yes, it happens primarily for Tomcat. It is still a valid issue in recent build 20050301-0836.
This is fixable by e.g. copy & update isSuspended() method from TomcatManager, or by adding some api to call plugins and addition of another 'SUSPENDED' status. I leave decision on j2eeserver owners.
Testing of suspended state requires server's debug info for comparing with session parameters. Tomcat works well but App server debug info returns null, see issue #56714.
Fixed except wrong detection of App server. Checking in src/org/netbeans/modules/j2ee/deployment/impl/ui/ServerStatusBar.java; /cvs/j2eeserver/src/org/netbeans/modules/j2ee/deployment/impl/ui/ServerStatusBar.java,v <-- ServerStatusBar.java new revision: 1.15; previous revision: 1.14 done Checking in src/org/netbeans/modules/j2ee/deployment/impl/ServerInstance.java; /cvs/j2eeserver/src/org/netbeans/modules/j2ee/deployment/impl/ServerInstance.java,v <-- ServerInstance.java new revision: 1.46; previous revision: 1.45 done Checking in nbproject/project.xml; /cvs/j2eeserver/nbproject/project.xml,v <-- project.xml new revision: 1.6; previous revision: 1.5 done Checking in deps.txt; /cvs/ide/golden/deps.txt,v <-- deps.txt new revision: 1.51; previous revision: 1.50 done
app server is returning null, only is the server is not running... In the case the server is suspended, we should retunr the correct debuginfo. But the AS implementation for testing if the server is suspended is a littel bit different than tomcat... Do we need a new j2eeserver api?
It is a little bit beyond my knowledge of j2eeserver. Maybe Stepan would know...
I don't think new API is needed. ServerInstance could just cache debug info right after calling startDebugging..., reset the cache when stop is called. So, there is no need to call plugin's getDebugInfo when server is known to already running in debug mode.
IMO (if I understand), this solution works only if we resignate of existence of more than one target. The correct solution would cache not only ONE ServerDebugInfo for each ServerInstance but should contain mapping Target->ServerDebugInfo. In this case we get the old known problem not-having-target-when-app_server-is-suspended, thus cannot retrieve debug info. Well, I can implement Nam's or my solution (are hacks in fact), which would pretend that we have only one target... The best and now impossible way is the clearing and rewriting of the corresponding j2eeserver code and maybe some parts of the plugins to ... with multiple targets. Because we think that aside of optimal solution the responsibility for server state detection should be on server itself, we filed API review issue #56926.
Targets from an instance are cached, so I don't think we would have the problem of not-having-target-when-app_server-is-suspended J2eeModuleProvider.getServerDebugInfo is called.
"targets from instance are cached"....I can see it in ServerInstance. But I don't know which target to use (because there can theoretically more than one target). I am trying to solve following: a user right-clicks on server instance and click Run/Debug...then ServerStatusBar instance is created and ServerStatusBar.setCommandControlButtons() is called and this is the place where ServerInstance.isSuspended() method is called. Do you have any idea how to bring correct target to this call? UI does not support more targets (visible for user), doesn't it? Or did I miss something? And it is interesting - null target is passed to ServerInstance.startDebugTarget() which is called when a user clicks 'Start(Debug)' button on ServerStatusBar ;) Anyway, I still think that it is server responsibility to announce its state...
Thanks for clarifying. I agree that in general plugin would be better to report its own state like running, stopped, or running debug mode. *But* the case of suspended state is different. How would plugin find out about suspended state without talking with server? By doing the same thing that j2eeserver would. So why not spare plugins yet another required service. The ServerProgressBar dialog is design for start/stop server instance only. (Start/Stop target UI are currently to be provided by plugin). So, to pick the right target to check for suspended state in this dialog, use StartServer.isAlsoTargetServer(target). I assume, at this point when server is already running in debug mode, plugin would know how to answer this without talking to server.
Fixed by workaround proposed by Nam. There is a little bit slide based on target searching within Target->ServerDebugInfo map instead of current target-name cache. The reason is unclear (at least to me) and uncommented use of this cache (and more..it seems that this cache is never used when start debugging is executed). Checking in ServerInstance.java; /cvs/j2eeserver/src/org/netbeans/modules/j2ee/deployment/impl/ServerInstance.java,v <-- ServerInstance.java new revision: 1.49; previous revision: 1.48 done
Verified in build 20050319-0955.