Hi John, "John C. Turnbull" <[email protected]> wrote on 02/04/2009 02:42:05 PM:
> I have updated from SVN but I am getting a strange error when I run > Squiggle. It comes up with the following exception: > > org.mozilla.javascript.EvaluatorException: Function importClass must be > called with a class; had "[JavaPackage org.w3c.dom.Location]" instead. Hmm, my guess is that for some reason Rhino can't find the org.w3c.dom.Location class on your classpath so it assumes that it's a package. The question is why can't it find that class? I suppose we could call 'ClassLoader.findClass(...)' before asking Rhino to import it, but it feels risky since I'm not sure we can be certain that the same classloader is used in both places (plus it is likely to cause pings back to the applet server if it can't be found - so you would have to edit it out anyway). If it is as I suspect a classpath issue in your setup then that would be better. > at > org.mozilla.javascript.DefaultErrorReporter.runtimeError(DefaultErrorReporte > r.java:109) > at > org.mozilla.javascript.Context.reportRuntimeError(Context.java:938) > at > org.mozilla.javascript.Context.reportRuntimeError(Context.java:994) > at > org.mozilla.javascript.Context.reportRuntimeError1(Context.java:957) > at > org.mozilla.javascript.ImporterTopLevel.js_importClass(ImporterTopLevel.java > :197) > at > org.mozilla.javascript.ImporterTopLevel.execIdCall(ImporterTopLevel.java:272 > ) > at > org.mozilla.javascript.IdFunctionObject.call(IdFunctionObject.java:129) > at > org.mozilla.javascript.optimizer.OptRuntime.callName(OptRuntime.java:97) > at org.mozilla.javascript.gen.c2._c0(unnamed script:0) > at org.mozilla.javascript.gen.c2.call(unnamed script) > at > org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:400) > at > org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3005) > at org.mozilla.javascript.gen.c2.call(unnamed script) > at org.mozilla.javascript.gen.c2.exec(unnamed script) > at org.mozilla.javascript.Context.evaluateString(Context.java:1104) > at > org.apache.batik.script.rhino.RhinoInterpreter$1.run(RhinoInterpreter.java:1 > 78) > at org.mozilla.javascript.Context.call(Context.java:515) > at > org.mozilla.javascript.ContextFactory.call(ContextFactory.java:509) > at > org.apache.batik.script.rhino.RhinoInterpreter.<init>(RhinoInterpreter.java: > 183) > at > org.apache.batik.script.InterpreterPool.createInterpreter(InterpreterPool.ja > va:101) > at > org.apache.batik.bridge.BridgeContext.getInterpreter(BridgeContext.java:563) > at > org.apache.batik.bridge.BaseScriptingEnvironment.getInterpreter(BaseScriptin > gEnvironment.java:320) > at > org.apache.batik.bridge.BaseScriptingEnvironment.getInterpreter(BaseScriptin > gEnvironment.java:316) > at > org.apache.batik.bridge.BaseScriptingEnvironment.dispatchSVGLoad(BaseScripti > ngEnvironment.java:657) > at > org.apache.batik.bridge.BaseScriptingEnvironment.dispatchSVGLoadEvent(BaseSc > riptingEnvironment.java:616) > at > org.apache.batik.bridge.UpdateManager.dispatchSVGLoadEvent(UpdateManager.jav > a:243) > at > org.apache.batik.bridge.UpdateManager.dispatchSVGLoadEvent(UpdateManager.jav > a:221) > at > org.apache.batik.swing.svg.SVGLoadEventDispatcher.run(SVGLoadEventDispatcher > .java:100) > > I have found if I comment out that class and the following classes in > scripts.txt the problem goes away: > > org.w3c.dom.events.CustomEvent > org.w3c.dom.events.KeyboardEvent > org.w3c.dom.events.MutationEvent > org.w3c.dom.events.MutationNameEvent > org.w3c.dom.events.TextEvent > org.w3c.dom.events.UIEvent > org.w3c.dom.ElementTraversal > > All other classes are fine. > > Why is this happening? > > Thanks, > > John > > > -----Original Message----- > > From: Helder Magalhães [mailto:[email protected]] > > Sent: Thursday, 5 February 2009 06:31 > > To: [email protected] > > Subject: Re: FW: Strange applet delay revisited > > > > > Sounds good. What's the default contents of this file? > > > > Well, noticed this check in so a SVN refresh should be sufficient to > > take a look. ;-) > > > > > > > OK. If you feel happy with having only java.lang.System imported, > > then > > > I'm happy with that too. > > > > I'd argue if this should also be left out, but polluting the global > > namespace with a single item doesn't seem serious (specially when one > > has the possibility of disabling it without touching the source code, > > which is good). :-) > > > > > > Everything seems to work as expected - no more useless server > > connection attempts, at least from my quick check. :-) It's great > > that this has landed! ;-) I'd suggest everyone with access to the > > trunk version to test content (containing ECMAScript, naturally) in > > order to check for possible regressions. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: batik-users- > > [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
