Subj : More trouble with the Rhino debugger AND Re: Question about Rhino To : netscape.public.mozilla.jseng From : Jon Brisbin Date : Wed Sep 07 2005 12:05 pm Mark Turansky wrote: >This reply may not be the one you're looking for, but it seems to me you >could simplify your application. The more you can remove the better. The >fewer "moving pieces" the better. > > It actually has recently been rewritten to be much leaner. The part of the application I described was the simple part :-) >That said, Rhino has native XML support now thanks to E4X. I imagine you >could cut Jelly right out of the equation if you wanted to. > > Nope. JavaScript, while an integral part of the application, is far from the only part of it. JavaScript is a convienience tool for those times when the others parts of the application need a little more complex logic processing than can be provided through stored procedures, SQL, XSLT, or any others means. >Lastly, if you don't need xml, why use it at all? Javascript Object >Notation (JSON - www.json.org) is just as expressive in terms of data >markup but it includes semantics that xml does not have and is lighter >weight (no parsing required, easier on the bandwidth). > > XML is the foundation of my framework. It would be impossible, given the tasks asked of it, to get away from industry-standard XPath and XSLT. I have done extensive testing in performance and speed in the whole "you should use SAX instead of DOM" argument. My applications would have to be radically re-thought and they would perform twice as slow if I chucked the DOM. I know this for a fact because I've tested it :-) JavaScript notation is handy. I would like to use it more, but not at the expensive of the DOM. The DOM runs the application. It is the single most important part of the application framework because it glues the disparate actions together and allows them to talk to each other in a way that is almost impossible to replicate without a significant increase in the amount of Java code and would require unwieldy complexity (again, speaking from experience. :-) It would be wonderful if E4X integrated with my other XML technologies to make passing XML into and back out of a snippet of JavaScript code seamless. Now to the problems with the debugger: I'm storing a shared context in a HashMap that gets passed into each action performed. It solves the problem I mentioned in my earlier email, but introduces a new problem with the debugger: 10:30:03,753 INFO [STDOUT] Exception in thread "AWT-EventQueue-0" 10:30:03,753 INFO [STDOUT] java.lang.StackOverflowError 10:30:03,769 INFO [STDOUT] at sun.reflect.Reflection.quickCheckMemberAccess(Reflection.java:51) 10:30:03,769 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:571) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:142) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1666) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:177) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.IdScriptableObject.get(IdScriptableObject.java:383) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.LazilyLoadedCtor.getProperty(LazilyLoadedCtor.java:105) 10:30:03,769 INFO [STDOUT] at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) 10:30:03,769 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 10:30:03,769 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:585) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:142) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1666) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:177) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.IdScriptableObject.get(IdScriptableObject.java:383) 10:30:03,769 INFO [STDOUT] at org.mozilla.javascript.LazilyLoadedCtor.getProperty(LazilyLoadedCtor.java:105) 10:30:03,785 INFO [STDOUT] at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) 10:30:03,785 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 10:30:03,785 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:585) 10:30:03,785 INFO [STDOUT] at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:142) 10:30:03,785 INFO [STDOUT] at org.mozilla.javascript.ScriptableObject.getByGetter(ScriptableObject.java:1666) 10:30:03,785 INFO [STDOUT] at org.mozilla.javascript.ScriptableObject.get(ScriptableObject.java:177) 10:30:03,785 INFO [STDOUT] at org.mozilla.javascript.IdScriptableObject.get(IdScriptableObject.java:383) 10:30:03,785 INFO [STDOUT] at org.mozilla.javascript.LazilyLoadedCtor.getProperty(LazilyLoadedCtor.java:105) Looks like a circular reference problem in my scope, but I'm only setting a parent scope if 1) I'm debugging, and 2) the parent scope isn't an instanceof org.mozilla.javascript.tools.shell.Global, which is the context I'm using for debugging purposes. In my test case, I have a snippet of JavaScript that defines a function and gets executed via Jelly when the XML is processed. This evaluation isn't debugged, so the scope is just saved for later. When I get to the JavaScript I'm actually debugging, I see from my environment that some JavaScript processing has already occurred, so I snag that Context and set it as the parent scope. This works great when I'm not debugging anything. I get the above stacktrace, however, when I set debug = 'true.' I'm pondering whether or not to copy the values from the parent scope into the debugging scope to prevent the stack overflow but still have access to the results of previously executed JavaScript. Thanks for all the help here on my problems. I've learned a lot by working through this process and you folks have been very helpful! :-) Jon Brisbin NPC International, Inc. .