Bart created JRUBY-6481: --------------------------- Summary: AccessControl exceptions attempting to create JRuby instances in applet Key: JRUBY-6481 URL: https://jira.codehaus.org/browse/JRUBY-6481 Project: JRuby Issue Type: Bug Components: Core Classes/Modules Affects Versions: JRuby 1.6.7 Environment: Windows, Chrome and Firefox browsers Reporter: Bart Attachments: Engine.java, RubyVMThread.java
I was asked on the JRuby forum to submit the following as a possible bug: Hi, I'm trying to embed multiple instances of JRuby within an applet but am getting some unusual access violations. I'm using the 1.6.7.dev snapshot. The applet is signed. What I'd like to be able to do is create multiple threads each running a JRuby instance. I'm using ScriptingContainer to instantiate JRuby and feed it code to execute (via runScriptlet()) but perhaps this is not the best way? I notice that JRubyApplet does it differently. Here is what I'm observing: 1. When I try to create a new ScriptingContainer inside the constructor of a class other than the applet class, like so: RubyVMThread() { id = uniqueID++; try { jRubyContainer = new ScriptingContainer(LocalContextScope.THREADSAFE, LocalVariableBehavior.PERSISTENT); jRubyRuntime = jRubyContainer.getProvider().getRuntime(); jRubyContainer.runScriptlet("puts \"Hello, World!\""); } catch (Exception e) { e.printStackTrace(); } } The call to getRunTime() fails: java.lang.NullPointerException at org.jruby.util.OSEnvironment.addRubyKeyValuePair(OSEnvironment.java:101) at org.jruby.util.OSEnvironment.getAsMapOfRubyStrings(OSEnvironment.java:85) at org.jruby.util.OSEnvironment.getEnvironmentVariableMap(OSEnvironment.java:51) at org.jruby.RubyGlobal.defineGlobalEnvConstants(RubyGlobal.java:411) at org.jruby.RubyGlobal.createGlobals(RubyGlobal.java:363) at org.jruby.Ruby.init(Ruby.java:1092) at org.jruby.Ruby.newInstance(Ruby.java:182) at org.jruby.embed.internal.LocalContext.getThreadSafeRuntime(LocalContext.java:69) at org.jruby.embed.internal.ThreadSafeLocalContextProvider.getRuntime(ThreadSafeLocalContextProvider.java:61) at myapplet.RubyVMThread.<init>(RubyVMThread.java:64) at myapplet.Engine.createVM(Engine.java:93) ... If I do the same thing inside the applet's start() method, it works and the scriptlet is executed. If I do both (first in the start() method and then in a RubyVMThread() constructor), the second one results in: java.security.AccessControl Exception: access denied (java.lang.RuntimePermission createClassLoader) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkCreateClassLoader(Unknown Source) at java.lang.ClassLoader.checkCreateClassLoader(Unknown Source) at java.lang.ClassLoader.<init>(Unknown Source) at java.security.SecureClassLoader.<init>(Unknown Source) at java.net.URLClassLoader.<init>(Unknown Source) at org.jruby.util.JRubyClassLoader.<init>(JRubyClassLoader.java:30) at org.jruby.Ruby.getJRubyClassLoader(Ruby.java:2283) at org.jruby.runtime.CallbackFactory.createFactory(CallbackFactory.java:256) at org.jruby.Ruby.callbackFactory(Ruby.java:2700) at org.jruby.RubySystemCallError.createSystemCallErrorClass(RubySystemCallError.java:175) at org.jruby.Ruby.initExceptions(Ruby.java:1343) at org.jruby.Ruby.bootstrap(Ruby.java:1114) at org.jruby.Ruby.init(Ruby.java:1085) at org.jruby.Ruby.newInstance(Ruby.java:182) at org.jruby.embed.internal.LocalContext.getThreadSafeRuntime(LocalContext.java:69) at org.jruby.embed.internal.ThreadSafeLocalContextProvider.getRuntime(ThreadSafeLocalContextProvider.java:61) at myapplet.RubyVMThread.<init>(RubyVMThread.java:64) at myapplet.Engine.createVM(Engine.java:93) ... I'm testing this locally but would like to ultimately deploy it on a server. Any ideas on why this is occurring? I've attached the source code. Note that Engine.createVM(), which creates a new RubyVMThread, is called by JavaScript. Both source files are attached. Perhaps there is a different way to do this? Thank you! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email