The exception happens because js.jar does not have the "createClassLoader" permission.
The RhinoClassLoader is really used for two purposes:
a. It is used by Rhino to load classes it dynamically creates.
b. It is used to define the security domain for Rhino. This is used for some special operations (getURL/parseXML).
You have two options: either you configure Rhino to disable dynamic class compilation or you need to grant rhino permissions to do that (and Batik so that you do not get into restrictions due to Rhino being invoked from Batik).
What Thomas suggest would result in a NullPointerException as you need to configure Rhino to disable dynamnic class creation / loading. However, the part regarding the getAccessControlContext seems right.
The security permissions are application-wide settings. If you run squiggle, you actually use a specific security setting (see resources/org/apache/batik/apps/resources/svgbrowser.policy). Same for the rasterizer. In your applet, you also need to set/define the security settings.
My suggestion is to either grant the 'right' permissions to js.jar in your applet or you need to disable class compilation in the code. I am not familiar enough with Rhino to tell you how to do this exactly. There was a suggestion that removing some classes from js.jar would work.
I hope this helps, Vincent.
Thomas' suggestion might work even though Thomas E Deweese wrote:
"WB" == William Billingsley <[EMAIL PROTECTED]> writes:
WB> I'm using Batik in a couple of applets I'm developing ( WB> http://www.cl.cam.ac.uk/~whb21/svgDraw/svgCircuit.html is one WB> example; the applet is near the foot of the page)
WB> At startup an AccessControlException occurs when Batik tries to WB> create a Rhino Interpreter from the InterpreterPool (exception WB> trace at foot of email). js.jar is included in the archive WB> attribute for the applet on the page, and is available in the same WB> directory as the applet.
WB> From what I can see delving into the code, RhinoClassLoader WB> specifically extends URLClassLoader, so I'm not sure if this a WB> "can't find the class on the server and not allowed to look WB> elsewhere" (as if I had not included js.jar) or if this exception WB> is coming straight out of the way Batik is written, and will WB> always produce this error if the applet is unsigned?
This is the case, currently as written you will always produce this error.
WB> So I have a few questions: 1. How to stop this error (without
WB> signing or self-signing the applet -- self-signing will happen
WB> eventually but can't yet) .
I took a quick look at the code in Batik, and I think this is fairly easy to deal with.
1) Put the creation of the RhinoClassLoader in a try block. If you catch an error make sure rhinoClassLoader the member is null.
2) In getAccessControlContext if rhinoClassLoader is null. return 'java.security.AccessController.getContext()' instead.
The other two places where rhinoClassLoader is used should be ok with a null value being passed.
The net effect of this is that Batik will attempt to create a protection domain for Rhino (a sandbox for JavaScript to run in) if this fails then Rhino will simply run with Batik's permissions. I think this is the perfect solution - if Batik is in a sandbox already then so is Rhino, if Batik has full permissions Rhino get's a sandbox defined by Batik. If someone has granted Batik extra permissions then they can choose to also grant Batik classloader permission (in which case Rhino get's a sandbox) or let Rhino have those additional permissions as well.
Vincent you did the security work does the above sound like it might work?
WB> 2. Is there any way of turning ECMAScript off altogether in the
WB> document (but keeping the document "dynamic" so DOM updates made
WB> from my applet code will occur appropriately). In other words, is
WB> there a way to avoid including the 580k js.jar in the archive for
WB> the applet?
Theoretically yes. I think if you omit the classes from the script/rhino directory from the classpath it will not register a handler for text/ecmascript. I've never done this and I don't think I know anyone who has - but it looks like it should work.
WB> 3. If I did switch it off, is there an easy way to attach onClick WB> and onDrag events to the SVG elements, to fire directly to Java WB> (without going through Javascript) [I'm sure there must be but for WB> some daft reason I can't find it]
Yes, attach listeners to the DOM in Java.
WB> Will.
WB> exception trace: java.security.AccessControlException: access WB> denied (java.lang.RuntimePermission createClassLoader) at WB> java.securitiy.AccessControlContext.checkPermission at WB> java.securitiy.AccessController.checkPermission at WB> java.lang.SecurityManager.checkPermission at WB> java.lang.SecurityManager.checkCreateClassLoader at WB> java.lang.ClassLoader.<init> at WB> java.security.SecureClassLoader.<init> at WB> java.net.URLClassLoader.<init> at WB> org.apache.batik.script.rhino.RhinoClassLoader.<init> at WB> org.apache.batik.script.rhino.RhinoInterpreter.<init> at WB> org.apache.batik.script.rhino.RhinoInterpreterFactory.createInterpreter WB> at org.apache.batik.bridge.BridgeContext.getInterpreter at WB> org.apache.batik.BaseScriptingEnvironment.dispatchSVGLoadEvent WB> etc.
WB> --------------------------------------------------------------------- WB> To unsubscribe, e-mail: [EMAIL PROTECTED] For WB> additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- 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]
