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 don't know if it is in specification but when you have breakpoints in two web applications debugger is confused. - create web application 1 and run it - create web application 2 and run it - add breakpoint into index.jsp in both applications - debug main project (it should be webapp2) - continue when it stops at breakpoint - reload webapp1 in browser - it stops but green pointer is in index.jsp of webapp2 which is wrong Build 20050203-0717.
Jirko, could you please verify whether the issue #51901 somehow relates to this defect? Thx.
Possibly it is somehow related. But for me Step Into and Step Over works as continue. Note: Remember also the case when you attach debugger to a running server. There can be more than one application and breakpoints should work in all such applications.
*** Issue 51901 has been marked as a duplicate of this issue. ***
I did some tests...the good news is that debugger is stopping at correct breakpoint (e.g. local variables are shown correctly). The bad news is that a wrong file is shown to user. Debugger iterates over the source directories and looks for the _first_ occurence of the file retrieved from current call stack frame. It does not have any information about absolute path of the file where breakpoint is set, thus cannot differ between the same file names. I will consult it with JPDA debugger team.
Libor, any update on this issue?
Yes, a little one. I probably found the place which should be changed but don't have any idea how to do it without API change. I talked with Martin Grebac and he suggested to consult it with Hanz. The problem is following: CurrentThreadAnnotationListener is responsible for showing source and annotate the line where debugger is currently stopped at. It finds the source file with help of SourcePathProviderImpl.getURL(). From this method the _first_ matching directory is returned. But the first directory can be a part of incorrect project and then incorrect file is brought to user. Other views like Local view, Callstack view etc. contains correct values because they are not dependent on source placement but are static or depends on current callstack frame content. The solution: We should write our own SourcePathProvider implementation (we already have EngineContextProviderImpl, but it does almost nothing, so we should rewrite this class). If we don't want to duplicate code from the SourcePathProviderImpl class we must be able to share somehow the information with it. Maybe there is some possibility to listen on it but I am not sure. The current implementation seems like a big hack for satisfying JSP debugging requests, thus now I cannot expect any logical solution.
Removing fix-in-41 based on i-team agreement.
TM 5.0->TBD
reassigning to the jpda debugger team for evaluation, I am not sure whether it can be fixed w/o jpda debugger change, if possible at all. Maybe absolute path of the src file could be stored in the breakpoint object?
IMHO LineBreakpoint.getURL() must really return the URL in the first place. JSP violates the API contract by passing in a class filter. This prevents e.g. from fixing issue #61465 and issue #55663. Since JSP breakpoints need to provide the class filter, the appropriate methods need to be added. I propose: void org.netbeans.api.debugger.jpda.LineBreakpoint.setClassFilter(String) String org.netbeans.api.debugger.jpda.LineBreakpoint.getClassFilter() After this is done, you'll be able to distinguish the correct project from the URL.
Well, after issue #83188 was fixed, this seems to be fixed as well. Can you please verify? It looks like we do not have to do anything with issue #57095, right?
It doesn't seem to be fixed when you attach debugger (desc3). Try this: - create web application 1 and deploy it - create web application 2 and deploy it - add breakpoints to line 22 in both index.jsp - go to Runtime view and stop Tomcat server - start Tomcat server in debug mode - attach debugger to Tomcat (tomcat_shared_memory_id) - open web application 1 in browser - debugger stops at breakpoint in webapp1 - click continue - open web application 2 in browser - debugger stops at breakpoint in webapp1 which is wrong. Build NB dev 20060904-1018, JDK1.5.0_06, WindowsXP.
no surprise, path from the issue 83188 was not integrated into release55 branch ;) and also the JSP debugger code has not been modified to use new API yet. am I right, Martine?
I tested it in NetBeans dev build 20060904-1018. When an issue is marked as 'fixed' I expect it is fixed :-)
Yes, see my comment...btw, it cannot work in trunk build because AFAIK no change has been applied to jsp/debug client code to call new API. To clarify the issue status...this issue is regarding web/jspdebug module which is going to be part of NB55. it means that the state of this issue and other related issues like issue 57095 must considered according to release55 branch state. It means that it cannot be marked as fixed until it is really fixed in release55 branch. Martine, please integrate the patch of the issue 83188 into release55 branch. If you'd like to verify new API, please call it from jsp/debug module. Please attach jsp/debug module patch to this issue and I will verify it and integrate it. If it works I will also be able to resolve the issue 57095. Thanks.
1) I've followed the steps in this issue and it worked fine in trunk. It works when you debug the project. Breakpoints from all other projects are ignored. It can not work when the debugger is attached somewhere, because at that time *all* projects are sources and the debugger can not know which specific project do you mean to debug. 2) jsp/debug already calls the new API. See /cvs/web/jspdebug/src/org/netbeans/modules/web/debug/breakpoints/JspLineBreakpoint.java,v <-- JspLineBreakpoint.java new revision: 1.16; previous revision: 1.15 (viz issue #83188).
O.K., I was able to reproduce the problem now - when I attach to the server and deploy both projects, bad sources are opened for breakpoints that are hit. Starting to work on it...
Well, it can not be reasonably fixed IMHO, the debugger does not have the information about which particular project happens to be debugged. Even if I somehow match the breakpoints and open the correct file according to the breakpoint's URL, I do not have this information for other actions, like steps, method/field breakpoints, etc. Therefore in general when the debugger is stopped somewhere, all I get is the *relative* path to *some* root. But I do not know the root. So currently just some root is chosen randomly - this is not really nice, but it can be configured in the Sources View. The user should select/unselect the projects they want to debug. We plan to make some redesign of the sources management into 6.0, because there are some usability problems associated with the current design - see issue #61777, issue #60640 and issue #54358. This problem will be taken into account in the redesign, but I'm afraid we can not do much into 5.5.
OK, if you are able to fix it in NB6.0, please let this issue open until it is fixed.
O.K., so it's a dupl. of issue #54358. *** This issue has been marked as a duplicate of 54358 ***
Verified.