I think I've run into a subtle issue where the Rhino debugger view of
variables ("this" and "Locals" tab) gives you something different than
an evaluation in the "Evaluate" window.
What I think is happening is this: I'm using the debugger in a web
application (not remotely, so I set my Tomcat windows service to allow
interaction with the Desktop). At some point in processing an HTTP
request, we invoke Rhino (and the debugger). One of my custom object
wrappers ends up, after a few levels of calls, to depend on some
Thread context that the web application framework sets up.
When my custom object wrapper 'get' method is invoked from the
"Evaluate" window, it is on the HTTP processor thread, it finds its
web app framework context, and all is well.
But, when I use the TreeView in the "this" tab to display the same
variable, my custom object wrapper is invoked on the EDT thread. As a
result, the web framework Thread specific context is not setup.
Taking a look at the Dim.java class, it seems like the
private void interrupted(Context cx, final StackFrame frame,
Throwable scriptException) {
method has logic in there to interpret the eval request on the actual
thread (not the EDT). That's probably necessary (or at least the
easiest way) to get the right call stack context.
On the other hand, the Dim.java
public Object getObjectProperty(Object object, Object id) {
method doesn't seem to use the same 'thread switch' magic.
Seems like someone else using the debugger on the web app server side
(helma?) would have run into something like this at some point,
though?
Thanks,
Jeremy
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
