On Feb 25, 2:45 am, Merten Schumann <[email protected]> wrote:
> Hello Greg,
>
> in my hierarchy of scopes I solved the problem "how to use Java classes from 
> Rhino scopes" like this:
>
> I've got my sealed scopes called "root scopes" - with some basic 
> functionality and sealed, to prevent people from introducing global 
> variables, modify things at all - scripts can only introduce (their local) 
> variables.
>
> Then I have scopes called "run scopes" - I'm creating them with parent set to 
> my root scopes, so they have access to my global environment. Now, regarding 
> the Java class use, I'm doing Scriptable importer=new ImporterTopLevel(cx) + 
> run_scope.setPrototype(importer).
>
> So my run scopes can import more stuff than my sealed root scopes have 
> imported before ... works pretty well. These run scopes live as long as their 
> associated object in my Java environment exists ... And the single run scopes 
> will not put more and more stuff in the global scopes, if the run scope goes 
> out of use, it's imports will follow ...
>
> cu
>    Merten
>
> -----Original Message-----
> From: 
> dev-tech-js-engine-rhino-bounces+merten.schumann=asg....@lists.mozilla.org 
> [mailto:dev-tech-js-engine-rhino-bounces+merten.schumann=asg....@lists.mozilla.org]
>  On Behalf Of Greg Lindholm
> Sent: Tuesday, February 24, 2009 5:35 PM
> To: [email protected]
> Subject: Sealed shared scopes and Java classes (LiveConnect)
>
> Using Rhino 1.7R1
>
> I'm running JS from a Java web application and have setup a Sealed
> shared scope as described herehttp://www.mozilla.org/rhino/scopes.html.
>
> For each "request" where I need to run JS I setup a new scope and
> point the prototype to the sealedSharedScope.
>
> I have found that if I seal the shared scope itself
> ( sealedSharedScope.sealObject(); ) then I get this exception when I
> attempt to use Java classes from within a script.
>
> org.mozilla.javascript.EvaluatorException: Cannot modify a property of
> a sealed object: getClass. (/initSharedScope.js#44)
>
> I have traced the root cause down to inside:
> org.mozilla.javascript.NativeJavaTopPackage.init(Context cx,
> Scriptable scope, boolean sealed)
>
> Inside the init() method this call is made which attempts to define a
> property in the parent scope for the function "getClass".
> getClass.exportAsScopeProperty(); // line 139
>
> It then throws the exception because the scope has been sealed.
>
> If I don't call sealedSharedScope.sealObject();  then everything works
> with no exception. But of course the scope isn't sealed and this is
> too dangerous for untrusted JS in a shared environment.
>
> I've tried adding the "dynamic scope" but this made no difference.
>
> It appears that using a Sealed Shared Scope and Java classes is
> incompatible.  Is there some way to make this work?
>
> Note if you test this with some common java classes like
> "java.lang.String" it works fine as it appears some common classes are
> predefined in the scope or pre-cached.
> Note I also use a ClassShutter to limit the java classes allowed to
> safe classes.
>
> _______________________________________________
> dev-tech-js-engine-rhino mailing list
> [email protected]https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino

Thanks for the suggestion.  I took a look at ImporterTopLevel but
didn't really see how this helped, it just moved the problem to a
different scope since if I sealed the importer scope I ended up with
the same exception.  The other thing is that ImporterTopLevel does a
Context.initStandardObjects() which is an expensive operation which I
only want to do once, in the shared sealed scope.

I found the reply by wolffiex to solve the problem by forcing the
shared scope to load the needed properties before it gets sealed.
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino

Reply via email to