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.
Moving the breakpoint down several lines doesn't help -- the servlet breakpoint still ends up on the blank line. It seems that any breakpoint in the jsp in between the <% and %> tags has this behavior. If the JSP is changed so that the first line is on the same line as the tag, the breakpoint is correctly set on that line in the servlet. However, if I move the breakpoint to any subsequent line, the breakpoint is still on the first. Conclusion: No matter what line of code b/w the <% and %> is chosen for a breakpoint, the servlet puts the breakpoint on the line matching whatever is on the first line with the <% (meaning blank or the first line of code).
Created attachment 7660 [details] Sample jsp to demonstrate the problem
this JSP code: <% int a = 5; out.println("a is " + a + "<BR>") ; %> is mapped to this servlet code: // begin ["tomcat5/JSP.jsp";from=(7,2);to=(11,0)] int a = 5; out.println("a is " + a + "<BR>") ; // end you can see that 5 JSP lines is mapped to 4 servlet lines; because amount of JSP lines is higher than amount of servlet lines, we cannot find any reasonable mapping from JSP code fragment to the servlet code fragment that is why every JSP line from this fragment is mapped to the first line of the servlet fragment problem is the first line is empty, so breakpoint on this line is unusable work around is this: <% int a = 5; out.println("a is " + a + "<BR>") ; %> any suggestions how to fix it without servlet code reading?
Painful! I assume that we won't be responsible for the mappings anymore after we switch to JSP 2.0 and JSR 45 based servlet to JSP mappings (though it may be a good idea to draw attention to this potential problem to the reference implementation implementors). Damian, is there any way that we can find out if the line on which the breakpoint has been set is empty? If so, we could continue to the next line and so on until we find a non- empty line. This will slow down the mapping process obviously, but perhaps it's worth it for this behaviour which is very bizarre otherwise. In the meantime, Rochelle, does the workaround help with your problem? Ana
Not answering the right question here. Can it be fixed without looking at the servlet code? Weeellll... I assume that we will cease to provide our own line number mapper for JSPs pretty soon, so that we only have to do it for the versions of Tomcat that we already know about. In this case, I guess we know exactly what the mapping will look like, and you could determine, based on the JSP code, where the empty lines in the generated servlet will be, and you could attempt to set the breakpoint based on that. Ugly hack though, and you'd have to try a lot of cases to make sure it doesn't go wrong.
Ana, what workaround do you mean? So far I don't know of any.
I mean changing the code so that the <% is not on its own line, so that you write <% int i = 0; while(i < 10) { ... instead of <% int i = 0; ...
That only helps me if I want a breakpoint on int i = 0; If I want it on any other line (for example, the while (i < 10) line), it still places it on the int i = 0 line in the servlet. Therefore, what you mention is not a viable workaround.
It is possible to add a feature in the IDE debugger implementation (IDE code) that if user sets a breakpoint on empty line it will: 1) warn that br is on empty line 2) warn that br is on empty line and move the br on next non empty line, if it is possible 3) move the br on next non empty line, if it is possible 4) do nothing (current state) So we can solve this with the current JPDA APIs. There are 3 possibilities how to fix our bug: 1) improve usage of mapping from bigger JSP fregments to smaller servlet fregments by some heuristic methods (jsp debugger module) 2) improve/change granuality of JSP-servlet mapping (tomcat team) 3) empty line br will start to work in some way (debugger core team) The problem with number 1 is: heuristic methods will not never work for 100%.
debugger core team plans: 1) they will do nothing for NB40 2) for next release they will fix it that empty breakpoint will stop debugger on next non empty line, if it is possible
first of all I do not want to analyse servlet file lines if this possible the easiest fix can be: JSP lines in fragment will be mapped to same lines in the servlet fragment only last lines in the JSP fragments, which do not have proper mapping (because the JSP fragment is longer than the servlet fragment), will be mapped to lst line of the servlet fragment in our case it should really help and users maybe will not find this problem, because last lines in this case are not usually important
For what it's worth, I checked with the Tomcat team and it appears that the JSR45 line mappings have the same problem. From Kin Man: I afraid that our implementation suffers from the same problem. The reason is that the scriptlet is taken as a whole unit, and the line number mapping is only applied to the begining of that unit. In my opinion, the debugger should accept a breakpoint on a non-executable line, and break on the next executable line instead. It won't be too hard to fix this problem in this case: we just need to generate a mapping for each line in the scriptlet. However, that requires parsing the scriptlet that we don't do now, even if that is trivial.
We have the same problem with directives. <%! String myString = new String("Hello"); %> This is mapped correctly, but the following isn't. <%! String ana = new String("Polly"); %> Likewise if I declare a function, say: <%! String myMethod(String string) { return(string); } %> If I set a breakpoint on return(string) it is mapped to the first empty line under the Tomcat comment. For expressions, which are relatively likely to be inline, he following line kind of maps correctly: This is the value of <%=string%>. We get a map to out.println(string). However, if we map static content (as we do otherwise) then arguably this should be mapped to two lines, including the one that prints the static content also.
Ana or Martin, Do you think this qualifies as an issue that should be release noted? If so, could you review this proposed text for the note?: "Description: Breakpoints that are set between the <% and % > tags of a JSP are not mapped to the correct lines in the servlet. Partial workaround: In your code, do not put the <% and %> tags on their own line. Any breakpoints that you set on these lines will be mapped correctly. However, if you set breakpoints on lines between the ending and closing tags, the breakpoint will be mapped to the <% line in the servlet."
I'm OK with the description, even though the last part: '... will be mapped to the <% line in the servlet.' seems confusing to me. There is no '<%' line in the servlet, so how about something like '... will be mapped to servlet line corresponding to the '<%' line in jsp.' ?
Thanks Martin. Done.
Fixed in 3.6 - JSR45 works well in this case.
May appear in promoD.
What is promoD?
Promotion D is a promotion (release) of the CDP technology that will be released in Q3 CY2004. One of the goals of this promotion will be to support JSP source level debugging for S1AS 7 - currently we only support S1AS 8 and Tomcat 5.
In English, please =) -- should I remove my workaround for jsp's with this problem or not?
What's your workaround? It depends on the server. If you are using JSR45 compliant server (Tomcat5, S1AS8) in your *something* then you can remove it. If you use S1AS7 in your *something*, then do not remove the workaround, it will not work there.
My workaround is basically to have <% %> on every line instead of around the block. I'm working with a test case that debugs a JSP (I guess using the default server) and I try to run it with the NB 3.6 builds and Studio trunk builds. I think tomcat is always the default server in this case - is that right? If that's true, I should remove the workaround I think.
Yes, I think you may remove the workaround.
please confirm that this does not need to be release noted for 3.6
Yes, this shouldn't be release noted for 3.6.
This works with jsr45 servers so closing as fixed. Adding APPSERVER7 to sw field for tracking.
v.