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.

Bug 28004 - Breakpoints in <% %> are not correctly mapped to servlet
Summary: Breakpoints in <% %> are not correctly mapped to servlet
Status: VERIFIED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Debugger (show other bugs)
Version: -FFJ-
Hardware: Sun Solaris
: P2 blocker (vote)
Assignee: Martin Grebac
URL:
Keywords:
Depends on: 15994
Blocks:
  Show dependency tree
 
Reported: 2002-10-14 20:14 UTC by Rochelle Raccah
Modified: 2004-08-12 14:47 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Sample jsp to demonstrate the problem (330 bytes, text/plain)
2002-10-14 20:15 UTC, Rochelle Raccah
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rochelle Raccah 2002-10-14 20:14:34 UTC
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).
Comment 1 Rochelle Raccah 2002-10-14 20:15:28 UTC
Created attachment 7660 [details]
Sample jsp to demonstrate the problem
Comment 2 Damian Frach 2002-10-15 11:01:54 UTC
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?

Comment 3 Ana.von Klopp 2002-10-16 17:06:12 UTC
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
Comment 4 Ana.von Klopp 2002-10-16 17:13:12 UTC
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. 

Comment 5 Rochelle Raccah 2002-10-16 18:17:59 UTC
Ana, what workaround do you mean?  So far I don't know of any.
Comment 6 Ana.von Klopp 2002-10-16 19:00:59 UTC
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; 
...

Comment 7 Rochelle Raccah 2002-10-16 19:18:50 UTC
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.
Comment 8 Damian Frach 2002-10-18 10:22:41 UTC
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%. 
Comment 9 Damian Frach 2002-10-18 10:26:57 UTC
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
Comment 10 Damian Frach 2002-10-18 10:38:28 UTC
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
Comment 11 Ana.von Klopp 2003-01-09 00:14:01 UTC
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.


Comment 12 Ana.von Klopp 2003-03-08 01:30:17 UTC
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. 




Comment 13 Patrick Keegan 2003-04-03 15:38:58 UTC
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."
Comment 14 Martin Grebac 2003-04-10 07:23:46 UTC
 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.' ?
Comment 15 Patrick Keegan 2003-04-10 20:04:12 UTC
Thanks Martin. Done.
Comment 16 Martin Grebac 2004-01-13 21:22:00 UTC
Fixed in 3.6 - JSR45 works well in this case.
Comment 17 L Martinek 2004-02-03 17:58:02 UTC
May appear in promoD.
Comment 18 Rochelle Raccah 2004-02-05 19:33:09 UTC
What is promoD?
Comment 19 Petr Jiricka 2004-02-06 07:43:24 UTC
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. 
Comment 20 Rochelle Raccah 2004-02-06 08:01:29 UTC
In English, please =) -- should I remove my workaround for jsp's with 
this problem or not?
Comment 21 Martin Grebac 2004-02-06 08:07:47 UTC
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.
Comment 22 Rochelle Raccah 2004-02-06 08:15:16 UTC
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.
Comment 23 Martin Grebac 2004-02-06 08:16:40 UTC
Yes, I think you may remove the workaround.
Comment 24 Patrick Keegan 2004-03-03 22:29:54 UTC
please confirm that this does not need to be release noted for 3.6
Comment 25 Martin Grebac 2004-03-04 08:10:11 UTC
Yes, this shouldn't be release noted for 3.6.
Comment 26 Martin Grebac 2004-07-26 13:25:25 UTC
This works with jsr45 servers so closing as fixed. Adding APPSERVER7
to sw field for tracking.
Comment 27 L Martinek 2004-08-12 14:47:17 UTC
v.