|
|
|
|
|
|
|
Re: Remote Rhino debugging - Exception inside eclipse when evaluating JavaScript [message #648857 is a reply to message #648330] |
Fri, 14 January 2011 18:21 |
Michael Rennie Messages: 67 Registered: July 2009 Location: Canada |
Member |
|
|
> 1. It can't find my sources, I've got the exact same problem
> the guy in this thread.
If the debugger is suspended at a script load, there will be no stackframe selected, so at this time, no source. If you notice in the debug when suspended at a script load the Step Into button is enabled, so you can step into the script, which will return you a stackframe and source. If this does not happen, check the log, perhaps there was a problem getting the source from your server.
> what I don't get is what does suspending at script load gives
> me? It still doesn't find my sources...
When you have it set to suspend on a script load, the debugging will pause execution as soon as Rhino has loaded the script. The script has not been run yet, Rhino is paused right before the script is about to run. At this point as mentioned above, you can step into the script to debug it right as it is being run.
if you have a stackframe selected the source should shown to you in the editor, if not you can check the 'External JavaScript Source' project that is automatically created in your workspace. The project might be hidden, so to check if it is there (in versions < 1.3) go to the view menu for the package explorer and select the Filters menu item. In the resulting dialog, uncheck the filter for 'External JavaScript Source'. In the latest versions of JSDT the project is not hidden and does a much better job of organizing source than using hashcodes.
> How can I update JSDT on a clean J2EE copy? or any
> eclipse that already has jsdt installed for that matter.
I have always found that using the update site: http://download.eclipse.org/webtools/updates works well for getting the latest official release of JSDT, to get the latest dev releases you can use the links you mentioned, or get the source and launch a target workspace, or install into your host.
I should note there is a known problem with breakpoints and relative paths from remote servers. The bug in question is https://bugs.eclipse.org/bugs/show_bug.cgi?id=328531 and I am evaluating the patch for that now.
I am going to write up some more wiki pages talking about source, breakpoints, etc, these are all excellent questions that I am sure many other people have as well.
|
|
|
|
Re: Remote Rhino debugging - Exception inside eclipse when evaluating JavaScript [message #648956 is a reply to message #648158] |
Sun, 16 January 2011 15:35 |
Enrico Magen Messages: 15 Registered: September 2010 |
Junior Member |
|
|
Hey Michael, thanks for the responses!
I am definitely experiencing the effects of bug 328531.
Here are a few issues I'm facing now.
(**1**) Is there anything I can do on the server's side where the rhino interpreter is running to overcome the bug? I can't match any source my server runs to something local in the eclipse.
I decided to first try running the remote debugging process against a simple java program that only runs the interpreter with a debugger attached before trying to run against my server.
Here's my Interpreter code:
import java.io.FileReader;
import org.eclipse.wst.jsdt.debug.rhino.debugger.RhinoDebugger;
import org.mozilla.javascript.Context;
import org.mozilla.javascript.ContextFactory;
import org.mozilla.javascript.Script;
import org.mozilla.javascript.Scriptable;
public class RhinoInterpreter {
private static final String FILENAME = "C:/dev/HeliosClean/workspace/Rhino/src/com/worklight/temp/rhino/testing.js";
public static void main(String[] args) throws Exception {
ContextFactory contextFactory = ContextFactory.getGlobal();
// Attach debugger
RhinoDebugger debugger = new RhinoDebugger("transport=socket,suspend=y,address=9999,trace=y");
debugger.start();
contextFactory.addListener(debugger);
// Create context and run.
Context context = contextFactory.enterContext();
Scriptable scope = context.initStandardObjects();
FileReader fileReader = new FileReader(FILENAME);
Object exec = context.evaluateReader(scope, fileReader, FILENAME, 0, null); // Attempt 1
// Script script = context.compileReader(fileReader, FILENAME, 0, null); // Attempt 2
// Object exec = script.exec(context, scope);
System.out.println(exec);
}
}
This is testing.js:function foo(str) {
return "result is " + str;
}
function goo(i,j) {
return i+j;
}
var a = 5;
var b = 6;
var c = goo(a,b) + goo(goo(a,a),b);
foo(c);
I run the interpreter as a simple Java application, then I attach the eclipse JSDT rhino debugger to port 9999.
I can see in my stdout the entire communication between the debug process and the client.
Using this scenario (Attempt 1 and when the access to the file is with an absolute path) eclipse manages to match the source in the stack to the original source.
(**2**) If I put in "testing.js" instead of FILENAME in the evaluateReader parameters, eclipse fails to match the source to the stack file.
(**3**) Another problem I have with this scenario is that if I put a breakpoint where you see I immediately see a "setbreakpoint" request sent to the server, and when running the script I stop there. So far so good, BUT if I try to place a breakpoint inside on of the functions (like where you see return "result is" + str; the "setbreakpoint" is never sent and the script doesn't stop there.
(**4**) If I try debugging with "attempt 2" -> compiling instead of evaluating, I've seen mostly the same behavior.
(**5**) In both scenarios, stepping into a function doesn't really work, it doesn't jump to the correct line, local stack variables aren't shown in the variables view and stepping over again is like step-returning. Multiple calls to functions in the same line only allows stepping into once.
So in conclusion I think every issue I have now marked with (**#**) is something I'm trying to figure out. Are these problems something that can be resolved? Any answer to any of these will be appreciated
|
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.06635 seconds