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.
It is not possible to debug web application with Glassfish target server. To reproduce: - go to Runtime view and add glassfish server (9.1 b36-rc) - create web application project - toggle breakpoint at line 22 - start debugger - debugger stops but it doesn't show Call Stack, Local variables and green current line annotation in editor. It seems debugger got stuck (see thread dump). In debugger console is the following Attaching to localhost:9009 User program running Breakpoint reached at line 61 in index.jsp by thread httpSSLWorkerThread-8080-0. Build NB5.5.1 20070302-1013, JDK1.5.0_10, WindowsXP, Glassfish 9.1 b36-rc.
Created attachment 39118 [details] Thread dump when debugger claims to be at breakpoint.
Jirko, does the debug work with AS 9.1 build 33e that is AS 9.1 Beta? Thanks.
With b33 debugger doesn't stop at breakpoint at all (issue 88744).
Debugging with b33 works.
I tested this with AS 9.1 b33e and it works for me.
This is a bug at org.netbeans.modules.j2ee.sun.bridge.apis.AppserverMgmtContainerNode$ContainerChildren$1.run(AppserverMgmtContainerNode.java:119) It uses Default RequestProcessor to handle some socket communication, which apparently takes a long time. Because it uses the shared Default Request processor, all other modules using the same request processor are blocked. This is also the case of org.netbeans.api.debugger.DebuggerManager.startDebugging(DebuggerManager.java:337). The default RP should not be used for long-running tasks, because it blocks all other modules. A custom RP should be created instead.
Martin, thanks for the evaluation! Assigning to Vince - this ca be fixed on his side.
attempting to dup in trunk
could not dup in trunk
cannot dup on a slow machine.. 2x2ghz powermac g5 may be a mac jdk difference, though... it is jdk 5.0_07... I can easily reproduce this on my M2.
Has anyone else been able to duplicate this issue in the trunk?
I haven't applied a change for this, because I am seeing thread dumps like the one I just attached... The plugin isn't in there... except for waiting on the server log to get more content... I saw thread dump like it yesterday while I was testing with Martin's suggested fix (use a private RP instead of the default).
Created attachment 39265 [details] another thread dump
One other things that I noticed... it looks like the 'I am at a BP bit' is NOT getting set in the Session object for the server. This is in spite of the fact that the status line says 'Breakpoint reached at...'. Since the 'bit' isn't set this causes all kinds of grief in the plugin...
waiting for feed back from mentlicher. reassigning to mentlicher.
There is a similarity between the thread dumps in this issue and the first thread dump in issue 92771
I can not reproduce this, even after several reinstalls of the glassfish server can not start it. It allways fails: Application server startup complete. executePhase(RESTORE_VIEW 1,com.sun.faces.context.FacesContextImpl@1a5d6d6) threw exception com.sun.jsftemplating.layout.SyntaxException: Handler 'setResourceBundle' in event 'beforeCreate' is not declared! Ensure the '@Handler' annotation has been defined on the handler Java method, that it has been compiled with the annotation processing tool, and that the resulting 'META-INF/jsftemplating/Handler.map' is located in your classpath (you may need to do a clean build). at com.sun.jsftemplating.layout.template.TemplateReader$EventParserCommand.readHandler(TemplateReader.java:842) ...
Aha, it depends on NetBeans version! Reproduced in 5.5.1 beta build. I'm updating 5.5.1 sources and will try to reproduce in my own build...
This is in fact a duplicate of issue #75902. This simple change fixes this issue: Index: StartActionProvider.java =================================================================== RCS file: /shared/data/ccvs/repository/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/StartActionProvider.java,v retrieving revision 1.18.2.2.2.1.22.1 diff -u -r1.18.2.2.2.1.22.1 StartActionProvider.java --- StartActionProvider.java 15 Jan 2007 14:58:42 -0000 1.18.2.2.2.1.22.1 +++ StartActionProvider.java 13 Mar 2007 17:02:10 -0000 @@ -115,7 +115,10 @@ lookupFirst (null, JPDADebugger.class); if ( debugger != null && debugger.getVirtualMachine () != null - ) return; + ) { + actionPerformedNotifier.run(); + return; + } final AbstractDICookie cookie = (AbstractDICookie) lookupProvider.
I am starting a build and will integrate this patch. will update asap.
I applied this patch and it appears to have resolved the issue in the thread dumps.
Fine, but it is still not fixed in release551. As soon as you integrate it, I will verify it.
It's fixed in 6.0 according TM.
Review: The fix is safe enough for integration into NB 5.5.1.
Thanks for the review and verification, the fix is committed into release551 branch: /shared/data/ccvs/repository/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/StartActionProvider.java,v <-- StartActionProvider.java new revision: 1.18.2.2.2.1.22.2; previous revision: 1.18.2.2.2.1.22.1
Verified in build NB5.5.1 20070314-1939.