Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [atf-dev] Breakpoint matching in the ATF debugger


Giuliano

The standard for URL mapping to Project/File layout is based on the project type. The WST server code support specifying a deployable object for a project type that determines how a project is deployed out to a server. WST Static and Dynamic Web project (An Ajax project is a Static Web project) have one convention which have been defined by the WST team.

The Static and Dynamic convention is the following.

<Web content root>/<Path below the Web Content directory>

By default the Web Content Root is the project name, but doesn't have to be the project name. It is defined when a project is created.

The ATF code also supports deploying a PHP project and we use a different convention. The ATF team implemented the deployable object for a PHP project.

<Project Name>/<Path of the files is the project>

ATF also supports debugging remote files on a server. In that case we use the URL for the file is the id in the breakpoint. There is a flash movie at http://www.eclipse.org/atf/flash/index6.php that show how to do remote debugging. The eval support should work for remote debugging also.

The ATF infrastructure already has code to do the matching you described. Look at JSDebugThread#onScriptCreated and follow thru the call to JSDebugTarget"establishBreakpoint. There is code does the mapping you described. We also use the code when we open the file in the editor and highlight the line when the breakpoint is hit. I would also trace through the code for doing this.  I would think you would be able to use to code without changing it. At least any changes should do be in these files. I haven't looked if these files need be changed for eval support. We had discuss doing some of the things John describes, even in the non-eval case, but didn't have time to implement. We end up search through the list of breakpoint more than we need to, since we have implemented any such schemes.

    Thanks
      Bob



Robert Goodman
goodmanr@xxxxxxxxxx



"John J. Barton" <johnjbarton@xxxxxxxxxxxxxxx>
Sent by: atf-dev-bounces@xxxxxxxxxxx

01/07/2008 10:13 AM

Please respond to
AJAX Toolkit Framework discussion <atf-dev@xxxxxxxxxxx>

To
AJAX Toolkit Framework discussion <atf-dev@xxxxxxxxxxx>
cc
Subject
Re: [atf-dev] Breakpoint matching in the ATF debugger





Giuliano Mega wrote:
> Greetings,
>
> My name is Giuliano Mega, and I am currently doing some work on the
> ATF debugger. :-) I am a committer at the Google Summer of Code Project,
> where I've implemented an Eclipse debugger for distributed object
> applications (http://god.incubadora.fapesp.br/portal).
>
> My current objective with the ATF debugger is to get eval support
> working well (already checked out the eval_support branch), and to
> that end I have been working on getting some automated tests in place
> (including a failing test case for eval).
>
> During the course of that work, I realized that
> JSDebugThread#getBreakpoints is not functional, so I am trying to
> implement it. I am having some trouble, however, with matching the
> information that the Mozilla engine provides with what's available from
> the IBreakpoint instances.
>
> It seems that it is not possible to ask the engine to assign a unique ID
> to each breakpoint, so the only way to get this working, as far as I can
> tell, is trying to match the path structure of the URL returned from
> jsdIStackFrame#getScript#getFileName against the path structure of the
> resource returned from IBreakpoint#getMarker#getResource. Right? :-)
Right, except when it's not ;-).  The Mozilla engine labels eval buffers
with the
file name of the function that calls eval(). These line numbers overlap
the original file.
So for breakpoints in eval() buffers you can't use this approach.

What I did in Firebug 1.2 was create a covering object for each
compilation unit.
(eg file, eval-buffer, event-buffer). Each unit has a unique id, a
URL-like string. For
files, the ID is the jsdIScript.fileName; for eval buffers its the
jsdIScript.fileName plus
"/" plus the MD5 hash of the source in the buffer. Just after a unit is
compiled, I look thru the
list of breakpoints for any that apply to this unit.  If yes, I set the
breakpoint on the jsdIScript.

If you want to look at the Firebug source, you can probably make sense
of it by working
back from the mozilla APIs calls shared with your project. If you do,
for sure use
http://fbug.googlecode.com/svn/branches/firebug1.2
as this code makes much more sense than the 1.1 version.  At least I
hope ;-)
>
> Unfortunately, the structure of the URL doesn't exactly mirror the path
> structure of the resources in the workspace. For instance, when I get an
> URL "http://localhost:8080/DebugTests/test.js", it refers to file
> "workspace/DebugTests/WebContent/test.js".
>
> So, I was wondering. Is it safe to assume that this transformation is
> regular, I mean, that it's always performed in the same way for all
> servers we may want to debug on? If so, then the problem is easy to
> solve, and my current implementation will work fine. If not, then is
> there a standard way to know which kinds of path manipulations has the
> deployment process performed?
I created my own solution for this in fireclipse; any solution will be
http-server dependent,
but eclipse could and should offer a standard mapping for all
eclipse-embedded or
configured servers.  You may need to ask on one of the Wxx eclipse forums.

John

--
______________________________________________________
John J. Barton  email:  johnjbarton<at>johnjbarton.com  
http://www.johnjbarton.com

_______________________________________________
atf-dev mailing list
atf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/atf-dev


Back to the top