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.
Reproducing steps: 1. Create web module with a jsp in it. 2. Place a breakpoint. 3. Start debug. Result: debugger stops, but it writes 'Breakpoint reached on line ? in ... " and does not open the corresponding servlet. Expecting: debugger stops, opens the servlet (or jsp), annotates the current line, and writes 'Breakpoint reached on line (e.g.) 53 in file ... " I spent quite a time on this trying to find problem in jsp debugging line mappings, when I found out that it's a regression caused by fix of #27739 (in Utils and JUtils). You are ignoring hidden filesystems (returning null instead of lineset), but that's what web module uses for servlets.
This is "as designed" for me. The contract is that I do not debug files from hidden filesystems. Can you "unhide" your filesystem? The correct solution is to add a new capabilities: "visible in explorer" "show during debugging", but I am not sure if we can change it to the next release.
So based on a discussion with other webteam members, I'm reopening the bug and raising the priority to P1 since this is a regression. And as for the offered suggestions, they are not acceptable for us, because (at least) we already passed the UI freeze date. However, for later releases, I agree the additional capabilities in the filesystem would be useful.
You probably do not understand THE problem. If I change it (rewrite impl. to show files from hidden filesystems) another P1 will occur. So its not a solution. Your implementation is hack - you assume somethink what is not defined and logicall. At least I can not find some definition what FS.isHidden property should mean for debugger. So I am asking you: 1) try to remove this hack on your side - put your sources on some not hidded fs or 2) try to find some other correct way how to fix it - like add some other capability to fs, ... or 3) try to implement some other hack on your side which will solve this problem or 4) suggest some other solution
Reopening the bug, until we find a reasonable solution that works for Java and JSP debugging. This is a regression caused by latest integration in debugger and needs to be tracked. It's a potential Q-build stopper, because it disallows JSP debugging and it's going to have a big impact on functionality.
Well, as a suggestion - do we really need a new FS capability? Couldn't the existing DEBUG capability be used for this purpose? The src.zip with java sources does have the DEBUG capability set to false, and our hidden filesystems have the DEBUG capability set to true. So I think this is the way it could work for both, and it would be more logical either. Or am I missing something?
DEBUG capability is for something different. It means: "should be this fs on classpath for debugged process". But may be its one possibility, if we do not find better solution... BTW what about nb4.0. Will you have some regular solution?
As for the NB 4.0 solution: We expect there will be a Java root (created by us), which will contain the generated Java files. Since these files are not considered a part of the user's sources (they are not stored in VCS, they are server-dependent etc.), the Java root will somehow be hidden (this needs to be negotiated with the Java module team). In spirit, this is similar to the current situation, when the filesystem containing generated files is hidden. Note that hiding the filesystem is NOT a hack on our side, it is hidden by design.
Fixed on my side. I have added: GUIManager.DEBUG_SRC - see JavaDoc comment and JavaDoc for openide filesystems for more info how to use it.
Fixed in trunk on my side, too. Waiting for Hanz's integration into qbuild branch. Btw, the javadoc comment is really consistent with the rest of the filesystem api doc ;O) - words 'well known' are for sure the right ones to use in documentation.
Everything's commited in q-branch, too.
Verified with current Netbeans dev build (200302191342).