Thought I'd pitch back in since my message was linked... I haven't tried removing the Rhino classes (though it might work) because there seems to be another issue that is really the crux of the problem [this is just a symptom]. Batik only tries to load the Rhino interpreter at all because of the contentScriptType="text/ecmascript" attribute on the SVG. This is a default attribute in Batik, and cannot be removed, only changed (I understand in SVG 1.0 this is a required element; ironically it isn't required in the drafts for SVG 1.1). Consequently, shortly after Rhino fails to load, an "unknown language: text/ecmascript" error occurs.
There seem to be only two solutions: 1. Make the document Static to the canvas -- but this also prevents the DOM update listener from loading, which is rather useless if you actually want to make any alterations to the SVG document from within your applet (as I do). 2. Change the contentScriptType. The seemingly obvious solution would be to change the contentScriptType to Java (I forget the tag), since you probably will be adding DOM listeners from your applet. This has the snag that Batik then expects the Java "script" attached to the document to be another set of classes that it will dynamically instansiate, and not the pre-existing and already-instansiated classes of your applet. [which holes that idea unless you want to majorly re-engineer your applet in a very maintenance-hard way]. The temporary solution I am looking at is changing the contentScriptType to a constant (something like ThrowawayThisException), and subclassing the JSVGCanvas user agent to specifically suppress the "unknown language: ThrowawayThisException" exception -- the exception will still happen but the user never will never see it and it won't stop anything from running. More ideally, it would be nice if the "Dynamic Support" setting in the JSVGCanvas could be split into two separate settings for DOM Update Listening support and Scripting Support. cheers, Will. PS. My experience with Batik is limited to about a month, so anyone more knowledgeable feel free to correct me. ----- Original Message ----- From: "Thomas E Deweese" <[EMAIL PROTECTED]> To: "Batik Users" <[EMAIL PROTECTED]> Sent: Tuesday, June 10, 2003 5:55 PM Subject: RE: applet security rhino interpreter > >>>>> "S" == Stephen <[EMAIL PROTECTED]> writes: > > S> I'm having security problems with the applet (act surprised AGAIN!) > S> allowing the RhinoInterpreter to create a class loader. Do I have > S> to use the rhinoClassLoader that is created in the constructor of > S> RhinoInterpreter? Can I use the applet class loader instead? I > S> really dread having to require everyone who runs the applet to > S> update their security policy for it to run. > > Do you need script support? If you not might be able to leave the > rhino package out of your Applet. If you need JavaScript support then > things get tricky. See one of the cool things about Rhino is that it > compiles your JavaScript in ByteCode then loads it and runs it - I > don't think this can be done with the Applet Class Loader. > > A week or two ago there was a thread on just this, someone > mentioned that they were able to hack Rhino by simply removing the > optimization classes - perhaps the two of you can sort this out and > post results? > > http://koala.ilog.fr/batik/mlists/batik-users/archives/msg03506.html > > S> BTW: I used Crimson instead of xerces for the applet and it worked > S> just fine. > > Glad to hear it. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
