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.
I tried to debug a ServletContextListener but the debugger doesn't see the breakpoint although it was successfully submitted according to Netbeans 7.1(.1) I guess the ServletContext has already loaded before the debugger is active. On the other hand other breakpoints were also skipped ... A working web app can be debugged by hitting the debug button a second time without stopping the first debug attempt. Of course this workaround doesn't work for broken web apps.
IMHO the debugger is attached after the server starts up, therefore ServletContextListener is executed before debugger submits the breakpoint. I'll check whether the server startup parameters can be adjusted so that the debugger is attached before any code is executed...
Works for me in NB 7.1 and NB 7.2 dev builds. Breakpoints in contextInitialized(), attributeAdded() and sessionCreated() methods are hit for me when Tomcat server is starting as a result of "Debug" on the web project. Please provide a sample project, or detailed steps how to reproduce.
I have found that this issue only occurs when using a Maven Web Project. This was even the case after a clean (7.0,7.1.1,7.1.2) under Linux and Windows. Everything works when using a "normal" Web Project. Can you check this ? (In reply to comment #2) > Works for me in NB 7.1 and NB 7.2 dev builds. > Breakpoints in contextInitialized(), attributeAdded() and sessionCreated() > methods are hit for me when Tomcat server is starting as a result of "Debug" on > the web project. > > Please provide a sample project, or detailed steps how to reproduce.
I've reproduced the problem. Debugger is attached too late. It's because org.netbeans.modules.maven.j2ee.ExecutionChecker in performDeploy() calls Deployment.getDefault().deploy() first and *then* attaches the debugger. The debugger must be attached *before* the deployment. But it's not possible to simply call swap the calls, because Deployment.deploy() starts the server first (by targetserver.startTargets(mode, progress); call) and then performs the deployment: modules = targetserver.deploy(progress, forceRedeploy); The debugger needs to be attached in between these calls, IMHO. ANT project has the correct order: <nbstartserver debugmode="true"/> <antcall target="connect-debugger"/> <nbdeploy clientUrlPart="${client.urlPart}" debugmode="true" forceRedeploy="true"/> <antcall target="debug-display-browser"/> <antcall target="connect-client-debugger"/>
Downgrading to P3 since it has workarround and the use case is actually quite rare. You can start the server in debug mode (using Services/Servers/..right click on the server and Start in Debug Mode) and attach the debugger manually using menu Debug/Attach Debugger. After that you should be able to debug your application correctly. For the proper fix we will most probably need some API change in the Java EE Server support.
"me too" It seems to be a race condition. Sometimes breakpoints in my extended ServletContextListener will be hit and stop, but most of the time are ignored. Netbeans 7.1.1 Tomcat 7.0.22.0 Maven
this is still an issue netbeans 7.2.1 tomcat 7.0.32 Any chance to be repaired in 7.3 ? Maybe there is and workaround but it drastically drops usability.
(In reply to comment #7) > this is still an issue > netbeans 7.2.1 > tomcat 7.0.32 > > Any chance to be repaired in 7.3 ? Sorry, but no :( ..the NB7.3 final build is almost done and it's not possible to add more bug fixes. > Maybe there is and workaround but it drastically drops usability. To be honest I thought this isn't an important problem as debugging ServletContext sounds to me as rare situation. But you're right, there are already few votes for it, so I'll try to do this in the nearest patch (probably 7.3.1)
Removing 73patch-candidate, it does not make any sense now. Targeting to NB 7.4
Changes needs to be done in server infrastructure --> reassigning
API issue filed reassigning back. To verify later.
Closing as FIXED, works fine after Petr's fix. Thanks
*** Bug 228669 has been marked as a duplicate of this bug. ***