View source for JSDT/Debug/FAQ

{{JSDT-Debug}} 

== Overview  ==

This page contains a collection of common questions and answers and common problems and possible solutions. 

Check back often, new content will be added regularly. 

== Where is the Source?  ==

Depending on the version of JSDT you have installed, locating the remote source in your workspace can be a bit tricky. 

In all versions of JSDT debug the source from remote debug sessions is stored in the '''External JavaScript Source''' project in your workspace. This project is created for you automatically when remote debugging to store script source. The source arrangement in the project and the visibility of the project itself differs in versions of JSDT 1.3.x and later. 

==== Pre 1.3.x External Source  ====

In JSDT debug versions less than 1.3.x the source is stored in the '''External JavaScript Source''' project, with the quirk being that the project is filtered from explorer views by default. To make the project visible you have to change the filter settings for the view you want to see the project in. For example in the '''Package Explorer''' you would navigate to the '''view menu &gt; Filters...''' action and in the resulting dialog, un-check the '''External JavaScript Source''' filter. 

Now that the '''External JavaScript Source''' project is visible you can browse the folders in the project and see the source for any scripts you have debugged remotely. You will notice that the source is arranged in the project in sub-folders that are named using the hash codes of the strings from the URI for the script. At the time this was intentional as we planned to always hide this project from users, but as you can image it is almost impossible for users to understand where to find their remote source without searching for it. The other catch in the pre-1.3.x external source story is that the '''External JavaScript Source''' project is always deleted when the workbench is shut down. 

Realizing that this source story was sub-optimal we sat down and completely re-designed it to be more user friendly. 

==== 1.3.x External Source  ====

To combat the non-user-friendly source story from pre-1.3.x JSDT we made the following major changes: 

#The '''External JavaScript Source''' project is always visible in all views that show project by default 
#The '''External JavaScript Source''' project is no longer deleted when the workbench shuts down. The project can be deleted when the workbench shuts down if you want it to; the option to do so is controlled using the ''Delete External JavaScript Source project on workbench shutdown'' preference on the '''JavaScript &gt; Debug''' preference page. 
#The source is now saved in the '''External JavaScript Source''' project based directly on the URI from the script. For example <code>http://www.mozilla.com/js/jquery/jquery.min.js</code> would be saved in the project like: <code>External JavaScript Source/www.mozilla.com/js/jquery/jquery.min.js</code>.

<br> <gallery> widths="300px" heights="150px" perrow="1">
Image:Ext_js_src.png|The 1.3.x External JavaScript Source project
</gallery> 

==== Getting Source Lookup to work  ====

This bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=328531 causes the source lookup to fail for various reasons. There is a workaround for this problem.
#When compiling/interpreting your script in Rhino there's a 'scriptName' parameter that you supply. To make the source lookup find your source this parameter must equal the full path to your script's source. 
#In the client (Eclipse), in the debug configuration screen for your Rhino remote debugger go to the "Source" tab, and Add the project where your script's source resides. 
#To make sure the process worked, connect to the debugger, and try to set a breakpoint in Eclipse. If you see in the transport (prints to STDOUT assuming the debugger was initialized with "trace=y") a "setbreakpoint" request, that means the client was able to attach the local source to the one running in Rhino.
Note that you'll see this request only after you see the script in the "scripts" list. If it's not there then it hasn't been compiled/interpreted yet. In this case the setbreakpoint will be sent upon script load only if source lookup succeeded. Going to Eclipse preferences -> Javascript -> Debug and checking "suspend for all script loads" will cause the debugger to suspend when each script loads and you can make sure script lookup worked.
It is also possible to check success by right clicking the script in the script list and choosing "open source".


== Can I See Loaded Scripts? ==
Yes!

To view what scripts have been loaded in the VM simple use the 'Show All Scripts' action in the Debug view.

Activating this action will place a 'Scripts' node in the tree, which contains all of the scripts currently loaded in the VM.

<gallery> widths="600px" heights="150px" perrow="1">
Image:All_scripts.png|The Scripts node for a Crossfire VM
</gallery>