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.
Frequently I cannot start a jsp debugging session, usually after stopping Tomcat. I.e., it works before starting Tomcat, but doesn't work again after stopping Tomcat (even if any existing debug session is first Finsihed). This manifests as the Debug menu option being greyed out when right clicking on a jsp. In this state, if I try to set a breakpoint in the jsp, then NullPointerException in Utils.getServletClass results. Possibly related is a frequent exception I was getting in the request processor on start-up of the ide, usually after having stopped Tomcat externally. This happened when I was using my own Tomcat 5 installation and could start it and debug within the ide, but could not stop it. (That problem arose during the use of NB 3.6 and persisted in to my upgrade to 4.0 Beta 2 -- I expect 3.6 somehow wedged by Tomcat config in its various modifications of the config files.) After closing the ide and manually terminating the Tomcat process tree, I would get the request processor exception upon start-up of the ide (4.0 B2), and would be left in the state above where debugging jsp's was impossible. In this state, rebooting the PC was required to recover. I've switched to the bundled Tomcat and no longer get the request processor start-up exception, but still get the NPE and can't debug if I ever stop Tomcat. Fortunately, this problems appears resolved by restarting the ide, after which I can debug again. The attached log file has numerous occurrences of the request processor start-up exception as I was trying to resovle it in various ways before switchig to the bundled Tomcat. The focus here is on the NPE at the bottom. If there is a workaround for this problem that is quicker than restarting the IDE I would appreciate knowing about it. Thanks, Chuck
Created attachment 18033 [details] Log file: please focus on NPE at bottom. Bug description explains...
Thanks for the report. The SwingBrowser treepair exceptions in the beginning are this bug: http://www.netbeans.org/issues/show_bug.cgi?id=48590 which should be already fixed (not in beta2, though). As for the grayed menu, please have a look if it's not this one: http://www.netbeans.org/issues/show_bug.cgi?id=49418 The NPE exception is unknown. Could you please try it in latest dev builds and a clean userdir? There has been also this bug fixed since beta2 that could cause your 'unable to start debugging' problems: http://www.netbeans.org/issues/show_bug.cgi?id=49404 I'd like to know version of the jdk you are using and also which version is the external instance of tomcat you are using, and what configuration changes you did (if any). If you say 'when I stop tomcat' - do you stop it from IDE by the start/stop dialog or do you kill the process? Could you please be more specific about 'I can't stop it'? How does the IDE behave then?
I looked at the NPE - seems like there's a problem trying to find a webmodule for the jsp. Please try to run the IDE with this switch: -J-Dorg.netbeans.modules.web.debug=0 -that could give us more debug info to start work on.
Thanks for feedback and pointers to related bugs. The greyed menu problem does look similar to http://www.netbeans.org/issues/show_bug.cgi?id=49418 -- could be same problem but don't know for sure. I'm using the JDK 1.5 FCS. My external Tomcat is 5.0 (RELEASE-NOTES,v 1.18 2004/06/15 18:42:06). I haven't changed the standard Tomcat server configuration other than assining a different port for it to listen on, although I did need to repair 3.6's configuration changes at one point (it would not properly remove the HTTPMonitor config, or its additions to configure running of my app). Only other Tomcat config is my web.xml. By "could not stop it" I meant from the ide (Start / Stop Server). The monitor would just hang although the ide continued to work. Only when I couldn't stop Tomcat would I exit the ide, wait for it to fully shut down (watching its task in Task Manager) and then kill the Tomcat process tree. Will try a development build in the next few days and try to reproduce more cleanly. Just got suggestion to try -J-Dorg.netbeans.modules.web.debug=0, will try this also tomorrow. Tnx.
I do not have a reproducible case for this problem, but it or something just like it as just recurred. I'm now running in the 200410080520 Daily build and have not seen the problem until now. I just had Tomcat fail to stop from within the ide (right clicking on bundled Tomcat server, stop, and then deployment monitor hung showing no progress and Tomcat did not stop). I exited the ide, tried the bundled shutdown.bat script which appeared to run but also left some java process running. I then manually did end-process-tree in Task Manager on that jave process. Upon restarting the ide there were no apparent errors but I'm back in the state where Run, Debug, etc. menu options are greyed out on all of my jsp files. I've been starting and stopping Tomcat, debugging jsp's, etc., frequently for a few days now with no problems. I have no idea what was different this time. My latest messages.log will be attached in a sec showing the past few ide start-ups, ending with the one in the current hosed state. There are exceptions throughout (which were not apparent in the ide) and apparently one new deserialization exception in this ide start-up. Chuck
Created attachment 18205 [details] Log file per last description entry, showing exceptions
OK, I have a log file with the debug switch on that started up in the hosed state where Run, Debug etc. are greyed out for jsp files. I'll attach that log next. Generally, this problem is only resolved by rebooting. I reached this state after first reaching the state where the ide can not shut down Tomcat. This has happened consistently for the past several ide sessions. In each case, I try to Stop Tomcat in the ide, the deployment monitor makes 0 progress (no green bars) and just sits there, then I close the deployment monitor, exit the ide, wait for it to fully shut down, and then physically end the Tomcat process tree with Task Manager (since the shutdown script does not stop the bundled Tomcat either, as reported earlier). After doing this several times (constantly in debug mode in the ide), this last startup landed me in the hosed state. Nothing is materially different this time vs. the prior times that I am aware of. One other possibly useful detail: the first session where the ide failed to stop Tomcat (in prior sessions it had been stopping Tomcat wtih no problems), the deployment monitor reported a little progress (4 or so green bars) and then hung. After it hung, I did my normal procedure as above to exit, bring Tomcat down, and then restart. For all subsequent sessions the deployment monitor reported zero progress. I shifted to debug mode right after this first failure to stop Tomcat, so that particular session was not in debug mode.
Created attachment 18210 [details] Another log file ending in session that lands in hosed state.
OK, the greyed menu is a duplicate of #48590, so I'd like to concentrate on the stop tomcat menu hung, which may be a duplicate of 49961. Haven't you been stopped on a breakpoint in a server when you tried to stop tomcat?
I have definitely not been stopped at a breakpoint when trying to stop Tomcat. I was in a clean running state, between requests (i.e., no request being processed). I believe the failure to stop has happened whether or not there was a debugging session active at all (i.e., whether or not I had just Run the server or was Debug'ing). Re. 48590, it says it was fixed mid-Septemberish. I'm getting the problem in last Friday's build (10/8 build). So if this is a duplicate, then 48590 should be reopened because it isn't fixed. Reading 48590, it does not seem like the same problem to me, but I don't know the internals. 49961 does look similar except possibly for the "rarely", and the 49961 reporters have not mentioned the subsequent more severe greyed-menu-item problem, which makes me wonder if that is a different problem.
My mistake. I meant 49914 instead of 48590. Sorry for confusion.
Aaaaah, sorry again. 49418 is the CORRECT number. Really. ;O)
Ahh, yes, it is likely the same as 49418, although I do not do any clicks during the initial parsing and it still happens. Looks like you guys are converging on it!
Hi, 49418 has been fixed last week, so please if you can, try to test with a fresh dev build. As for the tomcat stop problem, I've got some more questions. I think you write at the beginning that you are using external tomcat 5.0.18. Are you able to reproduce the same problem with the latest version (5.0.28, or 5.0.29)? Are you able to stop tomcat reliably from command line? What shutdown port does your tomcat have (server.xml)?
One more thing I'm not sure about. Does the tomcat stop problem happen only sometimes, or does it happen in 100% cases?
Re. 49418, my current Netbeans Session in the 200410141800 build has the greyed out Debug, Run, View Servlet, etc. menu items problem on jsp's. Re. Tomcat, I've been using the bundled 5.0.28. In addition to not being able to stop it from within nb, I have also tried the bundled shutdown script, which also fails to stop it. 49418 seems to indicate it was fixed on 10/11. Does this mean the fix should be in the 1014 build? If so, it is not fixed for me. Re. your last question about the consistency of failing to stop Tomcat, it's strange. When I first upgraded to 4.0B2, Tomcat stopped fine for a while. Then suddenly it stopped stopping (i.e., the hang problem arose). I have no idea why. Since then I have not been able to get back to a state where it would stop again. I've tried deleteing the var/cache to no avail.
49418 has been fixed on 15.10. so the fix is not in your build yet, it's in builds from 16.10. and later. Ad Tomcat - if you are not able to stop tomcat from command-line, too, then it's not netbeans bug (therefore downgrading), but a problem in tomcat or your app. Does it write some messages to the log or console when you try to stop it from command-line? Isn't it a problem e.g in your web application which is not able to clear some resources or does some infinite loop or something? Did you try with an empty userdir and empty tomcat install?
I'm pretty sure this is a Netbeans problem, so releveled back to P2, plus it seems from the below that a fix may be close and this problem is biting a number of us. I don't have a problem shutting down my app when I run completely external to Netbeans. I'm posting the latest message on this issue from the user list, where Peter Nabbefeld appearst to be onto something: The root problem seems to be the port 8009: It seems to be used for both tomcat instances (embedded and httpd-tomcat-standalone-installation). I'll try with port 8019 for external tomcat. However, a proper solution for this seems to be making the port number editable in the options panel. Kind regards Peter Nabbefeld Chuck Williams schrieb: >Peter's symptoms sound exactly like what I'm experiencing and have >reported in issue 49914, which Martin Grebac is working on now. >Peter's observation here is potentially material: > > > >>The suspicious thing is "INFO: JK2: ajp13 listening on /0.0.0.0:8009" >> >> >: > > >>The jk2 connection to apache httpd should not be used from embedded >>tomcat. I assume NB is trying to shutdown the tomcat service instead >> >> >of > > >>the embedded tomcat - which fails. >> >> > >I've just checked my Tomcat output and I'm getting exactly the same >INFO: JK2: line. See start-up output attached below. Martin, I >thought this might be useful to you. > >Chuck > >[...] > >
I wouldn't be so sure about the IDE bug, nor I think it's ajp problem. Are you using two servers together when you are not using IDE? If not, then that could be why you don't get the same problem. I tested this a bit. Even with two tomcat instances running (bundled and an external 5.0.28) no matter what jdk, I have no problem shutting down each of those successfuly. If I try to start another tomcat and the 8009 port is already in use by first one, I get this to the log: 19-Oct-2004 10:41:59 org.apache.jk.common.ChannelSocket init INFO: Port busy 8009 java.net.BindException: Address already in use 19-Oct-2004 10:41:59 org.apache.jk.common.ChannelSocket init INFO: JK2: ajp13 listening on /0.0.0.0:8010 so ajp port 8010 is used, but everything's ok. If you think it's ajp problem, then please provide some steps to reproduce, as I'm not able to.
Created attachment 18804 [details] Commit log
Developers and QE are not able to reproduce this bug. Proposed patch didn't help to the submitters. There will be probably 2 different problems. Downgrading to P3.
What is the basis for downgrading this to P3? It is completely reproducible on 2 separate machines now. I've offered to physically take a machine to a Sun office in the Bay Area if necessary. This is a serious problem for us. My fear is that downgrading it to P3 will cause it to not get fixed in NB 4.0, which will leave a fatal development productivity bug in the product from our standpoint. Many Netbeans ide functions do not work properly when the ide is 100% incapable of shutting down Tomcat, which is the case for us on two separate machine. Please clarify the situation. I've got other team members refusing to considering shifting to Netbeans from other ide's solely because of this problem. Thanks.
As I wrote it seems that there are 2 different problems (at least that's what developers think) - so it seems there are no 2 reproducible machines :-(. We are now in CodeFreeze milestone and we are still not sure if it is NB or Tomcat or Windows, etc. problem. I would prefer to solve this problem and if possible to put the fix to AutoUpdate Center later (if we'll find it NB bug).
manawiz, could you please check whether this is still a problem in 4.1 dev builds? Thanks.
This now works in Netbeans 4.1 beta, although I made another change simultaneously so I'm not sure which one fixed the problem. Previously, I had a port conflict on 8080 and so had the Tomcat http connector listening on 8084. I recently eliminated the service on 8080 and so with the upgrade to 4.1 left Tomcat http on 8080. So, more precisely, this problem is resolved at least on NB 4.1 beta with Tomcat http listening on 8080.