Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] JSP debugging

Andrew,
The server stores the source filename, path, and line number information 
into the SMAP when it translates the jsp/gsp into Servlet source and 
compiles the .class file.  JDT and our plug-ins aren't involved with this 
part. The debugger doesn't actually need the .class files since the JDI 
stack frame communicates the class' source filename and path information 
based on the SMAP.  When it comes to the path value, however, we're at the 
mercy of the server's translation engine as the path is underspecified in 
the JSR (see bug 99674 for the gory details).  The launch's source lookup 
director will still try to find the right file in the launch's projects 
based on this information.

Basically I think your biggest concern will actually be setting and 
clearing Java Stratum breakpoints with class values that "hit" 
consistently and path values that work for the source lookup.  Being able 
to use the Display/Execute/Inspect abilities that are available in the 
Java editor would be fantastic, but we haven't explored those features 
ourselves, yet.

Regards,
---
Nitin Dahyabhai
Eclipse WTP Source Editing and JSDT
IBM Rational




From:
Andrew Eisenberg <andrew@xxxxxxxxxxxx>
To:
Nitin Dahyabhai/Raleigh/IBM@IBMUS
Date:
07/15/2010 04:07 PM
Subject:
Re: [wtp-dev] JSP debugging
Sent by:
andrew.eisenberg@xxxxxxxxx



Thanks.

GSPs already have an SMAP set up properly.  The only tricky part (I
think) is telling the debugger where to find the line number
information.

How does the debugger know where to find the .class files for a jsp
file?  They are compiled at runtime, are they not?


On Thu, Jul 15, 2010 at 12:35 PM, Nitin Dahyabhai <nitind@xxxxxxxxxx> 
wrote:
> Andrew,
> Most of the trickier parts of JSP debugging support are handled in JDT
> using the SMAP section of the .class files according to JSR045; I expect
> it would also apply to GSPs.
>
> The editor's role in debugging within Eclipse involves providing a
> mechanism to set and edit breakpoints and showing the current line
> indicator.  For adding and removing breakpoints, we use our
> 
org.eclipse.jst.jsp.ui.internal.breakpointproviders.JavaStratumBreakpointProvider
> class.  The org.eclipse.jdt.ui.examples.javafamily project in the 
Eclipse
> CVS repository also has an example for that.  For editing breakpoints, 
the
> org.eclipse.wst.sse.ui.internal.debug.EditBreakpointAction class should
> work as-is.  The current line indicator should paint automatically if
> you're not doing anything unusual for your syntax coloring.




Back to the top