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
