Subject:
Embedding Rhino in an Applet
Resent-Date:
Thu, 17 May 2001 14:53:05 -0700 (PDT)
Resent-From:
mozilla-jseng@mozilla.org
Date:
Thu, 17 May 2001 16:39:14 -0700
From:
"Chester Kustarz II" <chester@monkey.org>
Organization:
monkey.org
To:
mozilla-jseng@mozilla.org
Newsgroups:
netscape.public.mozilla.jseng
Hello, I am trying to find a scripting language with an interpreter that I
can embed in an applet in order to run test scripts inside the applet. I
have already tried TCL-based Jacl and they do not support running inside an
applet. I then downloaded the Rhino/JS interpreter but am having trouble
getting it to run inside the browser (IE 5.5). Here is the exception I am
getting:
com.ms.security.SecurityExceptionEx[org/mozilla/javascript/ScriptRuntime.<cl
init>]: Reflective access to class java.lang.Thread prohibited.
at com/ms/security/permissions/ReflectionPermission.check
at com/ms/security/PolicyEngine.deepCheck
at com/ms/security/PolicyEngine.checkPermission
at com/ms/security/StandardSecurityManager.chk
at com/ms/security/StandardSecurityManager.checkMemberAccess
at java/lang/Class.checkMemberAccess
at java/lang/Class.getDeclaredMethod
at org/mozilla/javascript/ScriptRuntime.<clinit>
at org/mozilla/javascript/ScriptableObject.getExclusionList
at org/mozilla/javascript/ScriptableObject.defineClass
at org/mozilla/javascript/Context.initStandardObjects
at org/mozilla/javascript/Context.initStandardObjects
at RhinoShellApplet.init
at com/ms/applet/AppletPanel.securedCall0
at com/ms/applet/AppletPanel.securedCall
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.run
at java/lang/Thread.run
com.ms.security.SecurityExceptionEx[org/mozilla/javascript/Context.initStand
ardObjects]: Unable to access system property:
org.mozilla.javascript.JavaAdapter
at com/ms/security/permissions/PropertyPermission.check
at com/ms/security/PolicyEngine.shallowCheck
at com/ms/security/PolicyEngine.checkCallersPermission
at com/ms/security/StandardSecurityManager.chk
at com/ms/security/StandardSecurityManager.checkPropertyAccess
at java/lang/System.getProperty
at org/mozilla/javascript/Context.initStandardObjects
at org/mozilla/javascript/Context.initStandardObjects
at RhinoShellApplet.init
at com/ms/applet/AppletPanel.securedCall0
at com/ms/applet/AppletPanel.securedCall
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.processSentEvent
at com/ms/applet/AppletPanel.run
at java/lang/Thread.run
1. In that patch I forgot to remove "import org.mozilla.classfile.*" and
simply catch Exception in newInvokerMaster which is not a good practice.
The attached patch FunctionObject_patch fixes that and removes other
unused imports.
2. In org.mozilla.classfile.DefiningClassLoader defineClass method first
tries to call via ClassManager the defineClass method in a class loader
that loaded DefiningClassLoader itself. But this would define new
classes in that class loader so they would not be subject of the garbage
collection until a classloader that loads DefiningClassLoader would go
away even if a DefiningClassLoader instance is gone. The
DefiningClassLoader_patch removes that and simply calls super.defineClass.
The patch also change the order of class search in loadClass so the
loader first looks for a class among its defined classes and only after
that in parent loaders.
Regards, Igor
1. In that patch I forgot to remove "import org.mozilla.classfile.*" and
simply catch Exception in newInvokerMaster which is not a good practice.
The attached patch FunctionObject_patch fixes that and removes other
unused imports.
2. In org.mozilla.classfile.DefiningClassLoader defineClass method first
tries to call via ClassManager the defineClass method in a class loader
that loaded DefiningClassLoader itself. But this would define new
classes in that class loader so they would not be subject of the garbage
collection until a classloader that loads DefiningClassLoader would go
away even if a DefiningClassLoader instance is gone. The
DefiningClassLoader_patch removes that and simply calls super.defineClass.
The patch also change the order of class search in loadClass so the
loader first looks for a class among its defined classes and only after
that in parent loaders.
Regards, Igor
> Igor Bukanov wrote:
>
>
>>Norris Boyd wrote:
>>
>>
>>>The intention was to keep classfile and JavaAdapter optional. Those
>>>dependencies crept in. We can use Invoker optionally--perhaps I should do
>>>some performance numbers to see if it's worth it.
>>>
>>I implemented that patch, it splits Invoker.java into Invoker.java and
>>its implementation in optimizer/InvokerImpl.java The reason to put it
>>into optimizer package is that Invoker is very similar in spirit to
>>NativeScript: it generates classes to speed up access and in this way
>>there is no need to have separated option not to use: one can simply
>>remove optimizer all together.
>>
>
> Yes, that sounds great.
>
>
>>
>>I noticed during implementation that JavaAdapter.DefiningClassLoader and
>>optimizer/JavaScriptClassLoader contains the same code, so maybe they
>>can be moved to org.mozilla.classfile package under one name?
>>
>
> Yes, that sounds like a good change too. Thanks for noticing that.
The update is pretty messy: it touches FunctionObject which I changed to
remove the special treatment of NativeWith in the previous patch, and it
also add/removes files.
Here is a description:
DefiningClassLoader.java should go to org/mozilla/classfile. It is the
same code that was in omj/optimizer/JavaScriptClassLoader.java with
class rename and adding public attribute and correspondingly
omj.optimizer/JavaScriptClassLoader.java should be removed. I guess it
would be nice to preserve logs/history in CVS during the move.
InvokerImpl.java should go to omj/optimizer. It is mostly what
omj.Invoker was.
invoker_changes_patch was generated via
cvs diff -u Invoker.java JavaAdapter.java optimizer/Codegen.java
and contains changes against the current CVS
FunctionObject_invoker_patch was generated via
diff -u ../../mozilla.1/javascript/FunctionObject.java FunctionObject.java
and contains changes against that With patch.
Igor
constructor, removes the special treatment of the With object from
IdScriptable and FunctionObject, adds to IdFunction the
initAsConstructor method similar in spirit to
FunctionObject.addAsConstructor (it is called now from IdScriptable and
NativeWith) and replaces in Context.java lazy initialization of
NativeWith by direct call of NativeWith.scopeInit.
The attached patch moves the IdFunction.Master interface to the
separated file IdFunctionMaster and eliminates getParentScope from the
interface: it is simpler to set scope explicitly.
The patch assumes the changes in IdFunction.java from the previous patch
and were produced via:
diff -uP javascript.2000-05-10 javascript
Regards, Igor
