Community
Participate
Working Groups
In our project, the JSPs belonging to different projects are in different folders, but share the same name. e.g. there is gui/comp1/test.jsp as well as gui/comp2/test.jsp Looks like when I set the breakpoint on line 10 of gui/comp1/test.jsp, and invoke gui/comp2/test.jsp; the debugger actually stops at the line 10 of gui/comp2/test.jsp I noticed this behavior in WTP-1.0M4
*** Bug 99676 has been marked as a duplicate of this bug. ***
Nitin, can you assess and see if on our end, or on "source lookup" end?
Changed Version field given new release numbering.
While a bad problem, given this doesn't "block use" of the general release, any fix for this bug is, I believe, too risky to make at this point for 0.7 ... so, we'll attend to this bug next release. If you disagree or believe there is something "blocking" here I am not seeing, please comment. We have investigated enough to know there is no easy fix that works for all server containers (since they can and do use different "paths" when they translate the JSP to a Java file). I suspect we will either have to add a "target server" sensitive notion of breakpoint (which is not good) or we'll have to detect when there are multiple potential matches, and ask user which is the right one (also not great). We will continue to investigate better fixes, but these would probably require some improvments in the base debugging infrastructure.
I'm unable to find any way to control the source lookup order for JSPs My scenario: * Have a source directory * intermediate build directory * runtime directory I edit and set breakpoints in the files in the source directory, but when debugging via remote VM (Starting using an external Tomcat loader) it is usually the intermediate build copy of the file that is opened. I would expect the file system copy fo the JSP loaded at runtime by tomcat, or the JSP where I set the breakpoint, to be the one loaded, not the one in some other directory that just happens to be in my workspace. I expect that I should have some way to see, if not control, the deterministic logic used to open JSPs during debugging, but I cannot find such a control.
Ah, sorry. Just realized from bug 151446 comment #4 that my source lookup is determined in my remote VM config, so my problem is resolved and not related to this bug.
I emailed Nitin directly about this bug and he advised me to add my info to this bug, below are snippets of our conversation: ********************************************** From what I’m seeing, your statement “My understanding is that this only applies to two files with the same name within the same web application” is not correct. I have two separate Web apps defined as different eclipse projects, one of which is largely an edited copy of the other, so they share many of the same file names. In debugging, Eclipse keeps track of class files with the same name properly, but as soon as the class hands off control back to a JSP, the FIRST matching file name in the project list appears in the debug perspective. I did find something of a workaround. If I declare a project “inactive”, then the debugger finds the next matching file name. Since we have 4 websites all using our “framework” (its not really a real framework but that’s the best name we could come up with), I have to inactivate the 3 I’m NOT working with in eclipse to get the debugger into the proper JSP file. I am using the Sysdeo tomcat plugin, which I suppose adds another wrinkle… **************************** Nathan, My understanding is that this only applies to two files with the same name within the same web application, or at least with the same build path, Deployment while testing works differently in 1.5 than in 1.0, so the odds of this happening are reduced (it used to be an issue with the .deployables folder). For now it's still a limitation in terms of the JSR not defining how to represent the JSP's file path when the breakpoint is triggered; the determination of that value varies server to server. ********************************************* Nitin, I just downloaded Calisto and loaded up the WTP, and this bug has not been fixed. Any word on when we might see a fix for this bug? We use a framework that we simply copy and then edit whenever starting a new site so we have lots of jsps with the same file name...this really causes problems with JSP debugging. Short of changing the matching file names, do you have any suggestions to work around this bug?
The real problem appears to be how the JDI stack frame's source is found and shown. When a JSP is run on the server, the app server converts it into the source for a Java Servlet, compiles that, and with the rules in JSR-45, appends a source map indicating which lines from which JSP files match the lines in the Java source. From what I can tell, the source file path returned by org.eclipse.jdt.internal.debug.core.JavaDebugUtils.getSourceName(Object) for that stack frame is the source path set in the map by the app server. With Apache Tomcat 5, for example, it's the path relative to the web application context root, not the path or location of the file in the workspace, or even where it's being run from on disk. This value is optional, however. There's no requirement that it be in the map, nor a fixed requirement of how it is to be interpreted. The JSR only says it "is a path name (often relative to one of the compilation source paths)". For an app with /app/WebContent/1/test2.jsp, I get this map from Apache Tomcat 5.0.28: SMAP test2_jsp.java JSP *S JSP *F + 0 test2.jsp 1/test2.jsp *L 1:42 2:43,2 *E So, assuming we'd have some pathing information, the Server Tools could use a custom ISourceLookupDirector with a ISourceLookupParticipant capable of taking the source path and returning the JSP file that has that as its suffix, but that wouldn't solve the problem for folks using the another launcher or with servers that don't report a usable path. I don't think this is a problem the editor can solve. CCing Tim for comments.
Thanks for the detailed description, Nitin. Unless I'm mistaken, the web app name ("app" in your example) isn't in the map though, is it? Even if a server follows the JSR's option and includes a path name 'relative to one of the compilation source paths', there isn't enough information here for the server/server tools to do a better job of this. To differentiate between the two JSPs we'd need the web app name or context root to figure out which project it belongs to. If you do see this information somewhere, please feel free to pass this to server tools and hopefully there is something we can do. If not, then I think we're stuck - it doesn't look like the spec provides enough info for us to resolve which module it belongs to and users will have to use different names, or use a workaround like temporarily closing the other projects or removing them from the server.
CCing Nick as he's been investigating behavior with a different server than Tomcat, which looks like it's using its own source director (meaning the results are entirely different from what's recorded in comment 8).
Hello, our projects contain a lot jsp's with the same name in differnt folders. E.g. index.jsp, detail.jsp, edit.jsp, and so on. The described bug makes it impossible for us to debug any of those files. So it's almost impossible to debug any project. Since years we have to debug those files with the ancient style of writing output to the console (System.out.println()). Obviously it's very difficult to automatically find out the correct file for debugging. But David M Williams wrote on 2005-07-24 19:41:16 EDT: "or we'll have to detect when there are multiple potential matches, and ask user which is the right one (also not great)." Maybe that's "not great", but it's still a solution to handle this problem somehow. Another "quick&dirty" solution would be to first look in the currently open editors for a jsp with a matching name before opening a matching random jsp of the workspace. That would be a great "quick&dirty" solution and probably quite easy to implement. I don't understand, why this bug has the importance "P4 major". I think, this is a clear "P1 Blocker" - and that since years! Please, please do something! Thanks!
(In reply to comment #11) > Maybe that's "not great", but it's still a solution to handle this problem > somehow. > > Another "quick&dirty" solution would be to first look in the currently open > editors for a jsp with a matching name before opening a matching random jsp of > the workspace. > That would be a great "quick&dirty" solution and probably quite easy to > implement. I don't believe there are ways to hook into those parts of the UI. Deciding which file to open isn't something we can even attempt to address within Source Editing --we're just providing the editor that happens to be opened by default for the .jsp source file type. > I don't understand, why this bug has the importance "P4 major". > I think, this is a clear "P1 Blocker" - and that since years! There is a limitation of the JSR specification poorly defining how the file's path is represented, and not even requiring it to be there. When the breakpoint is triggered, there is not enough information to know for certain which file in the IDE contains the source that should be shown. See comment 8.
(In reply to comment #12) > > Another "quick&dirty" solution would be to first look in the currently open > > editors for a jsp with a matching name before opening a matching random jsp of > > the workspace. > > That would be a great "quick&dirty" solution and probably quite easy to > > implement. > I don't believe there are ways to hook into those parts of the UI. Deciding > which file to open isn't something we can even attempt to address within Source > Editing --we're just providing the editor that happens to be opened by default > for the .jsp source file type. I'm for example using an eclipse plugin (Name: "Editorlist"), which has access to the list of the currently open editors and their edited files (with full pathname). So it should be possible for the debugger, to look up this list as well. So it would be a great quick&dirty solution, if the debugger checks this list first, before it opens a random file with matching name. > There is a limitation of the JSR specification poorly defining how the file's > path is represented, and not even requiring it to be there. When the > breakpoint is triggered, there is not enough information to know for certain > which file in the IDE contains the source that should be shown. See comment 8. But checking first the mentioned list of files from open editors would help a lot. That's not a perfect solution - the bug would be still there, but it provides a usable workaround...
(In reply to comment #13) Another way of finding a good file hit: If the debugger stops in a jsp because of a breakpoint, the target file must be listed in the breakpoint list. So in that case (debugger stops at breakpoint) taking a file with matching name from the breakpoint list is much better than taking a random file with matching name from anywhere in the workspace. In any other case the mentioned list of open editors is still a good help for using a workaround.
(In reply to comment #13) > (In reply to comment #12) > > > Another "quick&dirty" solution would be to first look in the currently open > > > editors for a jsp with a matching name before opening a matching random jsp of > > > the workspace. > > > That would be a great "quick&dirty" solution and probably quite easy to > > > implement. > > > I don't believe there are ways to hook into those parts of the UI. Deciding > > which file to open isn't something we can even attempt to address within Source > > Editing --we're just providing the editor that happens to be opened by default > > for the .jsp source file type. > > I'm for example using an eclipse plugin (Name: "Editorlist"), which has access > to the list of the currently open editors and their edited files (with full > pathname). > So it should be possible for the debugger, to look up this list as well. > So it would be a great quick&dirty solution, if the debugger checks this list > first, before it opens a random file with matching name. > > > > There is a limitation of the JSR specification poorly defining how the file's > > path is represented, and not even requiring it to be there. When the > > breakpoint is triggered, there is not enough information to know for certain > > which file in the IDE contains the source that should be shown. See comment 8. > > But checking first the mentioned list of files from open editors would help a > lot. > That's not a perfect solution - the bug would be still there, but it provides a > usable workaround... Unfortunately, I don't think we have control over which editor gets opened. I think it's strictly the debug tools. And I don't know if it'd be in their best interest to follow this heuristic of checking the open editors. The debugger developers might have more input to the matter. Again, I'm not sure if there's much for us to do. But we appreciate the dialog.
As mentioned in the comments (specifically comment 12), from a Source Editing perspective, there's nothing we have control over to correct this. If a heuristic like checking for matches in open editors is really the best bet, it would have to come from the Debugging tools. For these reasons, we will not be pursuing a fix in Source Editing.
